What are agent guardrails?

By Nolan Sullivan, Founding Growth Engineer

·Published October 7, 2026·Updated October 13, 2026

AI guardrails often start with a content filter for prompts and model responses. An agent that calls tools over the Model Context Protocol (MCP) can also read a CRM, run a shell command, and post data to an external system. A filter on the model call does not inspect those tool actions.

In the 2026 CISO AI Risk Report, cited in an April 2026 Cloud Security Alliance research note, 71% of 235 large-enterprise security leaders said AI systems had access to core business platforms, and only 16% said they governed that access effectively.

Layers name where a control runs. Levels name what it decides. This guide applies the three levels in order: approved agents, access controls, and data exfiltration. More than one of the four layers can enforce each level.

Why do AI agents need runtime guardrails?

Frontier models refuse a blunt request to drop a production table or ignore their instructions, providers ship their own content filters, and every extra check adds latency and false positives. For a single developer using a chat assistant on public data, the model’s built-in behavior is often enough.

An agent with credentials needs controls beyond model refusal. Refusal is a probability, and prompt injections in tool results or encoded payloads can bypass it. A refusal in a transcript is not an independently configured policy with a recorded enforcement decision. Guardrails add explicit checks outside the acting model and write a log entry when they fire. Pattern matching can be deterministic; classifiers and LLM judges can still produce false positives and false negatives. Our guardrails release post makes this argument in more detail.

What are the four layers of AI agent guardrails?

Each layer sees a different part of agent traffic.

1. Infrastructure. The network paths and gateways agent traffic crosses: an edge network, an AI gateway in front of model providers, an MCP gateway in front of tools, and private networks such as a private MCP gateway or MCP tunnels. Infrastructure guardrails cover every client that routes through them, and nothing that doesn’t.
2. Applications. The AI apps and agent harnesses themselves, and the model calls they make. Content filters on prompts and responses run here, as do agent hooks that fire inside a coding agent on every prompt and tool call.
3. Access controls. Identity and authorization: which principal an agent acts as, which servers and tools that principal may call, and when the grant expires. Agent access management and enterprise MCP auth cover this layer.
4. Session management. The live agent session: watching it, quarantining it, and ending it while it runs. Agent session management covers this layer, which acts on the session rather than on the account behind it or the tools it calls.

Combining layers covers traffic a single guardrail misses. An application-layer content filter doesn’t see direct tool calls, and a gateway doesn’t see local tools that never route through it. Identity providers decide whether to issue a token without reading what the agent does with it.

How do guardrail layers map to the three enforcement levels?

The layers describe where a control runs, and the levels describe what it decides. Level 1 decides which agents may run and connect, level 2 decides what each approved agent can reach, and level 3 decides what data may move through the traffic that results. Each level draws on more than one layer.

Session management appears under level 3 because it handles quarantine after exfiltration findings, but it is the response layer for all three levels. When a check fires at any level, session management decides whether the agent keeps running.

The levels depend on each other: access controls scoped to known agents say nothing about an agent nobody approved, and exfiltration checks only inspect traffic from agents and paths the organization knows about. Each level narrows the problem for the next one, so a gap at level 1 carries through to the levels after it.

Level 1: How do you approve AI agents?

The first guardrail is deciding which agents may exist in the environment at all. An agent can be a desktop assistant, a coding harness such as Claude Code or Cursor, or an autonomous workflow on a server. Employees can install them without review and wire up MCP servers in a config file, so endpoint and asset tools record the editor and miss the connections behind it. Shadow AI covers this detection problem, and shadow MCP covers the unsanctioned servers in particular.

Approval at this level has two parts. Discovery finds what is running, through a device agent, hooks inside agents, or network detection, and agent discovery describes how those signals become records. The results land in an agent inventory, which gives each agent an owner and a disposition: approved, blocked, or not yet reviewed. Enforcement then makes the disposition real, usually at the infrastructure layer, by refusing an unapproved client when it tries to authenticate to a gateway.

