MCP Output Firewall MCP server

mcp-output-firewall

A three-layer firewall for MCP servers.

An MCP-enabled agent reads the output of every tool it calls, and it reads that output as data. Sometimes it isn't data. Anyone with write access to a file, an issue, a database row, or a web page the agent fetches can plant text that looks like data and reads like instructions — and the model does what the text says.

Existing MCP gateways solve authorisation: who is allowed to call this tool. They do not solve content: whether what came back can be trusted. A perfectly legitimate tool call can return poisoned data, and an authorisation layer has no opinion about that at all.

mcp-output-firewall sits in that gap.

Three layers, because one is not enough

Content filtering is defeatable. That is not a defect of this implementation; it is the state of the field. The honest response is not a better regex list, it is a posture with more than one failure mode.

Layer 1 is the one everyone builds. Layers 2 and 3 exist because layer 1 loses.

Why layer 2 matters most

The content scanner never sees the tool call. That is where the damage happens. A tool named fetch_url with the description "Retrieve the contents of a URL" is honest, well-behaved, and completely safe to install — right up until a poisoned tool result tells the agent to call it with http://169.254.169.254/latest/meta-data/iam/security-credentials/.

No amount of scanning the response can catch that, because the attack isn't in the response. It's in the request.

mcp-output-firewall wrap --egress-strict \
  --egress-allow api.company.com,registry.npmjs.org \
  -- npx -y some-mcp-server

Blocked by default: cloud instance metadata endpoints, private ranges, loopback, DNS-tunnelling hostnames, and known drop-host patterns. Everything else that is unrecognised is permitted but logged — this is not a web filter and does not pretend to be one.

Why layer 3 exists

Meta's "Rule of Two" for agent design: an agent may combine at most two of (a) processing untrusted input, (b) access to sensitive systems, and (c) changing state externally. An agent reading tool results permanently has (a). So any call that is both sensitive and state-changing is asking for all three at once — and that is the shape of every real agent incident.

mcp-output-firewall wrap --confirm-actions \
  --trust-tools read_file,list_directory \
  -- npx -y some-mcp-server

Read-only tools are never interrupted. Destructive arguments (rm -rf /, DROP TABLE, pipe-to-shell) are refused outright. Consequential but legitimate operations (file writes, git push, payments) require an explicit yes.

Two shapes, because the check has two possible locations

Shortened. The full README is on GitHub.