AI Agent Guardrails: A Deterministic Layer the Prompt Can't Be

AI agent guardrails are checks that run in code around the model and decide whether an action happens: a cap inside a tool, a scoped credential, a budget on the loop, an approval gate. A rule in the prompt is a request the model usually honors. One question sorts every candidate: can text argue with it?

I wrote this for a backend engineer holding a ticket that says “add guardrails to the agent.” The AI agent guardrails in this post have no attacker to catch. The model is wrong once in some number of runs, a task drifts, or a loop won’t end, and the question is which code refuses, caps or stops it and how you know that code works. The attacker’s side of the story is in the companion post on how to prevent prompt injection in AI agents.

Does a rule in the system prompt count as a guardrail?

No. A rule in the system prompt is text the model reads and weighs on every pass, and no code halts the run when the weighing goes the wrong way. Chapter 17 of the book (in the full book), in the section “Guardrails as a Separate, Deterministic Layer,” asks what enforces three such sentences and answers: “There is no interpreter that halts on violation, no permission system consulting your list.”

The same paragraph lists how the request fails, and two of the three ways need no adversary. The model can “drift from it under a hundred turns of accumulated context, or simply draw an unlucky sample on an ordinary afternoon.”

One public case shows the shape. According to a press report of a user’s own posts (The Register, July 2025), a coding service deleted his production database “despite his instructions not to change any code without permission.” Later, after trying to have the service freeze code changes, he wrote that there was “no way to enforce a code freeze” in apps of that kind. He also wrote, “you can’t not separate preview and staging and production cleanly.”

Keep the rule in the prompt, because it is free to write and can lower how often the model tries. Then apply the sorting question, which is this post’s own formulation: when the rule is violated, which code refuses or halts, and can any text the model reads change that? A freeze that is a sentence fails the test. A freeze that removes the write tools from the run passes it.

What does “AI agent guardrails” mean, and to whom?

The phrase “AI agent guardrails” has no standard meaning, so ask what the speaker includes. The book’s definition is the one this post uses, and it carries a tension worth reading closely: “A guardrail is the field’s answer: a check that lives outside the model’s reasoning and runs deterministically, whatever the model has decided.” The next sentence widens it: “Concretely it is ordinary code—or, as we will see, occasionally a second, separate model—stationed at the agent’s boundaries, examining what passes and empowered to allow it, block it, modify it, or escalate it to a person.”

I read the two sentences as naming two properties, and the chapter supports the reading a few paragraphs on, where it says of a model-based guard that “its verdicts are probabilistic.” What runs deterministically is the checkpoint: it sits outside the model, it always executes, and its verdict binds. Whether that verdict is certain depends on who renders it: code, a model or a person. A guardrail in this post means the first property, and the inventory below marks each row with the second.

Other sources draw the line elsewhere. One lab’s guide to building agents (2025) describes an agent’s instructions as “Explicit guidelines and guardrails defining how the agent behaves,” and it places authorization outside the word: guardrails should be coupled with “authentication and authorization protocols, strict access controls, and standard software security measures.” The OWASP entry on excessive agency (LLM06:2025) doesn’t use the word in its guidance and requires the control: “Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.”

Is a guardrail library or product enough?

For an agent, no. A product that inspects text going into and out of the model covers the layer the book ranks below the tools: “Prose is recoverable; an apology retracts a bad sentence.” The destructive call in the incident below was authenticated and looked ordinary, and I read nothing in the write-up that a content check would have flagged. When a vendor says “guardrails,” ask whether authorization, tool limits and budgets are inside the word.

Which AI agent guardrails exist, and can text argue with each?

The table lists nineteen candidate AI agent guardrails with where each is enforced, whether text can argue with it, what it costs and how to test it. Two rows are on it to be classified: the system-prompt rule, which is a request, and the log, which detects and stops nothing.

In the fourth column, which applies the second property, “No” means code renders the verdict and no sequence of tokens can change it; it still depends on the check being built, configured and wired in correctly, like any access control. The cost and test columns are my judgment except where a source and year are named.