Discovery only sees the clients it instruments, so a tool on an unenrolled laptop is invisible. Enforcement at a gateway only works for clients that identify themselves when they authenticate, and only for traffic that routes through the gateway. Approving and blocking servers rather than clients is part of MCP governance, which covers the server lifecycle from approval to retirement.

Level 2: How do you control what an approved agent can access?

The second level decides which systems, servers, and individual tools an agent may call, and which principal it acts as when it does. An agent acting for a signed-in user should carry that user’s permissions, and an autonomous agent should carry its own identity with a human owner, rather than a shared API key that nobody can trace. Agent identity, non-human identity, and extending IAM to agents cover the identity model.

Most of this level runs at the access controls layer. The identity provider decides whether to issue a token, roles map to servers and tools, and destructive tools get a narrower grant than read-only ones. Task-scoped credentials shorten how long a grant lasts. The infrastructure layer adds a second limit, because a server on a private network can only be reached from that network, whatever token the caller holds.

Access controls don’t inspect content. An agent with legitimate read access to a customer table can still send rows from it to an external endpoint, and that is the problem level 3 exists for. Access controls do limit the damage of a successful prompt injection, because an injected instruction can only call the tools the agent was granted.

Level 3: How do AI guardrails prevent data exfiltration?

The third level inspects what moves through the traffic levels 1 and 2 have allowed. Data can leave through three paths: a prompt sent to a model provider, the arguments of a tool call, and a tool result returned into the agent’s context. Malicious content comes in through the last path, as prompt injection hidden in a document or web page a tool returns, or as tool poisoning in a tool’s own description. Simon Willison describes an agent with access to private data, exposure to untrusted content, and a way to communicate externally as having everything needed to turn a prompt injection into data exfiltration.

Each path is visible to a different layer. Application-layer filters see prompts and model responses. An MCP gateway sees tool requests and tool results for the servers it fronts, and agent hooks see tool calls inside the harness, including local tools that never reach a gateway. Detectors at any of these points look for secrets, personal data, government identifiers, financial data, and injection patterns, and some vendors add an LLM judge for risks a pattern can’t express, such as a bulk export to an unknown domain. Agent DLP covers the data loss prevention side in depth.

When a detector matches, the response options are to log the finding, warn the user, deny the call, or quarantine the session. Some vendors can also redact or mask the matched value and let the rest through. Quarantine belongs to the session management layer. It stops the whole session rather than one call, which matters when a run of individually harmless calls adds up to an exfiltration attempt.

How should teams roll out AI guardrails?

Start by monitoring and flagging findings before blocking. A detector that blocks legitimate work in its first week pushes people back to personal accounts and unsanctioned tools, and the organization loses visibility along with the blocked traffic. Monitoring first also shows how noisy each detector is against the organization’s own data before anyone is interrupted.

Cloudflare’s AI Gateway guardrails let an admin pick the categories to monitor and choose between flagging and blocking. Check Point’s AI Guardrails use a project mode to decide whether a flagged threat is blocked or logged for investigation. Microsoft’s Prompt Shields guidance suggests moving from block to annotate mode to log without filtering when false positives appear.

To roll out guardrails:

1. Turn the policy on in a log-only mode for a broad audience.
2. Review findings, tune the scope, and add exclusions for values that keep producing false positives.
3. Raise the action to warn or deny for a small audience.
4. Widen the audience once the enforcement behavior is confirmed.

How do AI agent guardrails differ from AI governance and AI security?

AI governance sets the policies, owners, and reviews for how an organization uses AI, and guardrails enforce some of those policies at runtime. A governance policy says customer data must not leave through an agent, and a guardrail is the check that denies the tool call carrying it. Agent governance and AI governance cover the policy side, and AI security frameworks compares NIST AI RMF, MITRE ATLAS, and OWASP and where runtime enforcement fits.

AI security is the wider discipline, including threat modeling, red-teaming, and supply chain review, and guardrails are its runtime controls. AI security covers the full picture. The AI Control Plane is the layer that runs guardrails alongside connection, identity, and observability in one traffic path.

