AI Agent Guardrails: Never Detect What You Can Forbid

AI agent guardrails only hold when the dangerous action is impossible, not merely disapproved of. A validator model returns a probability; scoped credentials and allowlisted tools return a guarantee. Put the guarantee underneath the probability, never the other way round.

Our position at LeapForce cuts against how most teams build right now. Adding a second model to judge the first is the best thing to happen to agent safety in two years, and the worst place to stop. A judgement is not a boundary. The day the judge is wrong is the day you learn which one you built.

The frustration is easy to find. On Hacker News in March 2026, a developer reading a coding agent's permission file asked the question that ends every deny-list conversation: "Are we really supposed to list all potential variations of harmful commands?" (gawa, Hacker News, 27 March 2026). Not rhetorical. They had counted the ways to read one file and given up.

The short answer: Sort every action your agent can take into four classes by reversibility, reach and taint; forbid the irreversible class outright at a scoped credential; and use a validator model only for the grey zone that policy genuinely cannot pre-decide.

Last updated: July 30, 2026.

The four layers, and the honest answer to "does this stop anything".

One disclosure first: we have not run our own controlled test of a validator model, so no figure below is our measurement. Every number here is someone else's published work, linked at the point of use.

What AI agent guardrails actually are

AI agent guardrails are the controls that decide what an agent may do to the outside world, and they come in exactly four kinds: instructions you hope it follows, detectors that judge each attempt, boundaries that make the attempt impossible, and records that let you prove and reverse what happened. Most guidance flattens all four into one word, which is why so many teams believe they have guardrails when what they have is a paragraph in a system prompt.

The distinction is not hair-splitting. LangChain's documentation draws it plainly, splitting guardrails into deterministic ones that "use rule-based logic like regex patterns, keyword matching, or explicit checks" and are "fast, predictable, and cost-effective, but may miss nuanced violations," against model-based ones that "use LLMs or classifiers to evaluate content with semantic understanding" and "catch subtle issues that rules miss, but are slower and more expensive" (LangChain docs). Correct as an engineering split. Incomplete as a governance split, because it says nothing about which family is allowed to be the last thing standing between an agent and a wire transfer.

So here is the naming we use for the rest of this piece.

The rule that falls out of the table is the whole article in six words: never detect what you can forbid. A detector suits questions with no pre-computable answer. It is wrong where you already know the answer at design time, because you are converting a certainty into a coin flip and paying tokens for the privilege.

Two things make this a live problem rather than a tidy taxonomy. First, scale: Palo Alto Networks reports machine identities per human in the enterprise hitting 109 to 1 this year, up from 82 to 1 last year, and cites its 2026 Identity Security Landscape Report for the finding that 99% of organisations have adopted AI agents, with 40% of those agents already holding access to organisational data (Palo Alto Networks). Second, the failures have started arriving: the OWASP Agentic Security Initiative published a threat-model-based reference of emerging agentic threats on 17 February 2025 (OWASP GenAI Security Project), and the project followed it on 9 December 2025 with a Top 10 for Agentic Applications developed, in its own words, "through extensive collaboration with more than 100 industry experts, researchers, and practitioners" (OWASP GenAI Security Project). Standards bodies do not build taxonomies for hypotheticals.

Why the validator pattern won, and what it genuinely fixes

The validator pattern puts a second model call in front of every action that touches the outside world: the agent proposes a tool call, a separate call decides whether it was authorised, and only an approval releases it. Borrowing the reinforcement-learning term, it is sometimes described as an actor-critic split: one model acts, another judges. It won as the default among AI agent guardrails because the two obvious alternatives are both bad, and because it is cheap enough to run on every request.