The last column says which of five harms the row is aimed at, and the buttons filter on it; the two rows that are there to be classified carry all five tags, so they stay visible under every filter. A wrong action is a call outside what the task or user authorized. An unsafe write is a destructive, irreversible or externally visible change. A data leak is data leaving its boundary.

Runaway cost is a loop, retry storm or fan-out that spends without converging. Bad output is text that is malformed, off-policy or unsupported. Injection is deliberately absent from the list: it is a cause that can produce any of the five, and the checks here don’t need to know the cause.

Which of your backend instincts carry over?

Most of them carry over, with one change that repeats down the list: the caller you are constraining is a model whose requests are plausible and occasionally wrong, so every check has to work without the caller’s cooperation. The mapping is mine.

Where does each check go?

Start with what the agent can reach at all, then put each check as close to the side effect as it will go: five places, in order. The ordering is this post’s synthesis; the book supplies the principle, “put the check next to the side effect,” and OWASP supplies the second step.

1. The process boundary. What the agent’s process can reach at all: a sandbox with no production credentials inside, a gateway in front of its calls, and the operator’s stop.

2. The downstream system’s own authorization. A scoped credential, a row-level policy and an undo window hold for every caller, including an agent that goes around your code.

3. The tool. Argument limits, identity arguments filled from the session (tenant, user, account, environment), quotas and a timeout live in the function that causes the side effect.

4. The harness. The harness (the code around the model that runs the loop) owns the tool allow-list, the approval gate, the budgets and the trip counter. Checks on what goes into the model and what comes out run here too.

5. A model or classifier, last. Use one where code can’t decide the question, never as the only check in front of a side effect, and make it finish before the action starts. One agent framework’s documentation (undated; read October 2026) says of an input guard that runs in parallel with the agent: “the agent may have already consumed tokens and executed tools before being cancelled.”

What happens when the downstream check is missing?

The agent’s mistake executes at once and nothing in the path can take it back, and one documented incident shows how. In April 2026 an AI agent deleted a production database volume, and the infrastructure provider’s own write-up says what the agent did: it found one of the provider’s API tokens “stored locally on the user’s machine” and called the delete operation directly. The write-up says “The request was authenticated, and our API honored it the same way it would for a CLI command or a CI pipeline,” and that the agent “wasn’t told to delete a database. It decided that deletion was a reasonable step toward fixing something unrelated.”

The provider names two missing controls. The token “was provisioned with account scoped access, the maximum access possible,” and the delete call ran “immediately, with no way to undo it” while the dashboard gave the same action a 48-hour window. The call also “performed a cascading delete on the model, making the backups look unavailable in the UI.” Its first fix was a soft delete for 48 hours on every delete; it also delayed the deletion of backups and said it would look again at how token scopes are presented.

By its own account the provider has since recovered the database; the customer’s public account differs on the details of the recovery, so I have used only what the write-up states. On my reading of that account, the process boundary was the only place on the customer’s side that would have been in the path, because the agent used a token it found on disk and never went through a tool. The provider’s summary generalizes: “make the destructive thing slow, make the recoverable thing fast, and put the actual point of no return as far away from a single click as possible.”

How do you stop an agent deleting, sending or spending?

Combine three things: limits inside each write tool, an approval gate on the few actions that are irreversible or high-stakes, and budgets with a stop path for runs that won’t end. The first is the top four rows of the inventory: limits in the tool, the tool list, the credential and the identity arguments. The other two follow.

How do you add approval gates to AI agents without wearing them out?

Gate by what the action costs when it is wrong. Chapter 12, Oversight and Autonomy (in the full book), in “Approval Gates and Escalation,” sorts everything an agent can do into “consequence tiers—read-only, reversible, externally visible, irreversible” and assigns oversight in four sentences: “Read-only actions run without ceremony; gating them buys no safety and teaches the person approving them to stop reading. Reversible actions run freely too, provided the system logs enough to undo and audit them. Externally visible actions, anything a third party will see, deserve a review queue. Irreversible or high-stakes actions wait for a signature, every time.”

