MCP Bouncer 0.1.4 puts a local policy check between an AI agent and its Model Context Protocol tools. If the agent tries to send information to a destination it encountered in untrusted tool output, the proxy can deny the call before it reaches the server.
The MIT-licensed project takes a deliberately narrow approach to prompt injection. It does not ask another model whether an email, document or ticket contains malicious instructions. It assumes the agent may already have been fooled, then limits what that agent can do through the tools it wraps. Its enforcement rules are deterministic, and every allow, deny or request for approval is logged. The repository describes version 0.1.4 as early software, supporting MCP over standard input/output on one machine.
The important qualification sits alongside the security result. In the project’s latest AgentDojo benchmark, Bouncer allowed no sends at all. Attacker sends fell to zero, but legitimate email and file-sharing task completion also fell to zero. That makes this a useful demonstration of an action-level barrier, with a substantial unresolved usability problem.
How Bouncer Decides Whether a Send Can Proceed
bouncer run launches an MCP server as a subprocess and sits between that server and the client. It records the server’s tool list at startup, checks subsequent calls and forwards only those permitted by its rules.
The documented enforcement sequence covers several separate controls:
| Check | What it controls | Practical consequence |
|---|---|---|
| Startup tool inventory | Whether a tool was present when the server started | Newly introduced tools are refused |
| Per-session call budget | How many times a tool may run | A destructive action can be limited, though its first permitted call may still execute |
| Path and argument checks | Permitted paths and regex constraints on arguments | Writes can be confined to a workspace, and arguments constrained |
| Destination check | Whether a send target appeared in untrusted output, is trusted or needs approval | Sends can be denied or escalated before reaching the server |
The destination rule is the distinctive part. Bouncer records the server’s returned text and structured content as untrusted. When a later call supplies a destination, the proxy normalizes case and whitespace, then looks for that destination in output the same server returned during the session.
A destination found in that untrusted output is grounds for denial. The documentation also provides for allowlisted and approved destinations to pass. If Bouncer cannot establish where a destination came from, it asks a human instead of silently allowing the action. Approval is remembered for the rest of the session.
Consider a poisoned support ticket that tells an agent to send a customer list to attacker@evil.example. Once that address has appeared in the ticket output, a subsequent email call to it can be stopped at the proxy. Bouncer does not need to understand the ticket’s prose or decide whether its instructions sound suspicious.
That separation is useful. My view is that a reproducible action rule is easier to reason about than a second model’s judgment about malicious intent. It also exposes the cost clearly: a legitimate new recipient found in a support ticket can have the same provenance as an attacker’s address. Provenance alone cannot tell Bouncer which business purpose is valid.
The Threat Model Stops at the Wrapped MCP Boundary
Bouncer’s destination matching is literal, after case and whitespace normalization. It is not a general-purpose analysis of where information ultimately flows. An encoded destination that cannot be traced goes to the unknown-destination path, which requires approval. It is not automatically permitted because the literal match failed.
That conservative fallback matters, but the boundary remains narrow. The project’s scope and limits are consequential:
- Only MCP calls through the proxy are covered. Shell commands and raw HTTP access remain outside its protection.
- Destination history is tied to the same server’s output in the current session. Readers should not assume a shared provenance system spanning every tool and process.
- Prompt injection itself is not detected. The agent can still read and follow hostile instructions; Bouncer constrains particular resulting actions.
- Trusted destinations can receive sends. The policy therefore depends on which recipients an operator chooses to trust.
- Call budgets bound activity, not intent. A permitted destructive call can still cause damage.
The trusted-destination exception deserves particular attention. If a workflow routinely sends sensitive data to an approved address, destination checking alone cannot determine whether a particular message contains the right information. That follows from what the control checks: where the action goes, not whether its content fulfills the user’s request.
I would treat Bouncer as a constrained-tool layer, not as permission to give an agent unrestricted alternative routes. An agent with an unwrapped HTTP or shell tool has capabilities outside the stated enforcement boundary.
The Benchmark’s Zero Comes With a Steep Utility Cost
The latest published benchmark summary is dated October 23, 2026. It reports a project-run evaluation using openai/gpt-4o-mini, AgentDojo workspace v1.2.2 and 40 user tasks. These are the developer’s measurements, not independent testing.
The results page separates attacker-goal success from whether a send to the attacker occurred:
| Published metric | Without Bouncer | With Bouncer |
|---|---|---|
| Attacker goal achieved, in-scope cases | 48 of 164 | 0 of 163 |
| Cases in which a send to the attacker ran | 106 | 0 |
| Legitimate task completion, without an attack | 33 of 40 | 30 of 40 |
| Completion of the six sending tasks, without an attack | 4 of 6 | 0 of 6 |
The attack-case counts differ between conditions, so these should not be described as 164 perfectly paired trials. A send reaching an attacker and the attacker achieving its full goal are also distinct measurements.
The project is explicit about the central limitation:
“Bouncer allowed no send at all in this run”
That means the zero attacker-send result follows from denying the entire class of actions in this configuration. It demonstrates that the barrier stopped those sends. It does not show a configuration that reliably distinguishes malicious sends from legitimate ones.
Aggregate Completion Hides the Workflow Failure
Overall benign task completion declined from 82.5% to 75%, a loss of 7.5 percentage points. On its own, that could look like a relatively modest cost. The sending-task breakdown tells a more useful story: completion fell from four of six tasks to none.
The published totals also permit a simple calculation:
- Excluding the six sending tasks, baseline completion was 29 of 34.
- With Bouncer, completion of those other tasks was 30 of 34.
- Four lost sending-task completions were partly offset by one additional completion elsewhere.
Those figures are arithmetic derived from the project’s reported totals, not a separate experiment. They explain why an aggregate utility score can conceal the failure of the capability a team actually needs.
For a read-heavy assistant, retaining most overall task completion may be useful. For an assistant deployed specifically to send email or share files, the zero-of-six result is the more relevant number. I would want evidence that a proposed policy preserves that workflow before using the overall 75% figure to justify deployment.
The results page also preserves earlier, smaller experiments. It explicitly says a July finding of improved utility did not generalize to a larger September run. Historical results used a different harness, including a shared Bouncer engine across cases in a pass, and are not directly comparable with the latest run. The latest summary is the sounder basis for interpreting the current security-versus-utility tradeoff.
Installing Bouncer Around an Existing MCP Server
The project documents installation with uv or pipx, using Python 3.12 or newer. Its standard setup wraps entries in an existing client configuration containing an mcpServers block.
For a client using .mcp.json, the documented installation path is:
uv tool install bouncer-mcp
cp .mcp.json .mcp.json.bak
bouncer init --config .mcp.json
The first command installs the package. The second backs up the existing configuration. The third prints a rewritten configuration and asks for confirmation before writing it. These are the project’s instructions, not commands executed for this article.
pipx install bouncer-mcp is the documented installation alternative. The package-install command above does not pin version 0.1.4, so it should not be read as a promise that future installations will reproduce this version.
Frequently Asked Questions
3 questions
1Does MCP Bouncer detect prompt injection?
No. It assumes an agent may follow malicious instructions and constrains resulting MCP calls using destination rules, path checks, argument checks and call budgets.
