> ## Documentation Index
> Fetch the complete documentation index at: https://www.truefoundry.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Guardrails for Agents

> Inspecting the content of every agent hop — prompt injection, PII, secrets, and unsafe tool calls — and how to apply guardrails to agent traffic on TrueFoundry.

Identity and access control decide *whether* a call is allowed; guardrails inspect *what* the call contains — the [distinction introduced in key concepts](/docs/agent-platform/agent-governance/key-concepts#access-control-and-guardrails-whether-vs-what) and the **Guard** step of the blueprint's [per-hop loop](/docs/agent-platform/agent-governance/governance-blueprint#4-authorize-and-scope-the-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](/docs/ai-gateway/guardrails-overview), 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:

| Surface           | Hook      | Runs                                | Typical checks for agents                                                                     |
| ----------------- | --------- | ----------------------------------- | --------------------------------------------------------------------------------------------- |
| **LLM call**      | Input     | Before the prompt reaches the model | PII masking, prompt-injection detection (including injected tool results), content moderation |
| **LLM call**      | Output    | After the model responds            | Secrets detection, hallucination checks, content filtering                                    |
| **MCP tool call** | Pre-tool  | Before the tool executes            | SQL sanitizer, code-safety linter, parameter validation, Cedar/OPA permission checks          |
| **MCP tool call** | Post-tool | After the tool returns              | Secrets and PII redaction from results, code safety on returned content                       |

```mermaid theme={"dark"}
flowchart LR
    Agent[Agent] -->|prompt| GI[LLM input guardrails]
    GI --> LLM[(Model)]
    LLM -->|response| GO[LLM output guardrails]
    GO --> Agent
    Agent -->|tool call| GPre[Pre-tool guardrails]
    GPre --> Tool[(MCP tool)]
    Tool -->|result| GPost[Post-tool guardrails]
    GPost --> Agent
```

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](/docs/ai-gateway/guardrails-overview#how-truefoundry-ai-gateway-runs-guardrails) covers the execution model, ordering, and latency behavior in detail.

## Matching risks to guardrails

The [risks from the overview](/docs/agent-platform/agent-governance/overview#the-risks-concretely) that guardrails address, and the concrete guardrail for each:

| Risk                                                               | Guardrail                                                                                      | Hook                  |
| ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- | --------------------- |
| Indirect prompt injection via tool results or documents            | [Prompt injection detection](/docs/ai-gateway/tfy-prompt-injection)                            | LLM input             |
| PII reaching an external model or leaking in results               | [PII detection and redaction](/docs/ai-gateway/tfy-pii)                                        | LLM input, post-tool  |
| Credentials leaking through model output or tool results           | [Secrets detection](/docs/ai-gateway/secrets-detection)                                        | LLM output, post-tool |
| Destructive database operations (`DROP`, `DELETE` without `WHERE`) | [SQL sanitizer](/docs/ai-gateway/sql-sanitizer)                                                | Pre-tool              |
| Dangerous shell commands or unsafe code from the model             | [Code safety linter](/docs/ai-gateway/code-safety-linter)                                      | Pre-tool, LLM output  |
| Tool calls that violate fine-grained policy                        | [Cedar](/docs/ai-gateway/cedar-guardrails) / [OPA](/docs/ai-gateway/opa-guardrails) guardrails | Pre-tool              |
| Requests missing required context (environment, cost center)       | [Metadata validation](/docs/ai-gateway/metadata-validation)                                    | LLM input             |

Beyond the built-ins, the gateway integrates external providers (Palo Alto Prisma AIRS, CrowdStrike, Bedrock Guardrails, and more) and supports [custom guardrails](/docs/ai-gateway/custom-guardrails) — see the [full catalog](/docs/ai-gateway/guardrails-overview#supported-guardrails).

## How enforcement behaves

Two settings per guardrail, both explained fully in the [overview](/docs/ai-gateway/guardrails-overview#how-a-truefoundry-guardrail-works):

* **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).

<Tip>
  **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.
</Tip>

## Applying guardrails to agent traffic

<Steps>
  <Step title="Register the guardrails">
    In **AI Gateway → Guardrails**, register the guardrails you need — built-in, external provider, or custom.
  </Step>

  <Step title="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](/docs/ai-gateway/guardrails-configuration).
  </Step>

  <Step title="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](/docs/agent-platform/agent-governance/agent-observability).
  </Step>
</Steps>

For one-off needs, guardrails can also be attached per request with the `X-TFY-GUARDRAILS` header — see [how to apply guardrails](/docs/ai-gateway/guardrails-overview#how-to-apply-guardrails).

<Warning>
  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](/docs/ai-gateway/guardrails-overview#faq).
</Warning>

## A baseline for agent traffic

A starting configuration that covers the highest-consequence risks for most agentic setups:

| Hook       | Guardrails                                                                     |
| ---------- | ------------------------------------------------------------------------------ |
| LLM input  | PII redaction (Mutate) + prompt-injection detection (Validate)                 |
| LLM output | Secrets detection (Validate or Mutate)                                         |
| Pre-tool   | SQL sanitizer + code-safety linter (Validate, on database and execution tools) |
| Post-tool  | PII and secrets redaction (Mutate)                                             |

Start every rule in **Audit**, review a week of traces, then promote to enforcement.

## Coming soon

<AccordionGroup>
  <Accordion title="Guardrail policies keyed on agent identity" icon="robot">
    **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.
  </Accordion>

  <Accordion title="Chain-aware conditions" icon="link">
    **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](/docs/agent-platform/agent-governance/truefoundry-implementation#coming-soon) at both gateways.
  </Accordion>

  <Accordion title="Guardrails on agent invocations" icon="shield-halved">
    **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.
  </Accordion>
</AccordionGroup>