An approval gate is a guardrail only if its trigger is code: “the gate must live in your code, never in the agent’s judgment.” Keying approval gates to consequence has a corollary teams skip: “the agent’s confidence plays no part in it.”

What does the classifier show for six actions?

It shows three signatures, one queued review and two actions that run. The classifier below opens on six actions from three agents: a support agent that looks up an order, drafts a reply, sends it and issues a refund; a coding agent that deletes files; and an agent that emails a customer list. The team’s current rule is “ask a human when the agent is less than 80% sure,” so no action is gated for what it is.

issue_refund, delete_files and email_customer_list land in tier 4 (“signature, every time; sync block”) because I answered yes to the tool’s question “Does it move money, delete data, or touch the public?” I counted a send to a whole customer list as touching the public. One reply to the customer who wrote in, send_reply, is tier 3 and goes to a review queue; draft_reply is tier 2 and runs with a log; look_up_order is tier 1 and runs with no gate.

The classifier also raises three warnings: tier 4 actions run with no signature today, an externally visible action reaches a third party with no review, and the current rule mentions the model’s confidence.

Now rebuild delete_files so that it only moves version-controlled files into a restorable trash. The honest answers change to “no” on the second question and “yes, and it’s logged to undo” on the question about undoing the change, and the classifier moves it to tier 2.

The tool’s questions do not ask about availability: a reversible change that can take production down is high-stakes, and I would answer yes to the second question for it.

Why not ask for approval on everything?

Because approval is a guardrail whose weakness has been measured, and the vendor that measured it says attention falls as prompts multiply. One vendor reported that users of its coding agent “approved roughly 93% of permission prompts” (company telemetry, no sample size given; Anthropic, 2026). A public browser game in which players approve or deny an agent’s commands logged “over 40,000 runs and 409,000 individual approve/deny decisions,” and “The average player missed 1 in 3 threats,” a miss being an approved command the game counts as a threat (Wauters, August 2026). The author adds his own caveats: about 34% of the commands shown were threats, far above daily work, and players were on a clock.

Replacing the person with a model has its own numbers. One vendor’s classifier that approves tool calls in place of a human wrongly blocked 0.4% of 10,000 real tool calls from its own employees and let through 17% of 52 real overeager actions, and its authors write that it “is not a drop-in replacement for careful human review on high-stakes infrastructure” (Anthropic, March 2026). The vendor ran the study on its own product.

What budgets should a run have?

A run should have several at once: steps, tokens, wall-clock time and money. Chapter 3, The Agent Loop (in the full book) defines the term in “Stop Conditions, Budgets, and Frameworks”: “A budget is a hard ceiling enforced by the harness, indifferent to the model’s opinion.”

Read the cap from your own traces; the agent cost per task estimator shows how re-read history and retries multiply the tokens in one run. When a budget fires, the instruction is “Fail loudly”: save the transcript and say the run was stopped.

A budget checked between model calls can’t end one tool call that hangs, so each call needs its own timeout. Chapter 18 says it in five words: “Give every call a deadline.”

What is an AI agent kill switch, and where does it live?

A kill switch is, in the words of Chapter 13, Writing the Outer Loop (in the full book), “one obvious, fast, tested way to stop every running loop and agent at once.” The book doesn’t say where the switch lives.

The placement is this post’s point: put it outside the agent’s own process. A stop that depends on the agent reading a message, or on a handler inside a wedged process, fails in the cases it exists for. An orchestrator that stops scheduling steps, a gateway that refuses the agent’s calls and revocation of its credential all work without the agent’s cooperation. Each stops the next step; a call already dispatched keeps running unless the downstream system is cut off too.

Pair the manual switch with an automatic one. The vendor whose action classifier is measured above stops a session after “3 consecutive denials or 20 total” (Anthropic, March 2026), which is a breaker on guard trips.

What does a guardrail spec for one tool look like?

It is one page per write tool that says what refuses a bad call, where that code lives and which test proves it. Paste it into the pull request and treat every empty line as work that remains.