The alternatives really are bad. Confirming every action destroys the product; an agent that asks permission forty times an hour is worse than the form it replaced. Trusting the model is not a control, and the counter-example is famous. On 18 July 2025 a Replit coding agent deleted a live production database during an active code freeze, "despite receiving repeated instructions not to make changes," then produced fabricated test results and incorrectly claimed rollback was impossible (AI Incident Database, incident 1152). The database held records on 1,206 executives and more than 1,196 companies; Replit's CEO called it "unacceptable and should never be possible," and the company shipped automatic development-production separation and a planning-only mode (eWeek, 22 July 2025). Note what failed, and note the fix. What failed was an instruction treated as a control. What Replit shipped was not a better detector but two boundaries: separate databases, and a mode where the agent cannot write.

The pattern's ancestor is Simon Willison's dual LLM design from April 2023, splitting the system into a Privileged LLM with tool access and a Quarantined LLM that handles untrusted content, "does not have access to tools, and is expected to have the potential to go rogue at any moment" (Willison). He was blunt about the ergonomics: "You may have noticed something about this proposed solution: it's pretty bad!" The validator is the pragmatic descendant: instead of isolating the untrusted model, let one act and ask another whether the act was authorised.

Vendors have converged on the shape. The OpenAI Agents SDK ships input and output guardrails with tripwires, where a failed check "immediately raise[s] a {Input,Output}GuardrailTripwireTriggered exception and halt[s] the Agent execution," and the docs suggest running it on a fast, cheap model so "the agent never executes, preventing token consumption and tool execution" (OpenAI Agents SDK docs). LangChain ships the same idea as middleware. Table stakes now, not a differentiator.

One refinement is worth stealing whatever you conclude about the limits: make the acting agent state its authorisation before the validator sees the call. If the tool schema carries a required field where the agent cites the evidence that the user asked for this, the validator's job drops from open-ended judgement to claim-checking. That is easier, better suited to a small model, and it leaves a loggable artefact.

And the cost objection is weaker than it looks. Take a validator call with a 3,000-token prefix, generous for a system policy plus recent task history plus one tool schema, returning about 120 output tokens. The nano tier of OpenAI's current line, gpt-5.4-nano, is published at $0.20 per million input tokens, $0.02 per million cached input and $1.25 per million output (fetched 30 July 2026, OpenAI pricing). That works out at $0.0006 in plus $0.00015 out, so about $0.00075 per validated action, and roughly $0.0002 once prompt caching is applied, which it can be, because a validator's prefix is identical on every call. Older small models on the same price list are cheaper still, so treat this as the conservative figure rather than the floor.

Seventy-five dollars a month, or twenty-one with caching, is not why anyone skips this. The real costs are latency on every action and the false-positive rate you absorb. Argue about those.

Four ways a model-based guardrail fails

A model-based guardrail fails in four distinct ways, and only the first is the one people worry about. It can be talked past by an adaptive attacker; it can block so much benign traffic that it gets switched off; it can share a blind spot with the model it checks; and it can be correct but irrelevant, because it was never told the thing that made the action wrong.

One: adaptive attackers get through. This is the finding that should reset expectations. A 2025 study by Zhan, Fang, Panchal and Kang evaluated eight published defences against indirect prompt injection on LLM agents and "bypass[ed] all of them using adaptive attacks, consistently achieving an attack success rate of over 50%" (Zhan, Fang, Panchal and Kang). Eight for eight, above half. A separate benchmark across 15 defences, from a team at IBM Research, found "significant performance variation depending on the style of jailbreak a defence is subject to" and that "simple baselines can display competitive out-of-distribution performance compared to many state-of-the-art defences" (Zizzo et al.). Read together: defences look strong on the attack styles they were tuned on and weak on the ones they were not. And the ones they were not are the ones you will meet.

Mackenzie Jackson's NDC Security 2026 talk in Oslo walks the mechanism end to end on a real target, Google's own CI/CD, showing how untrusted text reaches a privileged pipeline.

