Skip to main content
Identity and access control decide whether a call is allowed; guardrails inspect what the call contains — the distinction introduced in key concepts and the Guard step of the blueprint’s per-hop loop. This page covers what guardrails mean specifically for agents, and how to apply them; the underlying engine is the AI Gateway’s guardrails framework, which this page builds on rather than repeats.

​
Why agents raise the stakes

A chatbot with a bad response embarrasses you. An agent with a bad response acts on it. The 2025 Comet browser incident is the canonical example: a webpage carried hidden instructions written for the agent summarizing it, and the agent followed them — indirect prompt injection turning untrusted content into unauthorized actions. Identity governance cannot stop the injection itself; content guardrails at each hop are what stop the chain of actions that follows. Agents change the guardrail problem in three ways:
  • Untrusted content flows in continuously. Every tool result — a webpage, a ticket, a database row — re-enters the model’s context. Any of it can carry an injection. Inputs need checking even when the user is trusted.
  • Outputs become actions. A hallucinated shell command or an over-broad SQL statement doesn’t just read badly — it runs. Tool arguments need checking before the tool executes.
  • Chains multiply exposure. A five-tool chain is five chances to leak a secret or exfiltrate PII. Guardrails run on every tool call separately, so each hop gets its own checks.

​
Where guardrails run on the agentic call path

Every governed hop passes one of two kinds of interception point, each with a before and after hook: A pre-tool failure means the tool never executes — the cheapest possible failure. An LLM input-validation failure cancels the in-flight model request. The guardrails overview covers the execution model, ordering, and latency behavior in detail.

​
Matching risks to guardrails

The risks from the overview that guardrails address, and the concrete guardrail for each: Beyond the built-ins, the gateway integrates external providers (Palo Alto Prisma AIRS, CrowdStrike, Bedrock Guardrails, and more) and supports custom guardrails — see the full catalog.

​
How enforcement behaves

Two settings per guardrail, both explained fully in the overview:
  • Operation mode — Validate (inspect and block) or Mutate (rewrite, e.g. redact PII, and optionally block).
  • Enforcement strategy — Enforce (block on violation and on guardrail error), Enforce But Ignore On Error (block on violation, let through on guardrail outage), or Audit (log only).
Rolling out guardrails on agent traffic: start in Audit and watch traces to see what would be caught; move to Enforce But Ignore On Error for protection that survives a guardrail-provider outage; reserve Enforce for strict-compliance checks like PII. Agents amplify false-positive cost — a blocked hop can fail a whole chain — so audit first.

​
Applying guardrails to agent traffic

1

Register the guardrails

In AI Gateway → Guardrails, register the guardrails you need — built-in, external provider, or custom.
2

Create guardrail policies for the targets agents use

In AI Gateway → Policies → Guardrails, create rules that attach guardrails by target (the MCP servers, specific tools, and models your agents call) and subject (users, teams, or virtual accounts making the request). Because rules are keyed on the target, they cover every caller of that MCP server or model — including agents — with no per-agent setup. See Configure Guardrail Policies.
3

Verify in traces

Each guardrail runs as its own span in AI Gateway → Monitor → Request Traces, showing what it checked, what it found, what it mutated, and how long it took — per hop, per tool call. See Agent Observability.
For one-off needs, guardrails can also be attached per request with the X-TFY-GUARDRAILS header — see how to apply guardrails.
LLM output guardrails are skipped on streamed responses (stream: true), since they need the complete response to evaluate. For agent steps whose output feeds tool execution, prefer stream: false so output checks run. Details in the guardrails FAQ.

​
A baseline for agent traffic

A starting configuration that covers the highest-consequence risks for most agentic setups: Start every rule in Audit, review a week of traces, then promote to enforcement.

​
Coming soon

Coming soon. Today, policy subjects are users, teams, and virtual accounts; agent traffic is covered via the target (the MCP server or model the agent calls). The target model adds agent:<name> as a first-class subject filter, so you can express “apply the strict profile to this specific agent, whatever it calls” — different guardrail profiles for different agents hitting the same server.
Coming soon. Guardrail and access rules that use delegation context — for example, tightening checks for calls more than two hops deep in an actor chain, or for agents acting for users outside the resource owner’s team. This lands with Cedar policies at both gateways.
Coming soon. Pre- and post-invoke hooks on the Agent Gateway itself — inspecting the payload sent to a proxied agent and the response it returns, in addition to today’s LLM and MCP hooks. This closes the loop for agents whose model and tool calls happen outside the gateway.