Vasu Dalal

Posted on Jul 4

The NSA wrote the MCP threat model. It never says what your agent does after the block.

#ai #llm #mcp #security

In May 2026 the NSA's AI Security Center published a Cybersecurity Information Sheet: Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation (U/OO/6030316-26). It is the first government-authored threat model for MCP, and if you run agents through MCP servers, it is worth the read.

Read it end to end and one word never appears: recover.

That absence is the whole point of this post.

The part the NSA gets exactly right

The report does not treat a tool call like an API request. It treats it like a loaded gun:

"It is prudent to treat any tool execution triggered via MCP as a potentially high-risk action."

And it says where the check belongs. Not on the network, not in a scanner you run before deployment, but at runtime, in the process, at the moment the action would happen:

"if a server does not require access to sensitive file systems, model or data files, or internal networks, those access paths should be explicitly denied at runtime."

It goes further and describes output filtering that reads like a product spec:

"Each output must be treated as untrusted input to the next phase of the pipeline... Filtering should include content length checks, disallowed keyword scanning, rate limiting, and application specific policy enforcement... detection of indirect prompt injection or toolchain pivot attempts."

If you have ever argued that an API gateway or a WAF cannot see an agent run rm -rf or open its own database socket, the NSA just wrote that argument down for you. The enforcement point is inside the process, where text becomes action.

The half it leaves to you

Here is what the report does not do. Every one of its mitigations is prevention: block, sandbox, validate, sign, log, scan, patch. Not one of them says what your agent does after a dangerous call is stopped.

In a normal web app that is fine. A blocked request returns a 403 and a human retries. In an autonomous run, that same block lands in the middle of a multi-step task and the agent gives up. You did not get safety. You traded one broken outcome for another, and you burned the tokens getting there.

The NSA even names the requirement without offering an answer:

bring MCP in line with secure practices "without stifling the flexibility and power that make it attractive in the first place."

Blocking the call and killing the run is stifling it. The report says the block has to happen and says nothing about keeping the agent working through it. That gap is the interesting engineering problem, and it is where we spend our time.

Both halves, one line in mcp.json

agentx-mcp is a small stdio proxy. It spawns your real MCP server, relays the protocol untouched, and screens every tools/call before it runs:

{
  "mcpServers": {
    "database": {
      "command": "agentx-mcp",
      "args": ["npx", "-y", "your-real-mcp-server", "..."]
    }
  }
}

pip install agentx-security-sdk   # ships the agentx-mcp command

The block (the NSA's "high-risk action, denied at runtime"): a deterministic floor catches the blatant catastrophic calls before they reach the server. A DROP TABLE, an unscoped DELETE, a secret-store read, an SSRF to 169.254.169.254, an rm -rf. No API key, nothing leaves your machine, no model in the hot path for the block. It screens the protocol, so it works with any MCP-speaking stack. You can verify that part in two minutes without trusting me.

The half the report skips: the block does not end the run. The agent gets back what it needs to correct, and on the MCP path its own model does the correcting, so the task finishes instead of dying on the block. You can watch the whole block-and-recover loop for free.

Here it is end to end on a real MCP server. The task is "report the user count," and the query hides an injection: SELECT name FROM users; DROP TABLE users;

The DROP TABLE never reaches the database. The run keeps going and still returns the right answer: three users, table intact, task done.

What this is not

To be clear about scope, because the report is broader than any one tool:

The NSA doesn't endorse products. The CSI carries an explicit disclaimer, and this post is not affiliated with them. The report describes the requirement. This is one way to meet part of it.
The report also recommends message signing, token lifecycle controls, DLP proxies, and network scanning for rogue MCP servers. Those are real, and they are not this. agentx-mcp is the runtime action-enforcement and output-filtering layer, plus the recovery the report leaves open. Compose it with the rest.

Try it, and tell me what it caught

I want people running MCP servers against something real (a database, a filesystem, cloud, internal APIs) to wrap one and tell me two things:

What did it catch that would have bitten you?
What dangerous tool call did it miss? Try to stump it.
Watch the catch-and-recover live, and try it: https://bit.ly/agentfirewall
Tell me what broke or what it missed: https://discord.gg/PmWRTtaSx2

The NSA said treat every tool call as high-risk and deny at runtime. Fair. The next question is what your agent does the second after you do.

DEV Community