# AI agent guardrails

> AI agent guardrails limit what an agent can do as well as what it says. They combine tool permissions, argument checks, approvals, step limits and sandboxes.

Source: https://www.honeyhive.ai/learn/ai-agent-guardrails (updated 2026-11-03)

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](/learn/ai-guardrails).

## Why agents need more than content checks

OWASP [defines](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) 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](https://adk.dev/safety/) the action risks: damaging system commands, unauthorized purchases or financial transactions, leaking personal data and data exfiltration. It also names indirect [prompt injection](/learn/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](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) |
| Least-privilege identity | Permissions. OWASP says to minimize extension permissions and run extensions in the user's context. | [OWASP LLM06](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) |
| 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](https://adk.dev/safety/) |
| Tool design | Mistakes. Anthropic advises to "Poka-yoke your tools" by changing arguments so errors are harder to make. | [Anthropic](https://www.anthropic.com/engineering/building-effective-agents) |
| Approval before sensitive steps | Autonomy. OWASP says to require user approval. LangChain ships middleware for it. | [OWASP](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/), [LangChain](https://docs.langchain.com/oss/python/langchain/guardrails) |
| Stopping conditions | Runaway loops. Anthropic says it is common to include them, such as a maximum number of iterations. | [Anthropic](https://www.anthropic.com/engineering/building-effective-agents) |
| Sandboxed code execution | Blast radius of generated code. ADK recommends hermetic environments with no network access and full cleanup between runs. | [Google ADK](https://adk.dev/safety/) |
| Network perimeter | Data exfiltration. ADK notes this is coarse-grained, so tool-level guardrails are still needed. | [Google ADK](https://adk.dev/safety/) |
| Input, output and PII checks | Content. LangChain splits these into deterministic checks and model-based checks. | [LangChain](https://docs.langchain.com/oss/python/langchain/guardrails) |

## 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](https://adk.dev/safety/)). For how agents get identities, see [AI agent identity](/learn/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](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)).

## Where a framework's guardrails stop

Framework guardrails cover less than the name suggests. The [OpenAI Agents SDK docs](https://openai.github.io/openai-agents-python/guardrails/) 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](/learn/openai-agents-sdk-framework) and [MCP security](/learn/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](https://openai.github.io/openai-agents-python/guardrails/)). 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](https://docs.langchain.com/oss/python/langchain/guardrails)).

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"](https://www.anthropic.com/engineering/building-effective-agents), 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](/learn/ai-red-teaming). ADK [adds](https://adk.dev/safety/) 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](/learn/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](https://docs.honeyhive.ai/v2/tracing/client-side-evals), 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](https://adk.dev/safety/). See [AI guardrails](/learn/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](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/), 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](https://docs.langchain.com/oss/python/langchain/guardrails) describe human-in-the-loop middleware that requires approval before sensitive operations run, and OWASP lists [requiring user approval](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) as a prevention step. See [human-in-the-loop AI](/learn/human-in-the-loop-ai).