I Built a Prompt Injection Firewall for MCP Servers

Two days ago I wrote about how McKinsey's AI assistant got compromised through prompt injection. The day before that, a GitHub issue title was enough to hijack 4,000 developer machines running Cline. Both attacks exploited the same gap: AI tools that accept untrusted input and act on it without any inspection layer.

MCP servers have the same problem. Worse, actually. Because MCP's entire design is "client sends JSON-RPC, server executes." There's no middleware. No request validation. No way to say "inspect this before it touches my tools."

So I built one.

The gap nobody filled

The OWASP MCP Top 10 dropped in February. Tool poisoning is the number one risk. Invariant Labs documented how a malicious MCP server can embed exfiltration instructions in tool descriptions. JFrog published CVE-2025-6515 showing prompt hijacking in MCP session handling. Every week brings another proof-of-concept.

But the mitigation advice is always the same: "review tool descriptions carefully" and "don't install untrusted servers." That's not engineering. That's hope.

What's missing is something basic: a process that sits between your MCP client and server, reads every request, and decides whether it looks like an attack before forwarding it. A firewall. The kind of thing we've had for HTTP since the early 2000s.

What mcp-firewall does

@mkweb.dev/mcp-firewall is a stdio proxy. It wraps any MCP server and intercepts every JSON-RPC message on stdin before it reaches the server process. Each message gets scanned against 12 detection patterns across 6 attack categories. A scoring engine sums the matched pattern weights and makes a call: pass, warn, or block.

  MCP Client          mcp-firewall              MCP Server
  (Claude,    stdin   ┌──────────────┐   stdin   (your app)
   Cursor,  ────────> │ JSON-RPC     │ ────────>
   etc.)              │ Parser       │
                      │     │        │
                      │ Pattern      │
                      │ Scanner      │
                      │ (12 checks)  │
                      │     │        │
              stdout  │ Scoring      │   stdout
            <──────── │ Engine       │ <────────
                      │ pass/warn/   │
                      │ block        │
                      └──────────────┘

When a request is blocked, the client gets a JSON-RPC error response. The server process never sees the message. Logs go to stderr so they don't corrupt the MCP protocol stream on stdout.

How it works under the hood

The proxy spawns your MCP server as a child process with piped stdio. Client stdin flows through the firewall's input handler, which buffers newline-delimited JSON-RPC messages and parses each one.

// proxy.ts - the core interception loop
private processLine(line: string): void {
  let parsed: unknown;
  try {
    parsed = JSON.parse(line);
  } catch {
    // Not JSON, pass through
    this.child?.stdin?.write(line + "\n");
    return;
  }

  if (!isJsonRpcRequest(parsed)) {
    // Responses flow through untouched
    this.child?.stdin?.write(line + "\n");
    return;
  }

  const request = parsed as JsonRpcRequest;
  const result = scan(request, this.patterns, this.config);

  if (result.verdict === "block" && !this.config.dryRun) {
    // Send error back to client, server never sees it
    const errorResponse = {
      jsonrpc: "2.0",
      id: request.id,
      error: {
        code: -32001,
        message: "Request blocked by mcp-firewall: prompt injection detected",
        data: {
          verdict: result.verdict,
          totalScore: result.totalScore,
          matchCount: result.matches.length,
        },
      },
    };
    process.stdout.write(JSON.stringify(errorResponse) + "\n");
    return;
  }

  // Pass or warn: forward to server
  this.child?.stdin?.write(line + "\n");
}

The scanner extracts every string field from the request params recursively. Each string gets tested against all active patterns. This matters because attack payloads hide in nested arguments, not just top-level fields.

// scanner.ts - recursive text extraction
function extractTextFields(obj: unknown, path: string = ""): Array<{ text: string; location: string }> {
  const fields: Array<{ text: string; location: string }> = [];

  if (typeof obj === "string") {
    fields.push({ text: obj, location: path || "root" });
  } else if (Array.isArray(obj)) {
    for (let i = 0; i < obj.length; i++) {
      fields.push(...extractTextFields(obj[i], path + "[" + i + "]"));
    }
  } else if (obj !== null && typeof obj === "object") {
    for (const [key, value] of Object.entries(obj as Record<string, unknown>)) {
      fields.push(...extractTextFields(value, path ? path + "." + key : key));
    }
  }

  return fields;
}