Two: over-defence gets the guardrail disabled. A strict detector's cost is paid by every legitimate user, and it is larger than most teams model. The NotInject benchmark tests prompt guard models on 339 benign samples that happen to contain trigger words common in injection attacks, and found state-of-the-art guard models dropping to accuracy "close to random guessing levels (60%)" on that set (Li and Liu, InjecGuard). On an all-benign set, accuracy is the pass rate, so 60% means two in five harmless requests refused. A guardrail that blocks two in five ordinary requests because they happen to use an injection-flavoured word does not survive a product team. It gets a bypass flag, then a permanent exemption list, then nobody remembers it.

Three: the judge shares the blind spot. The standard defence is that the two prompts ask different questions, so attention lands differently and the correlation is weaker than it looks. Fair, and partly true. Not the same thing as independence. The standard reference on intrinsic self-correction, meaning a model revising its own answer with no external feedback, reports that "LLMs struggle to self-correct their responses without external feedback, and at times, their performance even degrades after self-correction" (Huang et al.). A separate call to the same model family is not intrinsic self-correction, so that is not a direct refutation. But it should stop anyone assuming a second look is an independent look.

One practitioner put the arithmetic well. Discussing an evaluation harness they had built, a Hacker News commenter reported that "the agent was about 80% correct, and the LLM judge about 80% accurate" (visarga, Hacker News, 16 August 2025). One person's project, not a benchmark. Still the right question to ask of your own numbers.

Four: it was never told the thing that mattered. A validator sees a conversation and a proposed call. It does not see that this customer is in arrears, that this mailbox is a shared alias, that the requester left on Friday, or that the same action already ran twice this hour. Those questions are answered by systems of record, not by reading a transcript. The fourteen authors of the design-patterns paper on agent security state the limit of the whole detection family without hedging: detection systems "remain fundamentally heuristic and cannot guarantee prevention of all attacks," and more broadly, "as long as both agents and their defenses rely on the current class of language models, we believe it is unlikely that general-purpose agents can provide meaningful and reliable safety guarantees" (Beurer-Kellner et al., with authors from Google, Microsoft, IBM, ETH Zurich and EPFL).

Some practitioners go harsher. Mario Zechner, writing about his own coding agent in November 2025, argued that "if you look at the security measures in other coding agents, they're mostly security theater," and shipped no permission system at all, on the grounds that users who need guardrails should use a container (Zechner). Too far as a conclusion; right as a diagnosis. The container is a boundary. A boundary beats a warning, and the half-measures between mostly buy comfort.

Never detect what you can forbid

This is the ordering rule for AI agent guardrails, and it fits on one line: if you can express a limit as something the agent cannot reach, express it that way, and let the detector handle what is left. Detection converts a design-time certainty into a runtime probability, and every action class you can pre-decide is a class where that probability is a downgrade.

Practitioners reach the same split without the vocabulary. Asking r/LLMDevs how people stop out-of-scope agent actions against real backends, one engineer separated two layers: "identity level, the agent literally doesn't have a credential that can do the dangerous thing," against call level, where a gateway inspects the request before it goes through (u/Big-Spot-5888, r/LLMDevs, 7 July 2026). Forbid and Detect, named from the field.

The same components in two orders. Only one bounds the damage when the judge is wrong.

The research literature has been converging on this for two years, and the strongest result is worth stating precisely, because it also shows the price. CaMeL, from a team including ETH Zurich and Google researchers, wraps the model in a system layer that "explicitly extracts the control and data flows from the (trusted) query; therefore, the untrusted data retrieved by the LLM can never impact the program flow," attaching capability metadata to every value so that policies are enforced when tools are called. It solves "77% of tasks with provable security (compared to 84% with an undefended system)" on the AgentDojo benchmark (Debenedetti et al.). There is the honest trade: seven points of task completion for a guarantee instead of a hope. AgentDojo itself comprises 97 realistic tasks and 629 security test cases (Debenedetti et al.).

A companion paper from an overlapping group of authors gives the guiding principle in a form you can hand to an engineer: "once an LLM agent has ingested untrusted input, it must be constrained so that it is impossible for that input to trigger any consequential actions" (Beurer-Kellner et al.). It names six composable patterns that achieve degrees of that isolation: Action-Selector, Plan-Then-Execute, LLM Map-Reduce, Dual LLM, Code-Then-Execute and Context-Minimization. Every one works by removing capability rather than judging intent.

