Guardrails for agents: where to lock before it acts

Of 52 documented security failures in AI agents, 40 would have been preventable outright by harness layers. Three quarters.

None of them needed a better model. They needed a lock we already know how to build and that almost nobody builds.

The same survey carries the probable reason: research on training-time alignment outpaces research on runtime harness by 8 to 12 times. The cheapest layer of the system is the least studied.

This post covers where to put the lock, and why the most common recommendation, a classifier judging whether the action looks dangerous, solves less than it promises.

A guardrail is a control limiting what the agent can do, and it works without depending on the model agreeing. That last part is the whole definition: an instruction in the prompt covers the case where the model obeys; a guardrail covers the rest.

The controls split into two families.

Preventive ones act before execution: the list of available tools, input sanitization, permission gates, injection classifiers. Detective ones act during or after: execution tracing, anomaly detection, behavior profiling, output classification.

In practice, four points exist where the lock can go:

1. Before the call, deciding whether that tool even appears to the agent.
2. At the tool boundary, validating parameter and effect before executing.
3. On the output, filtering what returns to the context or to the user.
4. At the delivery gate, refusing the "done" without proof that it got done.

The fourth is the rarest and the cheapest, and I come back to it below. The four together form the harness's guardrail layer.

<!-- [UNIQUE INSIGHT] -->

Here is the distinction that changes the layer's design, and it comes from a paper of 11 August 2026: "Agent Safety Should Be a Runtime Contract", by Albus W. Ng, Yi Han, Jusheng Zhang and Wenhao Wang (arXiv 2608.11274, accessed 27 August 2026).

The authors separate two families of mechanism:

A classifier mechanism evaluates a semantic property. It reads the command, the surrounding context, and decides whether that looks dangerous. Since it depends on learned discrimination, it inherits the same fragility as the model's alignment.

A structural mechanism imposes an invariant regardless of the model's behavior. Sandbox, resource quota, least privilege by default. It depends on no classification accuracy, because it classifies nothing.

The consequence is practical. A classifier has to judge whether rm -rf build/ is acceptable, and the answer depends on what came earlier in the conversation. A structural lock judges nothing: it knows recursive deletion has no undo, and it treats them all the same.

The cluster has already shown that same line failing from the other side. In the post on why prompt injection has no definitive fix, adaptive attackers got past twelve published defenses, several of them classifiers, above 90% of the time. The mechanism is the same here: whatever gets decided by interpretation invites an argument.

Being fair to the classifier is worth it, because it has a place. It cuts the volume of trivial attempts, imposes a cost on the attacker and produces a record of what got stopped. It fails to deliver a guarantee. Content guardrails and execution guardrails solve different problems, and conflating the two is the error this post tries to undo.

One design detail of the category reinforces that. The six failure families content guardrails tend to cover are jailbreak and injection detection, personal data leakage, toxicity, topic policy, hallucination and format validation. Five are semantic. Only format validation is mechanical through and through.

Every lock charges a toll on the people doing it right, and that cost seldom enters the accounting.

In April 2026, a group at Beijing Caizhi Tech evaluated four commercial guardrails against 1,018 inputs reannotated by humans, sampled from eight public datasets (arXiv 2604.24826, accessed 27 August 2026).

The authors' own conclusion: even the best-performing guardrail still blocks around 10% of benign traffic by mistake.

The damage of a false positive stops nowhere near the friction. It trains the person. A guardrail that interrupts too much makes the operator approve without reading, and at that point the lock became theater, which is risk ASI09 on the OWASP list, the exploitation of human-agent trust.

Hence this post's explicit judgment: a lock with no false positive measurement is debt. Before choosing a commercial guardrail, take real traffic from your agent, run it through the options you are weighing and count what got stopped for no reason. The table above serves to guide the shortlist, and never to replace that test.

Almost every piece of writing on the subject ends in the same two sentences. Both have a documented failure mode.

A whitelist of commands

The idea is intuitive: the agent runs only what is on the list. The problem is that the list approves the command's name, and the effect depends on the environment it runs in.

