The NSA Issued Its First MCP Security Guidance. Here Are the 3 Gaps It Didn't Solve.

The NSA has issued its first MCP security guidance: a Cybersecurity Information Sheet titled "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation", dated May 2026. That's not a sentence I expected to type in 2026.

The Model Context Protocol powers how AI agents talk to tools, databases, and APIs. It's the connective tissue of the agent stack. 97 million monthly SDK downloads. Adoption by OpenAI, Google, and Microsoft. And now, for the first time, a national security agency is telling the world how to deploy it safely.

I read through the guidance carefully. It's solid as a foundation. But three gaps stood out. Gaps that, if you're deploying MCP servers in production, you need to solve yourself.

TL;DR

The NSA named the right problems: supply chain, input validation, least privilege
But it didn't solve for pre-action authorization. Verifying intent before execution
It missed agent-level identity entirely. The guidance treats the MCP server as the boundary, not the agent
It also skipped revocation. What happens when a trusted agent goes rogue mid-session
If you follow only the NSA's guidance, your MCP servers will be safer. They won't be safe

What the NSA got right

Three of the guidance's nine recommendations stand out. (The others cover trust boundaries, signed messages, output filtering, logging, patching, and scanning your own network for stray MCP servers.)

Supply chain hygiene for MCP servers. Verify the MCP server code itself isn't compromised before you let your agents talk to it. Treat third-party MCP servers like you'd treat a new npm dependency with full filesystem access. This is basic, overdue, and necessary.

Input validation at the protocol boundary. MCP servers accept tool call descriptions from the model. If those descriptions contain path traversal or injection patterns, the server needs to catch them before they hit the underlying system. Endor Labs found 82% of MCP servers prone to path traversal and 67% to code injection. This isn't hypothetical.

Least privilege for tool access. Don't give your MCP server access to databases it doesn't need. Don't expose the full filesystem when a single directory would do. Zero Trust applied to the agent stack. The right instinct.

These are table stakes. If you weren't doing them, start today. Your agents will survive the weekend.

Gap 1: the guidance treats MCP servers as the boundary, and they aren't

The NSA's mental model is perimeter defense. Lock down the MCP server, and you've locked down agent access. It's a web server security model applied to something that is fundamentally not a web server.

The guidance concedes the point in one line and moves on: "Associating a session to an identity is not defined by the protocol, but optionally achieved at the discretion of the implementor."

Here's the problem: an MCP server doesn't know which agent is calling it. It knows a request came in over the protocol. It validates the request's shape. But it has no idea whether the agent requesting access to the customer database is a legitimate refund agent or a compromised instance that got prompt-injected 30 seconds ago.

This is the difference between authorization at the API level and authorization at the agent level.

An MCP server can check: "Is this a well-formed request?" It cannot check: "Is this particular agent actually authorized to call this tool, with this input, at this moment, for this purpose?"

The guidance treats the question as answered once the MCP server is hardened. It isn't.

Gap 2: no agent identity, no pre-action authorization

This is the biggest miss. The NSA guidance notes that MCP lacks a way to exchange role-based permissions when a session starts, but it never treats agent identity as a first-class security primitive.

In the physical world, we don't secure buildings by only checking that the key turns in the lock. We check who the key belongs to, whether they're allowed to be here at this hour, and whether anything has changed since their last visit.

MCP today has none of that. In a typical deployment, every agent connects to the MCP server using the same service credential. There's no per-agent identity, no per-request authorization, no way to say "Agent X can read the orders table but never write to it" in a way that travels with the agent.

The guidance gets close to pre-action authorization (verifying what an agent is allowed to do before the tool executes) and stops short. It says dynamic tool discovery "should be treated with caution unless it can be coupled with origin verification or authorization checks", and it flags that an already-trusted server can change what it does without anyone being re-prompted. But it never turns that into a requirement to check each action against the calling agent's permissions before the tool runs. Its recommendations lean on sandboxing, filtering proxies, and parameter validation. Those are network-level and process-level controls. This is an identity-level problem.

Since Microsoft published its Agent Governance Toolkit at Build, and Linx Security launched agentic access control, the industry has started to converge on this. The NSA hasn't caught up yet.

┌─────────────────────────────────────────────────────────────┐
│  MCP Security Model Comparison                              │
├─────────────────────────────┬───────────────────────────────┤
│  NSA Perimeter Model        │  Pre-Action Authorization     │
├─────────────────────────────┼───────────────────────────────┤
│  Agent (unauthenticated)    │  Agent (identity + scope)     │
│         │                   │         │                     │
│         ▼                   │         ▼                     │
│  MCP Server                 │  Pre-Action Auth Middleware   │
│  (input validation only)    │  verify(agent_id, tool,      │
│         │                   │    params, context) → signed  │
│         ▼                   │    ALLOW / DENY decision      │
│  Full system access         │         │                     │
│  (who is this? unknown)     │         ▼                     │
│                             │  Scoped system access         │
│                             │  (agent whitelisted → OK)     │
└─────────────────────────────┴───────────────────────────────┘

This diagram captures the core difference. The NSA model validates requests and has no agent identity layer. Pre-action authorization adds that layer: a middleware that verifies every tool call against the specific agent's permissions before execution.

Gap 3: no revocation model for rogue agents mid-session

The guidance covers initial access control. Set up your MCP server, configure who can reach it, validate input. But it has nothing to say about what happens when a trusted agent turns rogue in the middle of a session.

Prompt injection can compromise an agent seconds into a conversation. A legitimate agent with access to the CRM can be hijacked into exfiltrating customer records. The MCP server accepted the connection, validated the request format, and the data is gone before any human can notice.

What we need is what fintech has had for decades: a kill switch. The ability to revoke an agent's authorization mid-session, across every MCP server it's connected to, in real time.

The NSA guidance mentions revocation once, in a list of things the MCP spec leaves unspecified: servers rely on bearer tokens "without specifying protocol-level token lifecycle management (i.e., refresh, revocation, and reuse control)." It names the gap and does not fill it. Nothing in the recommendations says how to cut off a compromised agent mid-session. The document assumes that once an agent has access, the security work is done. That's not how the threat model works, and the people actively red-teaming MCP servers know it.

What this means for your deployment

If you run MCP servers in production, here's what I'd do:

Implement the NSA's recommendations right now. They're basic and they work.
Add per-agent identity on top. Every agent instance gets a short-lived credential that carries its authorization scope. The MCP server checks this, and not only the request format.
Build pre-action authorization as a middleware layer. Between your agent and your MCP server. Before a tool executes, verify the agent is permitted to call that specific function with those specific parameters.
Add a revocation mechanism. When an agent is compromised, one command should lock it out of every MCP server it could reach.

The NSA guidance is a start. The real work of making agents safe is understanding that the agent itself is the security boundary. And we're still building that layer.

What this is not

This isn't a critique of the NSA for putting out incomplete work. It's great that they're engaging with MCP security at this level. It signals that agentic AI has crossed a threshold. National security agencies are thinking about your agent stack.

But if you're the person deploying MCP servers on Monday, and you follow only the NSA guidance, you'll have safer servers that still don't prevent the most dangerous class of attack: a compromised agent acting with legitimate credentials.

The O'Reilly AI Agents Stack 2026 edition came out around the same time. It says security is the open problem in the agent stack. The NSA's first guidance is a step forward, and the open problem is still open.

Over to you

I've been building pre-action authorization for AI agents. It's the core of what I work on. So I'll confess these gaps jumped out at me faster than they might for someone deploying MCP for the first time.

What's the single biggest security gap in your current MCP server setup? I'm genuinely curious what's actually hitting production, beyond what the threat models predict.