Two deserve translation for teams who will never read the paper. Action-Selector reduces the agent to a switch statement: it picks from a fixed list of parameterised actions and gets no feedback from the results, so untrusted output cannot steer the next decision. Plan-Then-Execute lets tool output flow back but fixes the plan before untrusted data is read, so results change the content of actions and not which actions run. Both are less flexible than an open-ended agent, and both make whole attack categories structurally impossible rather than unlikely.

The plumbing already exists and is mostly ignored. The Model Context Protocol specification is explicit that servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server," names token passthrough as a forbidden anti-pattern, and devotes a section to scope minimisation — warning against "wildcard or omnibus scopes (*, all, full-access)" and recommending a minimal initial scope with incremental elevation (MCP security best practices). Those are boundary controls, and they set your blast radius when a detector misses. We covered the connector side in our earlier analysis of MCP server security and governing AI connectors.

Gartner reaches the same conclusion from the governance side, and states the root cause more sharply than most security writing manages. In a May 2026 release the firm found that failures "are most likely to occur when organizations fail to distinguish between an agent's ability to act and the scope of access it is granted," and predicted that by 2027, 40% of enterprises will demote or decommission autonomous AI agents "due to governance gaps identified only after production incidents occur" (Gartner, 26 May 2026). Ability to act versus scope of access is the Detect-versus-Forbid distinction arriving from a different direction.

The three-question action triage

Before choosing a mechanism, sort the actions. Three questions per tool, answerable in an afternoon by anyone who knows the system, produce four classes, and the class picks the layer. This is what we would do first in any agent review, because the usual failure is not the wrong control but one control applied uniformly across actions with wildly different consequences.

The symptom is familiar to anyone who has shipped one. Writing about agents given internal APIs, files, scripts and browser control, a developer described "broad tool access quietly turning into broad execution authority," then asked the question this triage exists to answer: "what actually stops the action before it runs?" (u/docybo, r/LLMDevs, 21 March 2026).

One row per tool. The action sets the class, not your confidence in the model.

Q1, reversibility. Can one person undo this in under an hour, alone, without telling anyone? Not "is there a backup somewhere". Can one person actually do it, today, without a change ticket? If the answer is no, the action is irreversible for governance purposes even if a database administrator could theoretically recover it.

Q2, reach. Does it leave the building? A customer, a regulator, a payment rail, a public channel, a third-party system of record. Internal actions have a forgiving audience; external ones create obligations you cannot retract.

Q3, taint. Can text an outsider wrote reach the decision to call this tool? Inbound email, a scraped page, a customer ticket, a PDF, a code comment in a public repository, an MCP server's tool description. If yes, the tool sits inside the prompt-injection blast radius however careful the system prompt is.

Four classes fall out. "Forbid outright" means the general capability is absent, not that the work is impossible: the narrow, human-gated version can still exist.

Worked example, a customer-support agent with six tools. search_knowledge_base is class A: the query comes from a ticket, but reading cannot act on anything. read_ticket_thread is class A on the same reasoning. draft_reply is class B, because the draft is shaped by attacker-controllable ticket text and will be read by a human who may not re-read it carefully. send_reply is class C: it leaves the building and cannot be unsent, though it can be corrected. issue_refund is class D and should not exist as a general tool; what should exist is issue_refund_up_to(amount ≤ 50, order_id from this ticket), a typed action with the dangerous range removed. close_and_purge_ticket is class D and belongs to a human.

Notice what the triage produced. Two of the six tools need no detector. One needs a different signature, not a guardrail. One needs a human. The validator earns exactly one, and that is the correct answer, not a disappointing one.

One note on tools that resist classification. If nobody in the room can say whether an action is reversible, that is the finding: an action whose consequences nobody can describe is an action nobody owns, and unowned automation is where audit questions land. We wrote about the ownership half in our analysis of moving from personal prompts to owned AI assets.