What are the trade-offs of AI agent guardrails?

Every guardrail in the request path adds latency. Pattern detectors are cheap, while an LLM judge adds a model call per evaluated message, so judge-based policies need a narrow scope. Blocking policies add their detection time to each call they cover.

Detection is probabilistic. Classifiers and judges miss some attacks and flag some legitimate work, and both rates depend on the organization’s own traffic, which is why tuning in a log-only mode comes before enforcement.

A gateway governs only the traffic routed through it, so local stdio servers, direct API calls with embedded keys, and uninstrumented clients sit outside it. Discovery sees only enrolled devices and instrumented clients. Some guardrails fail open when a scan times out, which keeps work moving and lets some content through unchecked. Logging tool arguments and results means the log holds copies of the data agents touched, and it needs its own retention and access rules.

Managed guardrails remove the operational work, and self-hosted guardrails keep prompts and tool traffic inside the organization at the cost of a team that runs and updates them.

Which vendors provide AI agent guardrails at each layer?

Vendors sit at different layers, and the layer decides what a product can see. The entries below draw on each vendor’s own documentation as of October 2026. They are grouped by layer and not ranked.

The table summarizes the traffic each control point can inspect and the actions described in this guide. Product coverage varies, and the vendor notes below explain the limits.

Application layer: guardrails for model prompts and responses

These products run inside or beside an application and inspect what goes into and comes out of a model.

• Amazon Bedrock Guardrails. Bedrock Guardrails provide content filters (hate, insults, sexual, violence, misconduct, and prompt attack), denied topics, word filters, sensitive information filters that block or mask PII with custom regex, contextual grounding checks, and Automated Reasoning checks. They run with a model at inference or on their own through the ApplyGuardrail API.
• NVIDIA NeMo Guardrails. NeMo Guardrails is an open-source Python library, with a microservice built on it, that runs input, retrieval, dialog, execution, and output rails configured in YAML and Colang. Execution rails validate tool inputs and outputs, and integrations detect and mask PII.
• Guardrails AI. Guardrails AI is an open-source Python framework that runs input and output Guards built from Guardrails Hub validators, and also generates structured output from models.
• Microsoft Azure AI Content Safety. Azure AI Content Safety includes Prompt Shields for user prompt attacks and for attacks hidden in documents, harm-category text and image analysis, and groundedness detection in preview.
• Check Point AI Guardrails (formerly Lakera Guard). The Guard API screens prompts, outputs, tool calls, tool responses, and tool descriptions for prompt attacks, data leakage, content violations, and malicious links. An application or an AI gateway calls it on each interaction.

Infrastructure layer: AI gateways and edge networks

These products sit in the network path in front of models and apply guardrails to the traffic that crosses them.

• F5 AI Guardrails. F5 AI Guardrails is a model-agnostic runtime layer that inspects prompts and responses for prompt injection, jailbreaks, and data leakage, with custom policies written in natural language. F5 documents public cloud, private cloud, on-premises, and air-gapped deployment, and introduces the product on its community site.
• Cloudflare. AI Gateway guardrails flag or block prompts and model responses for model-provider traffic. Separately, MCP server portals in Cloudflare One can route tool calls through Cloudflare Gateway for DLP scanning of requests to upstream MCP servers, though DLP AI prompt profiles don’t apply to portal traffic.
• Kong AI Gateway. The AI Prompt Guard plugin applies regex allow and deny lists to model requests, and AI PII Sanitizer handles personal data in LLM traffic. Kong’s AI MCP Server docs say prompt and response AI Policies don’t apply to MCP traffic, which gets API-level policies such as authentication, rate limiting, logging, and tool ACLs instead.

Infrastructure layer: MCP gateways for agent traffic

MCP gateways sit between agents and the MCP servers they call, so they see tool requests and tool results that a model-layer filter doesn’t. Cloudflare MCP server portals, described above, and Okta Agent Gateway, described below, also work at this layer. Speakeasy works here too.