CVE-2026-22708, in Cursor, showed that in production. In automatic mode with the whitelist active, shell builtins such as export and declare ran without appearing on the list, because the evaluator trusted them. Any text reaching the agent was enough to change environment variables in silence, and the approved command started executing something else. I told the whole case in the post on the ten OWASP risks.

Do this instead: a disposable environment. In a container with no credentials and no network, the effect of any command stays contained, regardless of whether its name is on a list. And taking the tool out of reach solves more than describing it as dangerous.

Human approval for everything sensitive

It works until the twentieth identical approval. After that, the operator approves without reading, and the false positive data explains why: a lock that interrupts often is a lock that teaches people to ignore it.

Do this instead: ask fewer times and show more when you ask. An approval displaying the exact command, what it changes and whether it can be undone is worth ten generic confirmations. For anyone on Claude Code, permissions and auto mode covers configuring that boundary.

Replace "does this look dangerous?" with three questions that have objective answers.

Can it be undone? It is the dominant criterion. A reversible action can afford to be wrong.

How far does it reach? Does it stay on the machine, hit the repository, or leave for the world and land on other people?

Does it cost money? A paid call, a provisioned resource, a consumed quota.

The rule coming out of the table is short: what cannot be undone is no option for the agent. Not an instruction asking for care, and not a confirmation it can interpret. It is the absence of the tool, or mandatory human approval.

Note that the reversibility column asks nothing about intent. That is why it works: arguing with a --force is impossible.

A note on the quota row. A spending limit is a structural guardrail, and almost nobody configures one. The loop repeating a cheap call is the pattern that surprises people most on the invoice, by the mechanism described in what each usage pattern costs.

The three cheapest structural locks

Sandbox sounds expensive. In the minimal version, it is not. The three locks below fit in an afternoon and cover most of the damage available.

1. A container with no credentials. The agent runs inside a container. The repository comes in mounted; the rest of the disk does not exist for it. Environment variables holding secrets stay outside. The gain is large and immediate: rm -rf remains possible and stops mattering, because what it erases is disposable.

2. A minimal-scope, short-lived credential. The agent gets an account of its own, with access only to what the task needs. A token expiring in hours is worth more than a permanent token with broad scope. This is the lock that would have prevented the Vertex AI case, where an over-privileged service account allowed credential theft.

3. A spending ceiling. A hard limit on the API account, configured at the provider and not in the code. It costs five minutes. It is the only lock on this list protecting against a mistake of yours rather than an attack: the loop repeating a cheap call carries no bad intent.

None of the three depends on the model understanding anything. That is their whole point.

If you can do only one, do the third. It is the fastest and it prevents the most common loss.

The cheapest control on this list is also the rarest. Of the 12 public agent systems audited in the August paper, only 2 demand proof that the safe action happened before accepting the delivery.

The idea is direct: the agent does not declare that it finished. It presents evidence that it finished, and the gate checks.

In an audit of 32 false-completion cases, what would have solved them were evidence gates of four kinds: test execution, log capture, file diff and source citation.

The difference from the previous layer is subtle and important. The verification loop runs the test. The evidence gate refuses to accept the delivery without the test result attached. One produces the signal; the other makes the signal mandatory.

Without the gate, the agent that skipped verification and the agent that passed it deliver the same sentence: "done". With the gate, one of the two cannot deliver.

In practice this tends to be simpler than it sounds. The gate demands that the delivery include the output of the verification command, with the return code. No summary, no "the tests passed" written in prose. The raw output, or it does not pass. Once you have to paste the evidence in, the agent has no way to claim it ran something it never ran.

<!-- [PERSONAL EXPERIENCE] -->

The operation publishing this blog has this today: human confirmation for an irreversible action, no push without explicit authorization, no publication without the sixteen-item checklist, and permissions declared per tool.

Said in full, here is the gap: there is no sandbox. The agent runs with write access to the whole repository, with no container and no resource quota.

The lock protecting me today is the one in the table's first column: almost everything it touches sits under git, and can be undone. That is a conscious choice and no architecture. In a repository with a secret in a file, with automatic deploy on push or with access to a production database, that design would fail, and it would fail fast.