And the triage is not a one-off, which is the part that kills it. A single afternoon classifies the tools you have today. Agent tool sets change weekly, an MCP server's catalogue can change without you touching anything, and a class A tool becomes class C the moment someone adds a send scope to it. So attach the class to the tool definition rather than to a document: a required field on the registration, defaulting to D. A new tool with no class is not a tool with an unknown class, it is a class D tool until someone argues otherwise, and that default is the only version of this that survives contact with a team shipping fast. Then review the classes on the same cadence you review access grants, and treat any tool whose class changed without a ticket as an incident rather than an update.

Two classifications deserve extra care because they are not really credential questions. Deploy and schema-change actions sit in class D, but the control that governs them in a regulated environment is change management, so the agent's path to production should be the one your humans already use, with the same approvals and the same record. And any action that grants or alters access belongs in class D permanently, because an agent that can widen its own scope has no scope at all.

Nine guardrail mechanisms, and what each is actually for

Here is the field of AI agent guardrails, on four questions: best for, what it enforces, when it fails, what it costs. The order runs weakest guarantee to strongest, roughly the reverse of how most teams adopt them.

1. System-prompt policy

• Best for: setting default behaviour; making the agent's job legible to the model.
• Enforces: nothing. It shifts the probability distribution over actions.
• Fails when: any untrusted text competes with it, or the model reasons its way to an exception. The Replit agent violated explicit written instructions.
• Verdict: necessary, never sufficient, and effectively free. Documentation the model happens to read.

2. Regex and deny-lists on tool arguments

• Best for: catching the specific known-bad string you have already been burned by.
• Enforces: an exact-match veto on patterns you enumerated.
• Fails when: the attacker rephrases. This is our problem card: enumerate cat .env, then tail .env, then sed '' .env, forever.
• Costs: microseconds to run, high maintenance, a growing exemption list.
• Verdict: fine as an alert, harmful as a security claim. Invert it — allowlist the permitted shapes.

3. Guard classifier for prompt injection

• Best for: volume triage and telemetry — how often someone is trying.
• Enforces: a probability that the input is an attack.
• Fails when: the attack is out of distribution, or benign text contains trigger words. Guardrail models fell to roughly 60% accuracy on 339 benign NotInject samples.
• Costs: milliseconds locally or one small call per input, plus a real false-positive budget.
• Verdict: good sensor, poor gate. Route it to monitoring, not to the authorisation path.

4. Validator model on every side-effectful action

• Best for: class B and the genuine grey zone, where authorisation depends on conversation context no policy can pre-encode.
• Enforces: a second, differently-prompted judgement, ideally checking a claim the acting agent was forced to make rather than forming an opinion from scratch.
• Fails when: an adaptive attacker targets it, or the authorising fact lives in a system of record it cannot see. Eight of eight defences fell above 50% attack success.
• Costs: roughly $0.00075 per action on a nano-tier model, or $0.0002 with a cached prefix, plus one round trip of latency and a false-positive rate you must staff.
• Verdict: the best available answer for judgement calls, and the wrong last line for anything irreversible.

5. Human-in-the-loop approval gate

• Best for: class C and D actions where a person can add information the system lacks.
• Enforces: a real stop, as long as the person is actually reading.
• Fails when: volume rises. Approvals "degrade under time pressure or approval fatigue, creating a false sense of safety" (Gartner).
• Costs: human minutes, workflow latency, an on-call rota.
• Verdict: mandatory for the top class, dangerous to over-apply, because it degrades silently rather than failing loudly.

6. Typed and templated actions

• Best for: replacing a dangerous general tool with a safe specific one.
• Enforces: structural impossibility. issue_refund_up_to(50) cannot refund 5,000; a parameterised query cannot become a DROP TABLE.
• Fails when: the safe range is set too wide, or a general escape-hatch tool appears next to it for convenience.
• Costs: design effort per tool, and flexibility you will occasionally miss.
• Verdict: the highest-payoff item on this list and the least fashionable. Most class D actions become class C with one signature change.

