AI Agent Guardrails: Inspecting Every Tool Call and Model Hop

What Are AI Agent Guardrails?

AI agent guardrails are content-inspection controls that examine the actual payload of every agent interaction — the user prompt, the model's response, and the arguments and results of each tool call — and take action (allow, block, or rewrite) based on policy.

It helps to separate two questions every governed agent call has to answer:

• Whether the call is allowed — handled by identity and access control (which agent is this, what is it permitted to do).
• What the call contains — handled by guardrails (is there an injection in this tool result, a secret in this output, a DROP TABLE in these arguments).

Access control is the bouncer at the door; guardrails are the metal detector. You need both. An agent can be fully authorized to call your Postgres MCP server and still be tricked into sending a destructive query — access said yes, and only a guardrail on the tool arguments catches what the query actually is.

Why agents raise the stakes

Guardrails aren't new to LLM apps, but agents change the problem in three concrete ways:

• Untrusted content flows in continuously. Every tool result — a web page, a support ticket, a database row — re-enters the model's context on the next turn. Any of it can carry an injection, so 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. Effective guardrails run on every tool call separately, so each hop gets its own checks.

Where AI Agent Guardrails Run: The Four Hooks

On TrueFoundry, guardrails are enforced at the gateway on the agentic call path — the chain of user → app → agent → sub-agent → MCP tool calls. Every governed hop passes an interception point with a before and after hook.

The ordering matters for cost and blast radius. A pre-tool failure means the tool never executes — the cheapest possible failure. An LLM input failure cancels the in-flight model request before you pay for it. Because every hop is checked independently, a compromised tool result on hop three is caught on hop three, not after it has already fanned out into three more calls.

Matching Risks to Guardrails

The value of running guardrails at the MCP Gateway is that each real agent risk maps to a specific, built-in control. TrueFoundry's built-in guardrails run on TrueFoundry-managed infrastructure — no third-party API keys to provision.

Beyond the built-ins, the gateway plugs into external providers — Palo Alto Prisma AIRS, CrowdStrike AIDR, Cisco AI Defense, AWS Bedrock Guardrails, Google Model Armor, NVIDIA NeMo Guardrails, Guardrails AI, and more — and supports fully custom guardrails when you need logic specific to your domain.

The prompt-injection guardrail is the one built specifically for the agent problem: it analyzes the user prompt and any document or context content separately, so an injection hidden inside a returned web page or ticket is caught even when the user's own message is clean.

How to Implement Guardrails for AI Agents

Applying guardrails to agent traffic is a three-step flow, and crucially none of it lives in your agent code.

Step 1 — Register the guardrails

In AI Gateway → Guardrails, create a guardrails group and add the integrations you need — built-in, external provider, or custom. A group is also the unit of access control: a Manager can add, edit, and delete guardrails; a User can only apply them. A common pattern is one org-wide group owned by the platform team, plus per-team groups for product-specific checks.

Step 2 — Create policies that attach guardrails by target

In AI Gateway → Policies → Guardrails, create rules that decide when each guardrail runs. This is what makes the model scale to fleets of agents: rules are keyed on the target (the models, MCP servers, and even specific tools being called) and the subject (users, teams, or virtual accounts). Because a rule covers every caller of a given MCP server or model, it protects every agent that touches that target — with no per-agent setup.

‍

Each rule combines:

‍

• Targets — models (IN / NOT IN) and MCP servers, optionally narrowed to specific tools (e.g. only the run_query tool of a database server).
• Subjects — IN / NOT IN filters on users, teams, or virtual accounts.
• Metadata — match on X-TFY-METADATA key-values, so a rule can apply only to environment: production.
• Hooks — attach the registered guardrails to LLM Input, LLM Output, MCP Tool Pre-Invoke, or Post-Invoke.

‍

Product screenshot — TrueFoundry docs: guardrail policy rule editor.

‍

All matching rules are evaluated and their guardrails are merged per hook. If Rule A applies PII detection on LLM Input and Rule B applies prompt-injection detection on LLM Input, both run. A rule with no target or subject conditions becomes a baseline that applies to all traffic — useful for a company-wide prompt-injection check on top of everything else.

‍

For quick tests or one-off calls, you can also pass guardrails per request with the X-TFY-GUARDRAILS header, which bypasses policies entirely:

‍

curl https://<your-gateway>/api/llm/chat/completions \

  -H "Authorization: Bearer $TFY_API_KEY" \

  -H 'X-TFY-METADATA: {"environment":"production","agent":"research-agent"}' \

  -H 'X-TFY-GUARDRAILS: {"llm_input":["global/prompt-injection","global/pii-detection"]}' \

  -H "Content-Type: application/json" \

  -d '{

        "model": "openai-main/gpt-4o",

        "messages": [{"role":"user","content":"Summarize ticket #4521 and email the customer"}]

      }'

Step 3 — Verify in traces

Every request is traced with the guardrails that ran and their verdicts, so you can confirm coverage before you trust it. This is also where you tune false positives, which matter more for agents than for chatbots: a blocked hop can fail an entire chain.

‍

Product screenshot — TrueFoundry docs: guardrail results in a request trace.

‍

Before shipping, use the Playground to fire test prompts and tool calls against all four hooks and watch what gets caught.

‍

Product screenshot — TrueFoundry docs: AI Gateway Playground.

‍

Enforcement Modes: Validate, Mutate, and How Hard to Block

Two settings control how each guardrail behaves.

‍

Operation mode:

‍

• Validate — inspect and block (e.g. prompt injection detection, which only detects and blocks).
• Mutate — rewrite the content and optionally block (e.g. PII detection redacting an email before the prompt reaches the model).

‍

Enforcement strategy:

‍

• Enforce — block on a violation and if the guardrail itself errors. Use for strict-compliance checks like PII.
• Enforce But Ignore On Error — block on a violation, but let traffic through if the guardrail provider has an outage. The pragmatic default for most agent traffic.
• Audit — log only, block nothing.

‍

For custom logic, you deploy a guardrail as an HTTP service and the gateway reads its response contract: an HTTP 2xx means the guardrail ran, and the JSON body carries the outcome — verdict: false to deny, or a mutated result body to rewrite:

‍