Agent Guardrails: Limits First, Approval Gates Second

Agent guardrails are action limits and approval gates that decide what an agent can do before it acts, not a human review after.

Agent guardrails are the action limits and approval gates that decide what an autonomous agent can do before it acts, not a human checking the output after. They scope which tools an agent can touch, cap how far it can go before something forces a stop, and decide which actions need a checkpoint first. Get the gates wrong and you build one of two systems: an agent too boxed-in to do its job, or a reviewer who stops reading and starts rubber-stamping.

I have shipped agents with both failure modes, usually in the same quarter. One version put a human in front of every action, and the reviewer went from careful to skimming to clicking approve without opening the diff. The other removed the gate to fix that bottleneck, and the agent reached a resource it had no business touching. Neither failure was a model problem. Both were a guardrail design problem, and the fix was the same: stop treating "a human checks it" as the control, and start scoping the action itself.

A guardrail decides before the agent acts. A human review decides after, and after is a report, not a control.

Key takeaways

Agent guardrails are action limits and approval gates that decide before the agent acts, not a human review that catches problems after the fact.
Anthropic's own agent-design guidance recommends stopping conditions, such as a maximum number of iterations, specifically because agentic systems carry higher cost and compounding-error risk.
OWASP names the no-guardrail failure mode directly: "Excessive Agency" (LLM08), the risk of granting an LLM unchecked autonomy to take action.
Claude Code's permission system is a working example of action limits in production. It evaluates every rule in a fixed order, deny, then ask, then allow, and exposes a hook so a team's own approval logic can run before any tool call executes.
Approval gates scale badly when every action gets one. The design question is which actions are cheap to undo and which are expensive or irreversible, not whether to add a human.

This sits one layer under the question I get asked most in architecture reviews on when to split one agent into many: once you decide an agent, or a fleet of them, gets to act on its own, guardrails are what decide how far "on its own" goes.

What are agent guardrails?

Agent guardrails are the action limits and approval gates that constrain what an autonomous agent is allowed to do without a human checking first. An action limit scopes which tools and actions the agent can reach at all: allow, ask, or deny. An approval gate decides which of the allowed-but-risky actions still need a checkpoint before they run. Together they answer one question for every action an agent can take: does this run on its own, does it wait for a yes, or does it never run at all?

That framing matters because most teams reach for one lever: put a human in the loop. A human in the loop is one possible approval gate, not the whole guardrail system. OWASP's Top 10 for LLM Applications names what happens when a team skips the rest: "Excessive Agency" (LLM08), the risk that "granting LLMs unchecked autonomy to take action can lead to unintended consequences, jeopardizing reliability, privacy, and trust" (OWASP LLM Top 10).

Why "a human reviews it" isn't a guardrail

This is where most agent rollouts drift into a false sense of safety. "A human reviews it" describes a step in a process. It does not describe a mechanism that decides, ahead of time, what the agent is even permitted to attempt. A reviewer shown a risky action after the agent has already drafted it is doing quality control, not access control.

Picture a support agent that can issue refunds. Every version of this I have seen starts the same way: a person reads every refund before it goes out. That works while volume is low, and each one gets a close read. It stops working once volume climbs, because the reviewer's job quietly shifts from "catch the bad refund" to "clear the queue," and those are different jobs with different failure rates.

Action limits: scoping what an agent can touch

An action limit is the first line of defense; it runs before any approval gate does. It answers a narrower question than "can a human catch this": can the agent reach this tool, this table, this endpoint, at all? Three buckets cover almost every action an agent can take.

Allow. The agent runs this action with no checkpoint. Reserved for actions that are cheap, reversible, and low blast radius: reading a record, drafting a reply, running a read-only query.
Ask. The agent can attempt this action, but a checkpoint, human or automated, has to say yes first. Reserved for actions that are expensive, hard to reverse, or reach outside the agent's own sandbox.
Deny. The agent never sees this action as an option. Reserved for anything it should not be able to attempt under any circumstance, no matter what a prompt tells it to do.

Take a support agent wired to a customer database. Reading order history is an allow: cheap, reversible, no blast radius beyond a query. Issuing a refund above a set dollar threshold is an ask: real money leaves the business, and reversing it means a second transaction and a ticket. Deleting a customer record is a deny: the agent should never reach that action, regardless of how convincingly a message asks for it.

The scoping decision, not the review decision, shrinks the agent's blast radius. Get the buckets right and most requests never need a human at all; the few that do are worth a person's attention.

If you are still mapping which actions in your own system belong in which bucket, an AI engineering team that builds agent permission systems for a living can run that classification against your real traffic before you ship it, not after an agent does something you have to explain to a customer.

The gate is not there to make the human feel involved. It is there because the action is expensive or hard to undo.

Approval gates: deciding which actions need a checkpoint

Once action limits sort "ask" out from allow and deny, the approval gate question gets narrower and more honest: which of these already-risky actions is worth a person's time, every single time?

The test that holds up is reversibility, not risk in the abstract. An action that is expensive or hard to undo earns a gate. One that is cheap to undo, even if it looks alarming on paper, usually does not, because the cost of the gate, latency, reviewer attention, the eventual rubber stamp, can exceed the cost of occasionally getting it wrong and fixing it.

An infrastructure agent that restarts a service is a fair allow or ask depending on blast radius: restarting a stateless service is reversible in seconds. The same agent dropping a database table is a different category: expensive, slow to reverse if a backup even exists, worth a real checkpoint every time, with no "don't ask again" exception. Two actions, one agent, two gates, because the cost of being wrong is not the same.