Speakeasy. We build the Speakeasy MCP gateway, so read this entry as coming from an interested party. It is part of the Speakeasy AI Control Plane and covers each of the three levels at the agent-traffic layer:

• Approved agents. The Shadow AI inventory lists the coding harnesses, assistants, and local models that enrolled devices report, through a device agent that is enabled per organization. An admin marks each harness or assistant Approved or Blocked, and the MCP gateway refuses a blocked agent client when it authenticates, on every MCP server in the organization. Enforcement works only for clients that publish a client ID metadata document, and local models are inventory only.
• Access controls. Sign-in goes through the organization’s identity provider, and roles narrow down to individual MCP servers and tools. Tailscale private access can serve a server only on the organization’s tailnet. It requires an Enterprise organization with the feature enabled, and it adds a network restriction on top of MCP authentication rather than replacing it. Tunneled MCP servers reach servers inside a private network over an outbound-only connection.
• Data exfiltration. Guardrails are risk policies that scan for secrets, PII, government identifiers, financial and healthcare data, prompt injection, destructive commands, and custom rules, plus prompt-based policies judged by an LLM that can be replayed against recent real sessions before going live. MCP-scoped policies, enabled per organization on request, are enforced by the MCP gateway itself and need no agent hooks. The gateway checks the tool request before forwarding it to the server and the tool result before returning it to the client, and not every gateway checks both.
• Session management. Policies that run on agent sessions through hooks can quarantine a session, freezing its prompts and tool calls until an admin releases it.

Several limits apply. MCP-scoped policies can only log or deny, read the first 50 KiB of each request or result, and let the call through when a scan times out or the content is larger than that. Speakeasy flags, warns, denies, and quarantines, and doesn’t redact or mask matched data, which Bedrock and NeMo Guardrails can. Shadow MCP detection requires Speakeasy hooks on the agent. The control plane runs on Speakeasy-managed infrastructure, so a buyer that needs on-premises or air-gapped inspection should look at vendors that document it, such as F5. The gateway doesn’t route model traffic, so prompt filtering for apps that call models directly needs an application-layer product or an AI gateway. If those limits fit, the Speakeasy MCP gateway page shows how it is set up.

Access controls layer: identity providers for AI agents

Identity providers decide whether an agent gets a token and what it is scoped to. They are integrated with, not replaced by, the other layers.

• Microsoft Entra Agent ID. Conditional Access for agents evaluates policy when Entra issues or refreshes a token for an agent acting for a user, as its own agent identity, or as an agent user account, and agent identity blueprints apply a policy to a class of agents. It protects only resources secured by Entra, so an agent using an API key bypasses it.
• Okta for AI Agents. Okta for AI Agents registers agents as identities in Universal Directory with human owners, discovers shadow agents from the browser and endpoint, and offers a kill switch that revokes an agent’s access. Its Agent Gateway enforces identity, policy, and audit on tool calls, which puts Okta at the MCP gateway layer as well.

Session management layer: controls for live agent sessions

Some products act on a running session rather than on an account or a single call, which needs visibility into the session from inside the agent or a control plane that tracks it. Speakeasy quarantine, described above, freezes a session until an admin releases it, and Okta’s kill switch revokes an agent’s access at the identity layer. Agent session management covers what this layer needs and who owns it.

Where can you learn more about AI agent guardrails?

Each of these pages covers one part of the picture in more depth:

• Level 1, approved agents: shadow AI, agent inventory, agent discovery, and MCP governance.
• Level 2, access controls: agent access management and enterprise MCP auth.
• Level 3, data exfiltration: agent DLP, prompt injection, and MCP tool poisoning.
• Session management: agent session management.
• Infrastructure: MCP gateway, AI gateway, private MCP gateway, and MCP tunnels.
• Policy and context: agent governance, AI security, and the AI Control Plane.

If you want to discuss where guardrails should run for your agents, talk with our team.