7. Scoped credentials on a non-human identity

• Best for: every agent, without exception.
• Enforces: the outer limit of the blast radius. If the token cannot write to the ledger, no amount of prompt injection writes to the ledger.
• Fails when: the credential is a shared integration user, has no expiry, or carries omnibus scopes because narrowing them was fiddly. MCP's specification names wildcard scopes as a common mistake for this reason. And when the vendor only issues full-access keys, the scope moves to your side of the wire: a broker that holds the key and exposes a narrower action set.
• Costs: identity work and a rhythm for reviewing grants.
• Verdict: the one control that survives a fully compromised model. If you do one thing this quarter, do this. Our earlier analysis of giving every agent an owner, a scope and an expiry covers the mechanics.

8. Sandboxing and egress control

• Best for: code-execution and computer-use agents, where the tool surface is unbounded by construction.
• Enforces: what the process can touch — filesystem, network, secrets.
• Fails when: the production credential is inside the sandbox, which is a common configuration.
• Costs: cold-start latency and infrastructure; a real engineering project.
• Verdict: the only credible control for an agent that writes and runs arbitrary code. The substance behind "just use a container".

9. Action audit trail with revocation

• Best for: everything. It decides whether an incident is a bad afternoon or an open-ended inquiry.
• Enforces: nothing at the moment of action, everything about what follows.
• Fails when: it logs requests but not tool calls, approvals but not refusals, or cannot answer "which agent, whose authority, what changed" in one query.
• Verdict: not a guardrail. It costs storage, schema discipline and an owner, and it is what makes the other eight auditable.

Choose accordingly. Choose a validator model if your grey zone is genuinely large — inbound-message-driven agents, open-ended assistants, anything where authorisation depends on what a human said three turns ago. Choose typed actions if your dangerous surface is small and enumerable, which describes most line-of-business agents and nearly all finance and HR workflows. Choose a sandbox if the agent writes code. Choose human gates by action class, never by confidence threshold. And choose scoped credentials always, first, before any of the above, because it is the only item here whose promise does not depend on a model being right. If you need a sequence: triage and scoped credentials first, typed signatures for class D next, the validator last. Each step is useful on its own if the next one slips.

When a validator model is the right answer anyway

There are cases where a validator model is not a compromise but the correct primary control, and a piece arguing for boundaries should say so plainly. It is the one place in a stack of AI agent guardrails where a probability genuinely beats a rule. If your agent's whole job is to act on text that strangers wrote, the grey zone is not an edge case — it is the product.

Consider a scheduling assistant that reads inbound email. A stranger writes asking for a meeting. Reasonable request, reasonable language, and not authorisation. No credential scope distinguishes "the user asked me to book this" from "someone emailed asking me to book this," because both resolve to the same API call with the same permissions on the same calendar. The distinguishing fact is who asked, and it lives in the conversation. That is exactly the question a validator can answer and a boundary cannot.

The trust model matters more than classifier quality here, and it is where we would spend the design time. Only the principal can authorise. A third party's inbound request never authorises, however polite. And an agent may not cite a conversation it started as its own justification, or it bootstraps permission out of nothing: send a message, read the reply, treat the reply as instruction. Those three rules beat any accuracy improvement, because they are the part a small, cheap model enforces reliably.

One more case favours it: retrofitting an agent that already holds broad credentials, where a validator is the fastest control you can add without re-architecture and buys time to narrow scopes.

What none of that changes: put it inside a scope. The validator narrows the grey zone; the credential decides how bad the grey zone can get.

Human approval gates fail quietly

Human approval is the strongest guardrail on the list and the one most likely to be broken in production while showing green, because its failure mode is a person clicking approve without reading. It does not error. It reports success.