GUARDRAIL SPEC: [tool name], [owner], [date]

1. What the tool may do
   - Changes: [what state, in which system]
   - Worst single call if every argument is wrong: [...]
   - Not offered at all: [operations left out of the tool]

2. Limits enforced in code (file and function for each)
   - Process boundary: [what the agent's process can reach; which
     credentials are absent from it]
   - Downstream: credential [name], scope [...], lifetime [...]
   - [argument]: [type, allowed range or allowed set]: enforced in [...]
   - Quota: [n] calls per run, [n] per user per day: enforced in [...]
   - Timeout per call: [n] seconds: enforced in [...]

3. Identity arguments set by code from the session, never by the model
   - [tenant / user / account / sender / environment]: read from [...]

4. Consequence tier and approval
   - Tier: [1 read-only | 2 reversible | 3 externally visible |
     4 irreversible or high-stakes]
   - If the tier depends on the arguments: the rule in code that
     decides, or "treated as its worst case"
   - Gate: [none | log for undo | review queue | signature every time]
   - The approval is bound to: [exact arguments shown to the approver];
     any change to them forces a fresh decision
   - What the approver sees is rendered by code from the arguments,
     never the model's summary
   - The approval is verified by: [the tool, checking a token bound to
     the arguments | the harness only]
   - Undo path and window: [...] or "none"; the agent's credential
     cannot delete the undo copy

5. Budgets this tool draws on
   - Run: [steps], [tokens], [wall-clock], [money]
   - Retries: [n] per call, only with idempotency key [how derived];
     counted against the run's single retry budget
   - Outcome unknown (timeout on a write): [read back | escalate];
     never resend without the key

6. What happens on a trip
   - Check refuses: [halt the run (default) | specific error returned
     to the model, for a limit the model can satisfy]
   - Check throws or times out: block. Never continue.
   - Model retries allowed after a fed-back refusal: [n], then halt
   - Run halts after [n] consecutive or [n] total guard trips

7. Stop path
   - Who can stop this tool, and how: [flag, gateway rule, credential
     revocation]; it lives outside the agent's process
   - A call in flight when the stop fires: [completes | rolls back |
     needs manual repair]
   - Time to halt, last measured: [...] on [date]

8. Tests that prove each guard (no model in the loop)
   - One negative case per limit in section 2: expect a refusal
   - Another identity's id in a model-filled field: expect it ignored
   - The check made to throw: expect the call blocked
   - A tool that hangs: expect the timeout to end the call
   - A stub model that repeats the call: expect the budget to stop the run
   - A tier 3 or 4 call: expect it held until a person decides, and a
     changed argument to void the approval
   - Undo: perform the action, then restore within the window
   - The production configuration loads every guard above

9. Model-based checks in front of this tool (not counted above)
   - [classifier or judge]: false-block rate [...], miss rate [...],
     measured on [n] labeled cases on [date], or "not measured"

10. Log fields: [tool, arguments with secrets and personal data
    redacted, prior value or undo handle, verdict, which guard
    tripped, approver]

How do three real actions come out?

Here are three write actions from the classifier, one of them below the signature tier, each walked through the inventory, the five places and the spec. The answers are illustrative.

Halting is the default. Chapter 3 lists “a guardrail trip” among the events where “the safe response is to halt it, loudly,” and the error table in this site’s post on idempotent tools and safe retries says the same. Chapter 17 allows feedback for “the milder trips (an output that failed groundedness, a malformed schema),” with capped retries, which covers the reply’s body.

Feeding one over-cap refusal back is my exception, for a limit the model can satisfy by asking for less. A trip here means a refusal by a limit, a policy check or an output check. Every trip counts toward the trip counter whether or not it was fed back, and a malformed argument is an ordinary tool error that counts for nothing.

What do AI agent guardrails cost?

AI agent guardrails that are ordinary code cost engineering time and some refused edge cases; model-based checks cost an inference each and bring two error rates; approval costs attention. The book doesn’t soften it: “Every check adds latency; every model-based check adds an entire additional inference, in both time and money, to every request it examines.”