On the evidence gate, the change is recent and it was born from a loss. A bug in a title field passed tsc, the nineteen tests and next build without a single warning, and it showed up only when I opened the generated HTML and counted the characters. Before that, I accepted "done" accompanied by "the build passed". Now the delivery has to arrive with the character count of the rendered title. It is an evidence gate under another name, and it exists because a delivery that passed everything had already fooled me.

The guardrail layer is the easiest one to fake. It exists in the diagram, nobody tests it, and everyone assumes protection. Four numbers settle that.

Blocks reverted by hand. Every time someone works around the lock to keep going, that is a false positive under another name. If the number rises, the lock sits in the wrong place. If nobody ever works around it, chances are it stops nothing.

Time between the approval request and the click. It is the fatigue indicator, and it carries a brutal kind of honesty. An approval granted in two seconds went unread. Once the median drops, the lock became a formality.

Irreversible actions executed without passing a gate. This one should be zero. Measuring it demands a record of what got executed, and it is the question that reveals locks that existed only in the document.

Deliveries accepted with no evidence attached. If the delivery gate exists, that number tends to zero on its own. If it does not exist, the number is 100% and nobody had noticed.

The first two measure friction. The last two measure coverage. A healthy layer keeps the first two low without hitting zero, and the last two at zero.

None of that needs a new tool. It needs logs, the subject of the next layer.

What are AI guardrails?

They are controls limiting what an AI system can do, and they work without depending on the model cooperating. They split into preventive ones, acting before execution (tool lists, permission gates, sandbox), and detective ones, acting during or after, such as execution tracing and output classification. The difference from an instruction in the prompt is that the instruction covers the case where the model obeys, and the guardrail covers the rest.

What is the difference between a guardrail and a permission?

A permission is one form of guardrail, and it deals with who can do what. The guardrail concept is broader and includes limits unrelated to identity: spending quota, execution sandbox, format validation on the output, a delivery gate demanding evidence. In practice, permission answers "does this agent have the right?" and the structural guardrail answers "is this action acceptable, whoever it comes from?".

Do I need human approval for everything?

No, and trying that tends to make security worse. Frequent approval trains the operator to approve without reading, which is risk ASI09 on the OWASP list. The useful criterion is reversibility: an action that can be undone needs no approval, and an irreversible action always needs one. Fewer interruptions, with more information in each, protects more than confirming everything.

Does a guardrail get in the way of the agent's work?

It does, and that is measurable. In the evaluation of four commercial guardrails published in April 2026, none passed 90.4% of legitimate traffic approved, meaning at least one in every ten benign requests got stopped. So the recommendation is measuring false positives with real traffic before adopting, and preferring structural locks, which never err on an ambiguous case because they interpret nothing.

Do I need a sandbox even on a personal project?

It depends on one question alone: what exists on that machine that you could not rebuild? A repository under git, with everything committed and pushed, is safe territory, because reversibility is already handled. An API key in a config file, a local database with no backup, a documents folder and a cloud credential with broad scope are not. If the agent reaches any of those, the container stops being overkill. And the spending ceiling at the provider holds in any scenario, personal project included, because it protects against a mistake of yours and takes five minutes.

Are Llama Guard or NeMo Guardrails worth using?

They are worth it for what they solve, which is content security: moderation, topic policy, detection of known attack patterns. Neither replaces execution control, because judging whether a text is acceptable and preventing an irreversible action are different problems. The sensible combination uses a classifier to cut volume and a structural lock to guarantee what cannot happen.

• 40 of 52 documented agent failures were preventable outright by harness layers. The cheapest layer is the least built.
• A classifier decides by probability, and an argument can move it. A structural lock decides by fact and holds even when the model disagrees.
• Even the best guardrail evaluated stops around 10% of legitimate traffic. A lock with no false positive measurement is debt.
• A whitelist approves the command's name, and not its effect. A disposable environment approves the effect.
• Anything that cannot be undone is no option for the agent.
• Only 2 of 12 systems demand evidence before accepting the delivery. It is the cheapest control there is.

That closes the four layers nearest execution. The next post in the cluster covers the fifth, the one that answers what happened in fact: agent observability. The full map sits in the pillar on harness engineering.