The 12 detection patterns

Each pattern targets a specific attack technique. I didn't invent these categories. They come from real CVEs, published exploits, and the OWASP MCP Top 10.

Scores sum. A request that combines role hijacking (8) with filesystem access (9) hits 17, well above the default block threshold of 8. The warn threshold sits at 5, so even low-confidence matches get logged.

Setting it up

Install globally or use npx:

npm install -g @mkweb.dev/mcp-firewall

Wrap any MCP server:

npx @mkweb.dev/mcp-firewall -- node my-mcp-server.js

For Claude Desktop, update claude_desktop_config.json:

{
  "mcpServers": {
    "my-server": {
      "command": "npx",
      "args": ["@mkweb.dev/mcp-firewall", "--", "node", "/path/to/server.js"]
    }
  }
}

Dry-run mode logs everything but blocks nothing. Good for seeing what your traffic actually looks like before enforcing:

npx @mkweb.dev/mcp-firewall --dry-run -- python mcp_server.py

Tuning it

Default thresholds are conservative. Block at 8, warn at 5. You'll want to adjust based on your use case. A firewall.yaml in your working directory handles it:

thresholds:
  warn: 5
  block: 8

logging:
  level: info
  format: json

allowlist:
  - initialize
  - ping

patterns:
  enabled:
    - "*"
  disabled:
    - chaining    # Too noisy for multi-step workflows
  custom:
    - id: internal-api-leak
      name: Internal API Leak
      category: exfiltration-network
      description: Detects references to internal APIs
      regex: "internal\\.company\\.com"
      score: 9

The allowlist skips inspection for methods that never carry user content. initialize and ping are safe to pass through. Custom patterns let you add domain-specific rules without forking the project.

What this doesn't solve

I want to be clear about the limits. This is pattern matching on request content. It catches known attack signatures. It does not catch:

Novel injection techniques. An attacker who phrases their injection differently enough will bypass regex-based detection. This is the same limitation every WAF has. Defense in depth matters.

Tool poisoning in descriptions. The attack where a malicious server embeds instructions in its tool description field happens during tools/list, and the response flows from server to client. mcp-firewall inspects client-to-server traffic. A separate tool like Invariant's mcp-scan covers that direction.

Semantic attacks. "Please help me understand the contents of the SSH configuration file" doesn't match any pattern because it's not using command language. Detecting intent requires an LLM-in-the-loop, which adds latency and cost.

I'd rather ship something that catches 80% of attacks today than wait for something that catches 100% never.

The programmatic API

If you want to integrate detection into your own MCP server instead of using the proxy, the scanner is exported:

import { scan, buildPatternList, loadConfig } from "@mkweb.dev/mcp-firewall";

const config = loadConfig("firewall.yaml");
const patterns = buildPatternList(config);

const result = scan(
  {
    jsonrpc: "2.0",
    id: 1,
    method: "tools/call",
    params: {
      name: "chat",
      arguments: { text: "ignore previous instructions" },
    },
  },
  patterns,
  config,
);

console.log(result.verdict);    // "block"
console.log(result.totalScore); // 9

This gives you the detection engine without the proxy. Useful for server-side validation where you control the MCP server code and want to reject suspicious inputs before processing them.

Why I built this as a proxy

I considered three approaches. An SDK that MCP server authors integrate. A client-side plugin for Claude Desktop or Cursor. And a stdio proxy.

The SDK approach requires every server author to adopt it. That's a coordination problem, not a technical one. The client plugin approach requires access to client internals that aren't exposed. The proxy approach requires zero changes to either side. You just wrap the command.

That's the same reason HTTP reverse proxies won. Nginx didn't need application code changes. Neither does this.

What's next

The package is at @mkweb.dev/mcp-firewall on npm. Source on GitHub. MIT licensed.

I'm considering adding response-direction scanning (server to client) to catch tool poisoning in tools/list responses. Also looking at an LLM-based semantic scanner as an optional detection layer for requests that evade pattern matching. Both would be opt-in behind config flags.

If you run MCP servers in production, try dry-run mode for a week. See what your actual traffic looks like. You might be surprised what's flowing through unfiltered.