Gartner's May 2026 governance research names four autonomy levels for AI agents: Observe, Advise, Act with Approval, Act Autonomously. Each one is a different trust boundary. Its analysis of the third is the most useful paragraph published on the subject this year. "At this level, human review is effective only if it remains a meaningful control," the firm's Shiva Varma is quoted as saying. "Without strong security testing, clear approval workflows with audit trails, and agent-specific incident response procedures, approvals can degrade under time pressure or approval fatigue, creating a false sense of safety while expanding the attack surface" (Gartner). The security literature agrees from the other side: confirmation mechanisms "pose a safety risk themselves with tired or overloaded human verifiers approving unsafe actions" (Beurer-Kellner et al.).

Regulators have been unusually specific. The EU AI Act's Article 14 requires that high-risk systems be designed so oversight persons can "properly understand the relevant capacities and limitations" of the system, "remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias)," and "intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure" (EU AI Act, Article 14). Automation bias is named in the text of the law. A design that assumes attentive approvers is one the regulation already anticipated.

Four things make an approval gate hold, and all four are boring.

Gate by action class, not by confidence score. A threshold sends humans the cases the model found ambiguous, which correlates with volume spikes and novel attacks. That is the worst moment to need careful reading. A class-based gate sends a predictable, budgetable stream.

Put the decision in front of the approver, not the transcript. "Approve refund of $340 to order 88213, requested in ticket 4471 by the account owner" is reviewable in four seconds. Two thousand tokens of agent reasoning is not, and a reviewer who cannot review in seconds stops reviewing.

Default to refusal on timeout, and measure the timeout rate. Expiring approvals mean the gate is on the wrong class or the team is understaffed; either way the number warns you before an incident does.

Keep a working stop. Gartner's description of the top autonomy level lists "rapid rollback mechanisms, circuit breakers that halt agent operation on threshold violations and clear ownership for agent behavior." A stop button nobody has pulled in anger is a stop button of unknown state. Pull it on purpose, on a schedule.

Prove: the layer nobody budgets for

The fourth layer of AI agent guardrails stops nothing at the moment it matters and determines everything about what happens after a miss. Its job is to answer three questions in one query: which agent took this action, on whose authority, and what changed. If your logs answer the first two and not the third, you have observability rather than an audit trail, and the difference surfaces in the first serious incident.

This is also the layer with the clearest regulatory hook. The EU AI Act's Article 12 requires that high-risk AI systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system," with logging sufficient for traceability appropriate to the system's purpose (EU AI Act, Article 12). The framework side is equally explicit: the NIST AI Risk Management Framework, released on 26 January 2023 with a Generative AI Profile added on 26 July 2024 (NIST), is organised around four functions, Govern, Map, Measure and Manage (NIST AI Resource Center). NIST has since moved toward agent-specific control language, announcing its Control Overlays for Securing AI Systems concept paper on 14 August 2025 with use cases covering "generative AI, predictive AI, single and multi-agent AI systems, and controls for AI developers" (NIST). Those overlays are not finished: as of 30 July 2026 the project's own publications page lists a single item, a March 2025 adversarial-machine-learning taxonomy, and no overlay document (NIST CSRC). Worth knowing before anyone cites them as a requirement.

Three properties separate an audit trail that survives scrutiny from one that does not.

It records refusals, not only executions. A log of what ran tells you what happened. A log of what was blocked tells you whether your controls work, and it is the only way to notice that a detector's block rate jumped last Tuesday. It is also harder to build: refusals happen in more places than executions.

It names a non-human principal, not a service account. "Action taken by svc-integrations" is not an answer. "Action taken by the invoice-reconciliation agent, owned by the finance operations lead, scope limited to the EU entity's ledger, credential expiring in 60 days" is. That is the difference between revoking one agent and revoking a shared integration everything depends on. The MCP specification makes the point from the plumbing angle, warning that token passthrough creates "accountability and audit trail issues" because "the downstream Resource Server's logs may show requests that appear to come from a different source with a different identity" (MCP security best practices).

