Foundations
What are AI guardrails?
AI guardrails are the constraints that decide what an AI system is permitted to do while it is running. They come in two families that are often confused: content guardrails, which screen what a model reads and writes, and action guardrails, which decide whether an agent may execute the operation it has just chosen. The two fail in different ways, and an enterprise running agents needs both.
The two families of guardrail
Almost everything sold as an AI guardrail belongs to one of two categories. They sit at different points in the loop, decide by different means, and leave different gaps.
| Content guardrail | Action guardrail | |
|---|---|---|
| Subject | The text going into and coming out of a model. | The operation the agent has decided to perform. |
| Position | Around the model call. | After the agent reasons, before the tool call executes. |
| Method | A classifier scores the text and acts on a threshold. | A policy is evaluated against the agent’s authorized scope. |
| Nature | Probabilistic — the same input can be scored differently twice. | Deterministic — the same action against the same policy returns the same answer. |
| Catches | Prompt injection, toxic output, leaked PII, off-topic use. | Unauthorized operations, SoD violations, actions over a threshold. |
| Misses | A correctly-worded request to do something the agent may not do. | Harmful text that never becomes an action. |
Neither is a substitute for the other. A content guardrail cannot tell you whether an agent was permitted to issue a refund, and an action guardrail does not care whether the summary it wrote was rude.
Why content guardrails do not govern agents
The gap opens as soon as a model stops answering and starts acting. A chatbot's output is its effect, so screening the text screens the risk. An agent's output is a decision to call a tool, and the effect happens in a system of record afterwards. Screening the text around that decision tells you very little about it.
Consider an accounts payable agent that has been asked, in entirely reasonable language, to settle an outstanding invoice. Nothing about the prompt is toxic. Nothing about the response leaks data. No classifier will flag anything, because there is nothing in the text to flag. The problem is that the agent raised that invoice an hour earlier, and approving it crosses a Segregation of Duties boundary. That is a fact about permissions and history, not about language, and no amount of content screening will surface it.
This is the failure mode OWASP catalogues as LLM06:2025 Excessive Agency, and it traces the risk to excessive functionality, excessive permissions, and excessive autonomy — three properties of what the agent is allowed to do, none of which are properties of its text.
Four implementation patterns
In practice, teams implement guardrails in one of four ways. They are listed roughly in order of how much they actually constrain an agent.
- Prompt-level instruction. Telling the model what not to do in its system prompt. Cheap, and worth doing, but it is guidance rather than a control: the model can be talked out of it, and there is no record of a violation because nothing evaluated anything.
- Content classification. A screening model on input and output. Effective for the risks that live in text, and the standard answer for chat interfaces. Probabilistic, so it produces confidence scores rather than decisions you can defend to an auditor.
- Tool-level restriction. Only connecting the agent to tools it needs. A genuine constraint and the single highest-value step most teams skip, but it is coarse: access is granted per server, while risk lives per operation. Connecting an agent to a finance system grants it read and write and approve together.
- Pre-execution authorization. A check in the path of the action that evaluates the specific operation against the agent's authorized scope and returns allow, block, or escalate before the call executes. The only pattern that produces a decision record, and the only one that can enforce a rule about who may do what.
The first three are all worth having. Only the fourth answers the question an auditor asks.
How LangGuard implements action guardrails
LangGuard implements the fourth pattern, deterministically, in two stages.
At design time, SCOPE-MCP enumerates an agent's complete action surface — every tool connected, every operation exposed, every system of record reachable — and classifies each operation against Segregation of Duties rules and regulatory regimes. That turns the agent's permitted scope into a written artifact before it ships, which is what makes the runtime check possible: you cannot enforce a boundary you have not drawn.
At runtime, Arbiter evaluates every action against that scope after the agent reasons and before the tool call executes, returning ALLOW, BLOCK, or ESCALATE. Safe actions clear with no added latency. Actions that cross an SoD boundary or exceed a policy threshold are blocked, or held and routed to a named approver. Every decision is recorded as evidence at the moment it is made.
LangGuard also enforces cost as a guardrail: per-workflow token budgets are checked in real time, so a runaway workflow is stopped rather than discovered on an invoice.
Common questions
Are AI guardrails the same as content moderation?
No, though the terms are used interchangeably and one is a subset of the other. Content moderation screens text for material that is toxic, unsafe, or off-policy, and it is one kind of AI guardrail. The broader category also includes constraints on what an AI system may do: which tools it may call, which operations it may perform, and which of those require a human to approve first. For a chatbot the two collapse into one, because the text is the whole product. For an agent that calls tools they come apart, because the damaging thing is an action taken in a system of record and no amount of text screening evaluates it.
Can AI guardrails be bypassed by prompt injection?
Content guardrails can be, and are, because they are the same class of system as the model they protect. A classifier deciding whether text is malicious can itself be fooled by text crafted to look benign, which is why injection defence is an arms race rather than a guarantee. Action guardrails are different in kind. A deterministic check on the action does not read the prompt or interpret intent; it compares the operation the agent is attempting against the scope that agent was granted. A successful injection can convince an agent to attempt an unauthorized action, but it cannot convince the authorization layer that the action is in scope, because that layer is not reasoning about language.
Where should guardrails sit in an agent architecture?
Outside the agent, in the path of the thing being governed. Content guardrails belong around the model call, screening input and output. Action guardrails belong between the agent's decision and the tool call, so they run after the agent has reasoned and before anything executes. The critical property in both cases is that the control does not live inside the agent's own loop. A guardrail implemented as instructions in a system prompt, or as code the agent itself invokes, fails in exactly the case it exists for, which is the case where the agent is behaving in a way you did not anticipate.
What is the difference between AI guardrails and an AI firewall?
An AI firewall is a content guardrail positioned at the network or gateway layer, inspecting prompts and responses in transit for injection attempts, data exfiltration, or policy violations. It is a deployment shape more than a distinct capability. Neither an AI firewall nor any other content-level control makes an authorization decision about an action, which is the separate job of an agent control plane. Most enterprises end up running both, and they do not overlap: the firewall governs what moves through the request path, and the control plane governs whether the agent may take the action at the end of it.
Do deterministic guardrails add latency to agent actions?
Not meaningfully, because the expensive part of an agent action is the model call, not the policy check. Evaluating whether a specific operation falls inside a pre-computed scope is a lookup rather than an inference, so safe actions clear without a perceptible delay. The design matters here: because the agent's action surface is mapped and classified at design time, the runtime decision is a comparison against an existing artifact rather than an analysis performed from scratch on every call. Actions that are escalated to a human do introduce a wait, but that is the intended behaviour rather than overhead.
Find out which actions your agents can take today.
LangGuard maps your complete agent action surface in minutes. Free for the first five managed agents, with every Scope included from day one.