AI agent guardrails

AI agent guardrails are the controls that bound what an agent can do and say while it works toward a goal. A chatbot guardrail checks a message. An agent guardrail also governs tool calls, the permissions behind them, how many steps the agent may take and where its code runs. Content checks are one layer. The rest limits actions, which is where an agent can do damage. For the text-level checks, see AI guardrails.

Why agents need more than content checks

OWASP defines excessive agency as the vulnerability that lets damaging actions happen “in response to unexpected, ambiguous or manipulated outputs from an LLM,” whatever caused the malfunction. It names three root causes: excessive functionality, excessive permissions and excessive autonomy.

Those causes point at the agent’s design, not at its text. A reply filter cannot help if the agent already holds a tool it should not have. Google’s ADK safety guide lists the action risks: damaging system commands, unauthorized purchases or financial transactions, leaking personal data and data exfiltration. It also names indirect prompt injection through tool use as a source of risk.

Controls by where they act

Control	What it limits	Source
Fewer, narrower tools	Functionality. OWASP says to minimize extensions, minimize their functionality and avoid open-ended ones.	OWASP LLM06
Least-privilege identity	Permissions. OWASP says to minimize extension permissions and run extensions in the user’s context.	OWASP LLM06
Policy in the tool, not the prompt	Arguments. ADK says developer-set context, not model-supplied arguments, should enforce rules such as allowed tables or read-only queries.	Google ADK
Tool design	Mistakes. Anthropic advises to “Poka-yoke your tools” by changing arguments so errors are harder to make.	Anthropic
Approval before sensitive steps	Autonomy. OWASP says to require user approval. LangChain ships middleware for it.	OWASP, LangChain
Stopping conditions	Runaway loops. Anthropic says it is common to include them, such as a maximum number of iterations.	Anthropic
Sandboxed code execution	Blast radius of generated code. ADK recommends hermetic environments with no network access and full cleanup between runs.	Google ADK
Network perimeter	Data exfiltration. ADK notes this is coarse-grained, so tool-level guardrails are still needed.	Google ADK
Input, output and PII checks	Content. LangChain splits these into deterministic checks and model-based checks.	LangChain

Permissions come before filters

The first OWASP fixes remove capability. Minimize extensions, minimize what each can do, avoid open-ended ones such as a tool that runs any shell command, and minimize permissions. “Complete mediation” means every request to a downstream system is checked against the user’s authorization, rather than trusting the model to decide.

Identity matters here. ADK describes two modes: the agent’s own identity, which suits cases where every user has the same access, and the controlling user’s identity, usually via OAuth, so the agent can do only what that user could. It warns that delegated OAuth scopes are often broader than needed, so more constraints may be required (ADK). For how agents get identities, see AI agent identity.

OWASP is explicit about what does not work. Logging, monitoring and rate limiting do not prevent excessive agency, but they can limit the damage (OWASP).

Where a framework’s guardrails stop

Framework guardrails cover less than the name suggests. The OpenAI Agents SDK docs state the limits:

• Input guardrails run only for the first agent in the chain, and output guardrails only for the agent that produces the final output.
• Tool guardrails wrap function tools, including local MCP tools when their server configures guardrails. They do not apply to the handoff call itself.
• Built-in execution tools such as ComputerTool and ShellTool “do not use this guardrail pipeline.”
• Agent.as_tool() does not currently expose tool-guardrail options directly.

So in a multi-agent flow, a check on the first message says nothing about what a later agent does, and the riskiest built-in tools need controls elsewhere, such as a sandbox or approval. Read the equivalent page for any framework you use before relying on its guardrails. See also OpenAI Agents SDK and MCP security.

In the SDK’s default parallel mode, an input guardrail runs concurrently with the agent. Blocking mode runs it to completion first, so if the tripwire triggers the agent never executes (docs). For an agent with side effects, that matters more than the latency saved.

Deterministic and model-based checks

LangChain’s docs describe two kinds. Deterministic guardrails use regex, keyword matching or explicit checks, and are fast and predictable but may miss nuanced violations. Model-based guardrails use an LLM or classifier for semantic understanding, and catch subtler problems but are slower and more expensive (LangChain).

For agents, use deterministic checks where the rule is exact: an allowed-tool list, a read-only flag, an argument range, a spending cap. Use model-based checks for meaning, such as whether a reply drifts off-topic. The same docs place checks at before_agent (once per invocation) and after_agent (once before the response returns), so a check there sees the request and final answer but not each tool call in between.

Test before you trust

Anthropic recommends “extensive testing in sandboxed environments, along with the appropriate guardrails”, and says agents can pause for human feedback at checkpoints or when they hit blockers. Adversarial testing of an agent’s tools and handoffs is covered in AI red teaming. ADK adds that tracing shows the steps, tool choices and efficiency behind an answer, which is how you find out what a guardrail did or missed. See agent observability.

Recording guardrail decisions in HoneyHive

Blocking runs in your own code. HoneyHive’s docs say guardrails such as format validation, safety checks and PII detection are ideal to compute client-side at execution time, and that enrich_span() adds metrics to a specific operation. Logging the decision on the tool-call span, with the rule that fired, lets you review blocked and approved actions per trace.

FAQ

What is the difference between agent guardrails and LLM guardrails?

LLM guardrails check text going into and out of a model. Agent guardrails also cover actions. Google's ADK guide lists unsafe actions such as damaging system commands, unauthorized purchases and data exfiltration as risks, and addresses them with identity, in-tool limits, callbacks, sandboxes and network controls. See AI guardrails for the text-level checks.

Can guardrails alone make an agent safe?

No. OWASP traces excessive agency to excessive functionality, excessive permissions and excessive autonomy, and its first fixes are to cut the tools and permissions an agent has. A filter on the model's output does not remove a permission the agent should never have held.

Where should a human approve an agent's action?

Before sensitive operations. LangChain's guardrails docs describe human-in-the-loop middleware that requires approval before sensitive operations run, and OWASP lists requiring user approval as a prevention step. See human-in-the-loop AI.