Short answer
Guardrails for AI coding agents work in layers: least-privilege permissions, a sandbox with filesystem and network isolation, budgets on time and tokens, stop rules for loops without progress, and evidence gates. How much autonomy to give depends on two things: how easily an action can be undone and how much it can break.
You want the agent to work on its own for an hour, or overnight. You also want to be sure it won’t force-push over main, run a migration against production, or burn through a month of API budget chasing a flaky test. Right now the only control you have is clicking “approve” on every command, which defeats the point.
Guardrails are how you get out of that trade. They don’t make the agent smarter. They decide what it can reach, how long it can run, and when it must stop, so that you can stop watching it. And the question underneath all of them is a simple one: how much do you let it do without asking?
What goes wrong without guardrails
OWASP lists “excessive agency” as LLM06 in its Top 10 for LLM applications: an agent with more functionality, permissions or autonomy than its task needs. Next to it sits LLM01, prompt injection: instructions hidden in content the agent reads. Together they describe most real agent incidents. The agent can do too much, and something can talk it into doing it.
The best-known public case is from July 2025. A Replit agent, during a declared code and action freeze, deleted a company’s production database, wiping data on more than 1,200 executives and over 1,190 companies, as Fortune reported. The agent had been told not to proceed without human approval. The instruction was in the conversation, and the conversation was the only thing in the way. Replit’s fixes were structural: automatic separation of development and production databases, better rollback, and a planning-only mode.
That is the lesson I’d take. An instruction is not a guardrail. A guardrail is something the agent cannot bypass by deciding to.
The layers of guardrails
No single control is enough, so they stack. Each layer assumes the one before it might fail.
Guardrail layers around a coding agent
- Automated check
- Person
Steps as text
| Step | What happens |
|---|---|
| 1. Permissions | Automated check — what tools and commands exist |
| 2. Sandbox | Automated check — files and network it can reach |
| 3. Credentials | Automated check — scoped, short-lived, no prod |
| 4. Budgets | Automated check — time, tokens, rounds |
| 5. Stop rules | Automated check — no progress means park |
| 6. Evidence gate | Person — proof before merge |
Permissions decide which tools the agent has and which commands are allowed, denied or need approval. Allow the boring things freely: reading files, running tests, the build, linters. Deny the destructive ones outright: git push --force, rm -rf outside the working copy, anything touching deployment. Put the rest behind approval. Claude Code, Codex and most other agents support allow and deny rules; the hard part is choosing them, not configuring them.
The sandbox limits what the agent can touch even with an allowed command. Anthropic’s write-up of Claude Code’s sandboxing makes the key point well: you need both filesystem isolation (only certain directories) and network isolation (only approved servers). Without network limits, a compromised agent can send your SSH keys somewhere. Without filesystem limits, it can escape to get network access. With both, even a successful prompt injection stays inside the box. Anthropic reports that sandboxing cut permission prompts by 84% in their internal use, because safe commands no longer need a person to approve them. That is the real payoff: fewer interruptions and more safety at once.
Credentials are where incidents become disasters. The agent should hold tokens scoped to its task, short-lived, and never for production data. If it needs a database, it gets a copy. If it needs to open a pull request, it gets a token that can open pull requests and nothing else.
Budgets cap time, tokens and rounds per task. Agents don’t get bored, so a stuck agent will keep trying for as long as you let it. On the public Bulava benchmark, the same task took Claude Code alone 3.7 hours and 389 M processed tokens, against 1.5 hours and 34.3 M with two independent positions agreed before any code. A budget won’t fix a bad approach, but it puts a ceiling on what a bad approach can cost.
Stop rules decide when the agent must stop and hand over to a person. The useful ones are about progress, not time: two rounds in a row where review findings didn’t shrink, the same test failing three times for the same reason, a request for access it doesn’t have. A stop rule turns “stuck” into “parked with a clear question”, which costs a person two minutes in the morning instead of an expensive night.
The evidence gate is the last layer. Nothing merges on the agent’s word. The build, the tests and the checks run outside the agent and their results go with the change. Evidence over claims covers this in detail.
The trust ladder: how much autonomy to give
Guardrails tell you how to contain an agent. The trust ladder tells you how much to let it do. I sort every action an agent might take by two questions:
- How reversible is it? Editing a file in a branch is undone with one command. A sent email, a dropped table or a published package is not.
- How big is the blast radius? A change in a feature branch affects nobody. A change to main affects the team. A change to production affects customers.
Those two axes give four zones, and each zone gets a different level of autonomy.
Agent autonomy by reversibility and blast radius
Data as a table
| Item | Blast radius | How easy to undo |
|---|---|---|
| Edit files in a branch | Small | Easy |
| Run tests and builds | Small | Easy |
| Open a pull request | Small | Easy |
| Merge behind a flag | Large | Easy |
| Add a dependency | Large | Easy |
| Rotate a dev secret | Small | Hard |
| Run a prod migration | Large | Hard |
| Delete prod data | Large | Hard |
The rungs of the ladder follow from it. An agent climbs one rung at a time, and only on a track record.
| Rung | The agent may | Required guardrails |
|---|---|---|
| 1. Read | Read code, run read-only commands, propose a plan | Sandbox, no credentials |
| 2. Edit | Change files in its own branch or worktree | Sandbox, git as the undo button |
| 3. Execute | Run builds, tests and installs | Network allowlist, budgets, stop rules |
| 4. Propose | Open a pull request with evidence | Scoped token, evidence gate, independent reviewer |
| 5. Merge | Merge low-risk change types itself | Track record per change type, feature flags, fast revert |
| 6. Operate | Deploy or touch production | Rarely. Staged rollout, automatic rollback, a person on irreversible steps |
Many teams are stuck between rungs 2 and 3, approving every command by hand. The sandbox is what moves them up, because it makes rung 3 safe without a person watching. Rung 5 is where the real time savings are, and it is earned per category: dependency bumps with green tests can merge on their own long before database changes can.
Rung 6 stays mostly closed, and I think it should for a long time. Not because agents can’t run a migration, but because the bottom-right corner of the chart is where one mistake ends a company. The rule I use: the agent may do anything it or git can undo. Anything else, it prepares and a person executes.
Bad guardrails and good ones
Some guardrails feel safe and aren’t.
- Instructions in the prompt. “Never touch production” is a request, not a control. The Replit case is what happens when it is the only control.
- Approving every command. People stop reading after the twentieth approval. Approval fatigue is a guardrail that fails silently.
- One shared environment. If preview, test and production share a database, no permission rule saves you. Separate the environments first.
- Budgets without stop rules. A budget alone means the agent fails at the limit with no explanation. Pair it with a rule that parks the task early and says why.
- Blocking everything. An agent that can’t run tests or install packages in a sandbox can’t verify its own work, so it hands you unverified code. Too little autonomy produces worse output, not safer output.
The good ones share one property: they are enforced outside the model, and they make the safe path the easy one.
Why this matters more every year
METR measures the length of task an AI agent can complete half the time, and found it doubling about every seven months between 2019 and 2024, faster since. Claude 3.7 Sonnet was at about 50 minutes. If that trend holds even roughly, agents will soon run unattended for many hours, then days. Approve-every-command supervision doesn’t scale to that. Guardrails do.
That is the bold claim I’d make: the teams that get the most from agents over the next few years won’t be the ones with the best model. They will be the ones whose guardrails let them hand an agent a ticket at 6 pm and read a reviewed pull request at 9 am. Running coding agents overnight describes what has to be true for that. If you want this set up for your team, write to me.
Questions
What are guardrails for AI coding agents?
They are controls enforced outside the model that limit what an agent can do: permission rules for tools and commands, a sandbox with filesystem and network isolation, scoped credentials, budgets on time and tokens, stop rules and an evidence gate before merge. Instructions in a prompt are not guardrails.
How much autonomy should you give an AI coding agent?
It depends on how reversible an action is and how much it can affect. Let the agent freely do things git can undo in its own branch, add checks as the blast radius grows, and keep irreversible actions on production for a person.
Is a sandbox enough to make a coding agent safe?
No, but it is the most valuable single layer. It needs both filesystem and network isolation, and it should be combined with scoped credentials, budgets, stop rules and verification of the agent’s output before merge.
What is excessive agency in AI agents?
Excessive agency is OWASP’s LLM06 risk: an agent with more functionality, permissions or autonomy than its task needs. The fix is least privilege, meaning the agent only gets the tools and access the current task requires.
