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.

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.

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

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:

// Validate — deny a destructive tool call
{ "verdict": false, "message": "Blocked: DELETE without a WHERE clause" }

// Mutate — redact PII from a tool result, then allow
{ "verdict": true, "transformed": true,
  "result": { "responseBody": { "content": "Customer <REDACTED_EMAIL> requested a refund" } } }

Recommended rollout for agents: start every new guardrail in Audit and watch traces to see what it would catch. Move to Enforce But Ignore On Error for protection that survives a provider outage. Reserve full Enforce for the checks you can't compromise on — PII, secrets, destructive SQL. Because a single blocked hop can break a whole agent chain, auditing first is not optional.

Why Enforce Agent Guardrails at the Gateway

You could try to implement these checks inside each agent. The reason not to is the same reason an AI gateway beats an API gateway for this traffic: consistency and coverage.

• One policy, every agent. Because rules key on the target, a new agent that calls an already-governed MCP server inherits the guardrails automatically — nothing to add to its code.
• Framework-agnostic. Agents built on LangGraph, CrewAI, AutoGen, or a custom loop all route through the same Agent Gateway and get the same checks.
• In the hot path, not in the way. The gateway adds roughly ~3–4 ms of overhead and sustains 350+ RPS on a single vCPU, so per-hop inspection doesn't become the bottleneck.
• VPC-native. Guardrails run inside your own AWS, GCP, or Azure account across 1,000+ models behind one OpenAI-compatible API — prompts, tool arguments, and results never leave your boundary. That is what makes SOC 2, HIPAA, and GDPR audits tractable.

The result is guardrails that behave like infrastructure: applied uniformly, observable in every trace, and owned by the platform team instead of scattered across a dozen agent repos.

Related reading

• MCP Server Security Best Practices — hardening the servers your agents call
• Enterprise AI Security with the MCP Gateway & Runtime Guardrails — the broader enterprise security picture
• MCP vs A2A — how agents talk to tools and to each other
• AI Gateway vs API Gateway — why agent traffic needs a different control point
• What is MCP Authorization? — the access-control half of governance

Conclusion

AI agent guardrails are what keep an autonomous system from acting on the wrong instruction — inspecting every prompt, output, and tool call for injections, PII, secrets, and unsafe operations before they do damage. The hard part isn't any single check; it's applying them consistently across every agent, every model, and every tool without scattering logic through your codebase. Enforcing them at the gateway solves exactly that: one set of policies, keyed to targets, covering every caller, observable in every trace, running inside your own cloud.

See how TrueFoundry runs guardrails across your agents, models, and MCP tools from one control plane → Book a demo or start free.