Permission modes in practice: Claude Code's allow, ask, deny

Claude Code's own permission system is a working, documented version of this model, worth studying even if you never touch the tool. It evaluates every rule against a fixed order: deny, then ask, then allow. The first matching rule wins, and specificity does not change that order; a broad deny always beats a narrower allow (Claude Code permissions docs).

# Roughly what a permission rule set looks like

deny: Bash(rm --rf *), Read(secrets/**)

ask: Bash(git push *), Edit(prod/**)

allow: Read(src/**), Bash(git status)

# evaluation order: deny > ask > allow, always

It also ships several permission modes, from one that asks before nearly everything to one that skips prompts entirely. For teams that want their own logic in the loop, it exposes a hook that runs custom approval code before any tool call executes, the automated version of an approval gate: a checkpoint with no person watching in real time.

Stopping conditions: iteration caps, spend caps, timeouts

Action limits and approval gates both answer "what can this action do." Stopping conditions answer a different question: how long does this agent get to keep going before something forces a stop, regardless of what any individual action looked like. Anthropic's own guidance on agent design is explicit about why this layer exists: agents should "pause for human feedback at checkpoints or when encountering blockers," and it is "common to include stopping conditions (such as a maximum number of iterations) to maintain control" (Anthropic engineering blog).

The reasoning is specific, not general caution. Anthropic notes that the autonomous nature of agents means higher cost and the potential for compounding errors, and recommends extensive testing in sandboxed environments alongside the guardrails themselves. A single wrong tool call rarely sinks a run; a dozen in a row, each compounding the last agent's mistaken belief about the world, usually does.

Three stopping conditions cover most production agents:

Iteration cap. A hard ceiling on how many tool calls or reasoning loops a single task gets before it stops and hands control back.
Spend cap. A dollar or token ceiling per task, so a stuck agent fails loudly on cost before it fails expensively on cost.
Timeout. A wall-clock limit, because a hung agent retrying the same failed call for an hour is a cost and an availability problem even when every individual call was within its permission.

The failure mode: approval fatigue and rubber-stamping

Every guardrail design eventually runs into the same honest trade-off. Approval gates feel safe, and they scale terribly.

Gate every action and the reviewer becomes a bottleneck, then a habit of approving without reading, then a liability that gives you false confidence while the real risk passes through unchecked.

I have watched a review queue go from reading every diff to skimming for anything obviously wrong to approving unless something jumped out, inside a single sprint, once volume passed what one person could carefully read. Nobody decided to lower the bar. The queue decided it for them.

The fix is not a better reviewer or a nicer approval screen. It is fewer gates, aimed better. Every action that reaches a human should be one the human needs to see: expensive, hard to reverse, or genuinely ambiguous. Everything else belongs in allow or deny, decided once at design time, not re-litigated on request four hundred of the day.

None of this gets simpler once an agent stops working alone. Coordination patterns like supervisor, pipeline, and swarm multiply the number of places an action limit has to hold, and every handoff is a place a permission correct for one agent gets misapplied to another. I go into that handoff-specific failure mode in how agents hand work to each other, because a guardrail built only for a human calling the agent has a gap from day one.

A guardrail checklist before you ship an autonomous agent

Run this before you give any agent standing permission to act without a person watching every step:

Every action is classified allow, ask, or deny before the agent's first real run, not discovered by watching what it tries to do.
Every "ask" action has a stated reason: expensive, hard to reverse, or ambiguous. If you cannot name the reason, it probably belongs in allow.
Iteration, spend, and timeout caps exist for every task type, sized to what a stuck agent could plausibly do in that window.
Deny rules cover the truly irreversible actions, regardless of what any prompt asks for.
Someone owns the review queue's volume, with a plan for when volume outpaces careful review.
The guardrail configuration is tested like code, with a case proving the deny rules block what they claim to block.

Frequently asked questions

What is the difference between agent guardrails and human-in-the-loop review?

Agent guardrails are the action limits and approval gates that decide, ahead of time, what an agent can attempt. Human-in-the-loop review is one possible mechanism inside an approval gate, the checkpoint a risky action waits on. Guardrails still work with no human step, through automated checks and deny rules. A human-in-the-loop step with no underlying action limits is not a guardrail; it is a person reviewing whatever the agent happened to show them.

When should an AI agent require approval before it acts?

Gate an action when it is expensive or hard to reverse, or when the agent's confidence in its own read of the situation is genuinely low. Do not gate an action because it sounds risky in the abstract. Reading a database is not the same risk as writing to one.

Do approval gates slow autonomous agents down too much to be useful?

Gating every action does. Gating only the actions that are expensive or hard to reverse usually does not, because most of an agent's actions turn out to be cheap to undo once sorted correctly. The slowdown people blame on "approval gates" is almost always a scoping problem: too many actions routed to ask when they belonged in allow.

How do you stop an AI agent from taking an irreversible action by mistake?

Put the irreversible action in a deny rule, not an ask rule. An ask rule still depends on someone paying attention the moment it fires, and approval fatigue is exactly what lets an irreversible action through on a tired click. A deny rule removes the action from what the agent can attempt, regardless of how the request is worded.

Where this leaves you

Agent guardrails are not a single control bolted on before launch. They are three decisions made in order: which actions the agent can reach, which need a checkpoint, and how long it runs before something forces a stop regardless. Get the order right, and most of what looks like a human-oversight problem turns out to be a scoping problem you can fix at design time.

I go deeper on building the evaluation and permission layer that keeps an agent's autonomy honest past the demo, in my book Agents That Actually Work. Read it before you hand an agent standing permission to act without you watching.