What Are MCP Guardrails? How Tool-Level Policy Enforcement Works
TL;DR
- MCP guardrails validate tool arguments before a call executes and tool results after it returns, a boundary that LLM-only content filters never inspect.
- Bifrost evaluates MCP guardrail rules with CEL expressions matched against
mcp_client,mcp_tool, andmcp_arguments, then routes matches to one or more linked guardrail profiles. - A rule can allow, block, or redact at each phase; a block before execution stops the tool call from running at all.
- MCP guardrails use the same provider ecosystem as LLM guardrails, including Presidio, AWS Bedrock Guardrails, Azure Content Safety, Patronus AI, and Lakera Guard, with no separate MCP-specific setup.
- Guardrails are one layer of a broader MCP governance stack that also includes tool groups, virtual keys, and federated authentication.
MCP guardrails are policy-driven checks that inspect and control what an AI agent does when it calls a tool through the Model Context Protocol (MCP), rather than only checking what the underlying language model says. Bifrost, the open-source AI gateway built in Go by Maxim AI, enforces these checks at the point where a tool call is about to execute and again after it returns a result, closing a gap that prompt-level content filters were never designed to cover. This post explains how MCP guardrails work, what they protect against, and how to configure one as a rule.
Why MCP Tool Calls Need Guardrails Beyond LLM Security
An LLM guardrail inspects a prompt going in and a completion coming out. It never sees what happens between those two events when a model decides to call a tool. That gap matters because tool calls are where an agent stops talking and starts acting: reading a file, querying a database, opening a support ticket, moving money between accounts.
MCP security has to cover a different boundary than model-level filtering. A prompt that passes every content check can still produce a tool call with a destructive argument, and a tool result that looks like ordinary text can carry a prompt injection payload back into the model's context on the next turn. Bifrost's MCP integration is explicit that tool calls proposed by an LLM are suggestions, not commands: execution requires a separate step, which is exactly the step MCP guardrails sit in front of and behind. Even Agent Mode, which allows configurable auto-execution of specific tools, still passes every call through this same guardrail boundary before anything runs.
Rules and Profiles: How MCP Guardrails Work
Bifrost's guardrails system is built from two objects that work together.
- Rules are policies written as CEL (Common Expression Language) expressions that decide which requests or tool executions get evaluated, and when.
- Profiles are reusable configurations for a specific guardrail provider, whether that is a Bifrost-managed check like secrets detection or an external provider like AWS Bedrock Guardrails.
A rule targets one of two boundaries, set by the target field:
| Target | Input phase | Output phase |
|---|---|---|
llm |
Before the request reaches the model provider | After the model provider responds |
mcp |
Before the MCP tool executes; guardrails inspect or redact its arguments | After the tool returns; guardrails inspect or redact its result |
The two targets are intentionally isolated. An mcp rule can reference mcp_client, mcp_tool, and mcp_arguments, but not model. An llm rule can reference model and params, but not mcp_tool. Both targets share headers, virtual_key, customer, team, and user, so the same identity fields apply regardless of which boundary a rule is protecting.
LLM Guardrails vs MCP Guardrails: What Each One Covers
LLM guardrails and MCP guardrails run through the same rules-and-profiles engine, but they answer different questions. The table below separates what each boundary actually checks.
| LLM guardrails | MCP guardrails | |
|---|---|---|
| What is inspected | Prompt text sent to the model, completion text returned | Tool arguments before execution, tool result after execution |
| Typical risk addressed | PII in prompts, toxic or off-policy completions, prompt injection in the input | A tool call reading or writing something it should not, a tool result carrying injected instructions |
| CEL variables available | model, provider, params, plus shared identity fields |
mcp_client, mcp_tool, mcp_arguments, plus shared identity fields |
| Where a block lands | Before the model call, or before the response reaches the caller | Before the tool executes, or before the result is returned |
Neither boundary substitutes for the other. A deployment that only runs LLM guardrails at the gateway layer still has an unguarded tool-execution step, since the argument values a model sends to a tool are not the same payload as the prompt that produced them. This is one reason MCP server governance treats the two boundaries as separate controls rather than one combined filter.
What MCP Guardrails Protect Against
The risk categories specific to MCP are different from generic prompt-injection risk, and they are serious enough that OWASP maintains a dedicated MCP Top 10 project cataloging the failure modes most likely to compromise an MCP deployment. Three show up repeatedly in production incidents:
- Tool poisoning. A malicious or compromised MCP server embeds hidden instructions inside a tool's description field, a location the model reads but a user never sees in the UI. Invariant Labs documented this pattern as a form of indirect prompt injection that exploits the asymmetry between what a tool description shows a human and what it hands to the model.
- Argument-level data exposure. A tool call can carry a credential, a customer record, or a file path outside its intended scope in its arguments, well before the request touches an LLM's output filter.
- Result-level injection. Text returned from a tool (a scraped web page, a file's contents, an API response) can carry instructions the model treats as trusted context on the next turn, because nothing distinguishes tool output from a legitimate system instruction.
MCP guardrails address all three by inspecting the argument payload before a tool runs and the result payload before it returns, which is the only point in the pipeline where both of those values exist in isolation from the rest of the conversation. This is also why tool execution in Bifrost is a distinct, controllable step rather than something the model triggers directly, and why teams evaluating a best-fit AI gateway for governance and guardrails should check whether tool-level checks are covered at all, not only prompt-level ones.
Configuring an MCP Guardrail Rule
A guardrail rule has a small, consistent shape regardless of target. The properties that matter most for an mcp rule are target, cel_expression, and apply_to.
| Property | Type | Description |
|---|---|---|
target |
enum | llm (default) or mcp |
cel_expression |
string | CEL expression that decides whether the rule applies |
apply_to |
enum | input (tool arguments), output (tool result), or both |
sampling_rate |
integer | Percentage of matching requests to evaluate (0-100) |
provider_config_ids |
array | Guardrail profiles linked to this rule |
The following example creates a rule that inspects the arguments of a GitHub create_issue call before it executes, using Bifrost's guardrail API:
curl -X POST <http://localhost:8080/api/guardrails/rules> \
-H "Content-Type: application/json" \
-d '{
"name": "Protect GitHub issue creation",
"description": "Inspect arguments before the GitHub tool creates an issue",
"enabled": true,
"target": "mcp",
"celExpression": "mcp_client == \"github\" && mcp_tool == \"create_issue\"",
"applyTo": "input",
"samplingRate": 100,
"selectedGuardrailProfiles": ["regex:1", "bedrock:2"]
}'
CEL expressions can also inspect individual argument values. A rule that flags any tool call moving more than 1,000 units in an amount argument looks like this:
("amount" in mcp_arguments) && mcp_arguments["amount"] > 1000
Once the CEL expression matches, Bifrost applies whichever phase the rule targets:
| Apply on | Flow |
|---|---|
Before tool call (input) |
Inspect arguments, then allow or redact and execute; a block stops execution before it starts |
After tool result (output) |
Execute the tool, inspect the result, then allow or redact and return; a block withholds the result |
| Both | Run the input flow; if allowed, execute the tool and run the output flow. A block at either boundary stops the request |
Guardrail Providers You Can Use for MCP Rules
Every provider supported for LLM guardrails also works for mcp rules without separate configuration. A single MCP rule can link multiple profiles for layered checks.
| Provider | What it checks |
|---|---|
| Secrets detection | Gitleaks-backed detection of leaked API keys, tokens, and private keys |
| Custom regex | Organization-specific patterns, including a built-in PII detection template |
| Microsoft Presidio | PII detection, blocking, and redaction |
| AWS Bedrock Guardrails | Content filtering, PII detection, prompt-attack prevention |
| Azure Content Safety | Multi-modal content moderation with severity-based filtering |
| Patronus AI | LLM security and hallucination detection |
| Lakera Guard | Prompt injection and sensitive-data exposure detection |
Provider capabilities differ in one respect worth noting before rollout: not every provider supports Bifrost-managed redaction. Providers outside that list can still detect or block a match; they return provider-managed transformations rather than letting Bifrost apply its own redaction strategy to the flagged text.
Streaming and Redaction: What Happens When a Rule Matches
An MCP guardrail rule can respond to a match in three ways: allow the content through, block it outright, or redact the specific text a provider flagged. Redaction has three modes, and the choice matters for anyone running under a compliance requirement:
- Runtime rewrites the live request or response and stores the same redacted value in logs.
- Logs only leaves runtime content untouched but redacts what lands in Bifrost's logs and trace-export connectors.
- Runtime + reversible logs redacts both runtime content and logs, using numbered placeholders a permitted user can later reveal.
For output guardrails on streaming responses, a detect-only or logs-only rule observes the stream without adding latency, while a rule capable of blocking holds the full response until the guardrail evaluation completes, since a client cannot un-send tokens once they have been delivered. Bifrost documents the full redaction behavior matrix, including which providers support each mode and how trace-export connectors handle redacted content.
MCP Guardrails as Part of Broader MCP Governance
Guardrails answer "is this specific call or result safe to allow." They are not the only control in MCP governance; they sit alongside controls that answer a different question: "should this identity be able to see this tool at all."
- MCP tool groups curate which tools a virtual key, team, customer, or user can discover in the first place, resolved at request time from up to six attachment dimensions.
- Virtual keys carry the budgets, rate limits, and per-consumer permissions that guardrail rules can reference through the shared identity fields.
- MCP with federated auth turns existing enterprise APIs into MCP tools without custom glue code, which means the same guardrail rules apply to internally built tools as to third-party MCP servers.
- Data access control and access profiles let teams pre-allocate consistent provider, model, budget, and MCP policies to virtual keys at scale, rather than configuring each one individually.
Together these layers form what a production MCP gateway needs to run agentic workloads safely: tool groups decide what is visible, virtual keys decide who is calling, and guardrails decide whether a specific call or result is allowed to proceed. A governed enterprise MCP gateway applies these controls consistently across every tool a team connects, rather than per-integration.
Coverage that stops at the model boundary, without extending to the gateway and the endpoint where AI tools actually run, leaves the tool-execution layer unmonitored regardless of how strong the LLM-level filtering is. The same endpoint security and guardrails that Bifrost Edge extends to individual machines are configured centrally at the gateway, so a rule written once applies everywhere.
Best Practices for Rolling Out MCP Guardrails
- Start with detection, not blocking. Run new rules in a detect-only or audit mode first, confirm the false-positive rate against real traffic, then move to blocking once the rule's behavior is understood.
- Scope rules to specific tools and clients. A CEL expression like
mcp_client == "github" && mcp_tool == "create_issue"is easier to reason about and tune than a blanket rule applied to every tool call. - Cover both phases for high-risk tools. Tools that write data (create, update, delete operations) benefit from an input rule that validates arguments and an output rule that checks whether the result leaked anything unexpected.
- Match redaction mode to the compliance requirement. Logs-only redaction is often enough for internal audit trails; regulated workloads that need to prove what a user saw at runtime should use runtime or runtime-reversible redaction instead.
- Treat guardrails as one layer, not the whole control. Pair guardrail rules with tool groups and tool filtering per virtual key so a tool that should never be visible to a given consumer is not discoverable in the first place, rather than relying on a guardrail to catch every call to it.
- Weigh guardrail coverage when comparing gateways. A gateway built for secure and responsible enterprise AI should support guardrails, tool groups, and virtual keys as one connected system rather than separate add-ons.
Frequently Asked Questions
What are MCP guardrails?
MCP guardrails are policy rules that inspect and control MCP tool calls at the point of execution: validating tool arguments before a call runs and validating the tool's result before it is returned to the model.
What are guardrails in LLM applications?
LLM guardrails are policies that validate a prompt before it reaches a model and validate the completion after the model responds, checking for issues like PII exposure, prompt injection, and policy violations in text.
How does MCP handle security?
MCP itself treats tool calls proposed by a model as suggestions requiring a separate execution step, which gives a gateway the room to apply authentication, tool filtering, and guardrail rules before any tool actually runs.
What do MCP tools stand for?
MCP tools are external capabilities, such as a database query, a file read, or an API call, that an MCP server exposes so an AI model can discover and invoke them at runtime instead of being limited to text generation.
What are types of guardrails?
Guardrails vary by what they check (LLM prompts and completions versus MCP tool arguments and results) and by what they do on a match: detect only, block, or redact the flagged content using a configured strategy.
Can one guardrail rule cover both LLM and MCP checks?
No. A rule's target field is either llm or mcp, and the CEL variables available to each are isolated from the other, so protecting both boundaries requires separate rules linked to the same or different profiles.
Do MCP guardrails add latency to tool calls?
Detect-only and logs-only checks run without delaying delivery. Rules capable of blocking hold the request until the guardrail evaluation finishes, since a block has to happen before the tool executes or before the result is returned.
To see how MCP guardrails, tool groups, and virtual keys work together to govern agentic workloads at scale, book a demo with the Bifrost team.