For classifiers, a 2025 preprint from one vendor reports that its jailbreak classifiers raised refusals by 0.38 percentage points on a random sample of 5,000 of its own production conversations and added 23.7% inference overhead (Sharma and colleagues, 2025).

False blocks compound over a run, and this arithmetic is mine and illustrative. If each of k guarded steps is falsely blocked with probability f, and the steps are independent, a clean run finishes untouched with probability (1 − f)^k. At f = 0.4% and 30 steps that is about 89%; at 8.5%, the false-block rate that vendor’s 2026 evaluation reports for its first stage alone, about 7%. A guard on every step needs a far lower false-block rate than a guard on one chat turn.

Fail-closed has a price too. The book’s rule is “The failure default must be to block or escalate, never to wave through,” which turns an outage of the guard into an outage of the agent for the actions behind it. I accept that for writes; for a read-only path, fail open only if a wrong answer there cannot lead to a write later in the run.

How do you test a guardrail?

Test each deterministic guardrail as ordinary code with no model in the loop, and measure each probabilistic one on labeled examples.

• Negative cases that must be refused. One per limit: the amount over the cap, the other tenant’s id, the unlisted tool name. Call the tool or the dispatcher directly.
• A forced failure. Make the check throw or time out and assert the call is blocked, which proves the guard fails closed. Make the tool hang and assert the timeout ends the call.
• A loop that must stop. Stub a model that requests the same tool forever; assert the budget ends the run, the trip counter ends it sooner when the tool refuses, and the output says “stopped.”
• A wiring test. Assert the production configuration loads every guard.
• The gate and the undo. Assert a tier 3 or 4 call is held until a person decides and that a changed argument voids the approval. Perform the action, then restore it within the window.
• Canary fields. Chapter 17’s canary field is a schema field “constrained to be empty,” so a response that fills it fails validation.

A probabilistic guard gets the report format that 2026 evaluation used: sample sizes, a false-block rate on real traffic and a miss rate on real cases. Introduce one the way you would any risky change, as a shadow deploy followed by a canary: log what it would have blocked, read the log, then enforce for a slice of traffic, which is the canary rung.

For the stop path, I suggest a drill on staging: trip the kill switch mid-run, measure the time to halt, and check that nothing is half-applied.

What do guardrails not fix?

Guardrails don’t shrink what a permitted action can destroy, they don’t catch a wrong action that is inside every limit, and some of their costs are unmeasured. Whether the agent should hold the tool at all is a question about the blast radius of an AI agent, and no check answers it.

In-limit harm is the second. A cap of fifty permits any number of wrong refunds of forty-nine unless a quota exists, and a quota permits its own total.

Signatures are where the layer costs more than it saves. By the tiers the book adopts, every refund waits for one, and a desk that issues many a day will produce the fatigue the measurements describe. The book’s own note calls the tier boundaries “judgment calls.” A team that lets small refunds run on a cap, a daily quota and a log has made the tier depend on the amount, and should put that rule in code and write down the loss it accepted.

Three things are unmeasured as far as I could find: the latency of deterministic guards in a neutral source, approval rates across more than one product, and any independently verified cost runaway, where the public record I found is self-reports.

Three things to build first

For the ticket that says “add guardrails,” build these three first, in the order of the five places. First, keep production credentials out of the agent’s process, then a scoped credential and an undo window in the downstream system, then limits inside every write tool, each proven by a negative test. Second, budgets on the loop, a timeout on every call and a stop outside the process, proven by a stub model that loops and a drill on staging. Third, a signature gate on tier 4 actions only, with tier 3 in a review queue, triggered by code and proven by a test that the call is held and the approval binds to the exact arguments.

For every sentence in your prompt that begins with “never,” some line of code should be able to say no.

Chapter 17, “Security, Safety, and Guardrails,” develops the four families, fail-closed and the cost of the layer (in the full book); Chapter 3, The Agent Loop (in the full book) covers stop conditions and budgets. The AI agent security guide places this post beside its neighbors, or you can see the formats.