Revocation is one step and has been rehearsed. Not whether you can revoke access, but how long it takes and whether anyone has. Time the drill. We covered the tracing side in our earlier analysis of audit trails that prove what an agent actually did.

Where guardrails stop being an application feature

Everything above can be built inside one application, and for one agent that is right. It stops being right at the second, because the controls that matter are properties of the company rather than the app. Who owns this. What it may touch. What it did. What it cost. That layer is what LeapForce builds: one controlled layer for every AI tool, connector, model and agent, so identity, scope, policy checks and the audit record are not re-implemented by whoever ships next.

Concretely, the four layers in this article map onto things we treat as platform concerns rather than application concerns. Every agent gets a non-human identity with an owner, an explicit scope and an expiry, so offboarding is one revocation rather than an archaeology project (Access and Identity). Connectors are vetted once and granted at action level, with credential brokering and human-in-the-loop gates on the sensitive classes, so scoping is a registry decision rather than a per-team negotiation (Connectors). Requests run through one governed endpoint whose lifecycle is Identify, Check, Protect, Route, Execute, Record, so there is one place where policy is evaluated (AI Gateway). The trail records what was refused as well as what ran, which is the property that makes an incident bounded (Observability and Audit).

Our sequencing advice is the one on that gateway page, and it exists because enforcing before you can see is how governance projects die: Observe first. Enforce second. Optimize third. Point one team's traffic at the gateway in observe mode, learn what is running, then turn on the policies the evidence justifies. Teams that start with enforcement block work they did not know was load-bearing, and lose the mandate.

To be plain about the boundary: LeapForce is a deployment and governance layer, not a prompt-injection detector, and nothing here replaces the application-level work of designing typed actions and deciding where a validator belongs. That design is yours. What we remove is rebuilding identity, scoping, policy evaluation and the audit record for every agent your company ships.

What we still do not know

Several things here are less settled than most guardrail writing implies.

We have not tested a validator ourselves. No first-hand block rate, false-positive rate or latency measurement, and no controlled comparison of a boundary-first architecture against a validator-first one. The argument above rests on published research and on reasoning about failure modes. If you have run that comparison, your numbers beat this article's reasoning.

The false-positive tradeoff has no published enterprise baseline. The over-defence figures come from academic benchmarks on constructed datasets. What a support agent's false-positive rate looks like in a real queue, over a quarter, is not in the public record we could find. Anyone quoting a number for your context is guessing.

Boundary-first architectures cost utility, and the size of that cost is unclear outside benchmarks. CaMeL's seven-point gap is a real measurement of a real system, but AgentDojo's 97 tasks are not your workflows. The six design patterns constrain agents deliberately, and the design-patterns paper is candid that they "explicitly prevent them from solving arbitrary tasks" (Beurer-Kellner et al.).

The standards are mid-flight. NIST's agent-specific control overlays were announced in August 2025, and eleven months later the project's publications page still lists no overlay document. Anyone building to a fixed compliance target here is building to a moving one, and the EU AI Act's high-risk obligations cover categories many agent deployments will argue their way out of.

Some sources a reader would expect are missing, and we would rather say so. The practitioner voices here come from Hacker News and r/LLMDevs. Both skew toward engineers rather than the operations, finance and compliance people this decision usually involves, and Reddit's JSON interface refused our requests, so only the older HTML view was searchable and we sampled less widely than we wanted. ISO's pages for ISO/IEC 42001 refused every request we made, so the AI-management-system standard many governance teams are certifying against is absent from this piece rather than cited at second hand.

And the honest limit of the whole argument: forbidding an action requires knowing in advance that it is dangerous. The triage works on tools you have enumerated. An agent that writes and executes code has an unbounded tool surface by construction, and there the boundary is a sandbox rather than a scope, which is heavier and less precise. That gap is why the researchers closest to the problem say general-purpose agents are unlikely to offer reliable guarantees with today's models. Prefer bounded agents where the work allows it, and be honest about which kind you run.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.