AI coding agents run commands, edit files, install packages and read the web. Each of those needs an allowlist, not a blocklist.
This guide covers the four layers, with example rules, and shows where an AI agent allow list sets the web page types a coding agent may open.
A blocklist tries to name every dangerous command, path and site. There are always more than you can list.
An allowlist names what the task needs. Everything else is denied or sent for approval.
A coding agent allowlist is the set of commands, file paths, network destinations and web page types an AI coding agent may use without asking.
It is enforced by the agent's settings, the operating system and the network, not by instructions in a prompt.
A coding agent touches four kinds of resource. Each gets its own short list.
The examples use a neutral format. Translate them into the settings your agent and proxy support.
Match on the full command, not the first word. "git" alone would allow a force push.
Secrets should not be readable at all. An agent cannot leak what it never saw.
A registry mirror lets you vet packages once, instead of trusting every public upload.
Coding agents read a lot of documentation. They rarely need to sign up, upload or post anywhere.
Most coding agents support three tiers. Getting the split right matters more than the length of any list.
Review the split each month using the approval log.
If "ask" fires every minute, people start approving without reading.
| Tier | What goes here | Why |
|---|---|---|
| Allow | Read-only and local checks: tests, lint, build, status, diff | Safe to repeat, easy to undo |
| Ask | Changes that leave the machine or change dependencies | Worth one look from a person |
| Deny | Destructive or shared: force push, production data, cloud admin, sudo | No task should need them from an agent |
Coding agents browse more than most people expect. They read docs, issues, forums and changelogs to solve problems.
Any of those pages can carry hidden instructions. The next URL the agent opens is where a check can stop the harm.
Agents add packages to fix problems quickly. A misspelled or look-alike package name is an easy way in for attackers.
Dependencies also outlive the task, so a bad one stays in the code long after the agent is gone.
Four rules keep dependencies under control.
The agent's network allowlist reaches the mirror, not public registries directly.
Adding a package is in the "ask" tier, with the name shown clearly.
Changes go through the normal review of a pull request.
Packages that run code at install time need an explicit yes.
Coding agents work where secrets live: config files, environment variables and shell history.
Each card below removes one common path from a secret to the outside world.
The safest secret is one the agent cannot read.
.env files, keys and credential folders are outside the file allowlist.
Start the agent with only the variables its tools need.
Where the agent needs access, give it a token that expires within hours.
Deny post_create and upload page types, the easiest routes out.
Check every change for secrets before it is committed.
Secrets pasted into a prompt end up in logs.
The same agent can run on a developer's laptop or inside a build pipeline. The risks differ, so the lists should too.
Keep the two lists in the same repository, so a change to one prompts a look at the other.
In pipelines nobody is watching, so "ask" usually becomes "deny".
| Layer | On a laptop | In a pipeline |
|---|---|---|
| Commands | Allow, ask, deny | Allow and deny only |
| Files | The workspace | The checked-out repository |
| Network | Mirror, source host, proxy | Mirror and source host only |
| Web page types | Reading pages allowed | Documentation only, or none |
| Pushing code | Feature branches, with approval | Through the pipeline's own identity |
The worst coding agent incidents involve production data. The fix is not a better prompt, it is no path at all.
Treat any path from the agent to production as a bug to fix, not a risk to accept.
Production should be unreachable from the agent's machine, not just discouraged.
Developers will turn off controls that get in the way. Start generous on reading, strict on acting.
Share the week 2 findings with the team, so they see their feedback change the list.
Tighten based on what the logs show, not on guesses.
Ship a default allowlist for all four layers, with web checks in log-only mode.
Collect which "ask" prompts fire most and which denials annoy people.
Move safe, frequent commands to allow. Keep destructive ones on deny.
Turn on page-type denials for signup, upload, posting and comments.
These mistakes show up in most first attempts. Each one quietly reopens what the list was meant to close.
Most can be spotted by reading the allowlist aloud with one question: what else does this allow?
"git" allows force push. List the subcommands.
Allowing any script means allowing anything.
If the file is there, the agent can read it.
Any site means any upload page too.
Nobody answers "ask" in a pipeline.
Instructions are advice. Allowlists are enforced.
Different projects need different tools. Start from the closest row, then trim what your team never uses.
Record the chosen row in the agent registry, so reviewers know which defaults apply.
The web column stays almost the same everywhere, because coding work is mostly reading.
| Project | Commands to allow | Commands to ask | Web page types |
|---|---|---|---|
| Web front end | Tests, lint, local dev server, build | Adding packages | Docs, help centres, community |
| Back-end service | Tests, lint, local containers | Local migrations, adding packages | Docs, status, integrations |
| Data pipeline | Tests on sample data | Runs against staging copies | Docs only |
| Infrastructure code | Format, validate, plan | Nothing that applies changes | Docs, status |
| Mobile app | Tests, lint, local build | Adding packages, signing steps | Docs, help centres |
A full allowlist programme takes a few weeks. These five changes remove the largest risks in a day or two.
Do them in this order if time is short.
None of them slows down ordinary coding work.
Or deny them in the agent's file settings.
The two git actions hardest to undo.
If the agent's machine cannot reach production, the agent cannot either.
With the agent's name in a header.
The quickest ways for code or secrets to leave.
Developers adopt coding agents to go faster. Controls that ignore that get switched off.
These answers help keep the conversation practical.
Move safe, frequent commands to allow. Approval should fire a few times a day, not every minute.
Reading stays open. Only signup, upload, posting and comment pages are denied.
Diff review catches bad code. It does not catch a command the agent already ran or a page it already posted to.
Containers limit files and processes. Network and web access still need their own lists.
Allowlists last when one team owns the defaults and each project owns its changes.
A few numbers show whether the balance is right.
The honest fine print — the same two assumptions we publish, plus two operational ones
28 page types, including 8 action types, on 40M+ domains.
