The MCP Security Crisis: What the NSA's May 2026 Guidance Reveals About Tool-Calling Risk

On May 20, 2026, the NSA's Artificial Intelligence Security Center published a 17-page Cybersecurity Information Sheet on the security of the Model Context Protocol. That alone would be notable. But the timing tells the real story: the guidance landed one month after researchers disclosed an architectural flaw affecting an estimated 200,000 MCP server instances across more than 150 million package downloads, and one day before the protocol's biggest specification rewrite was locked as a release candidate. Three seismic events in roughly 90 days. If you are building on MCP, integrating MCP servers into your product, or evaluating agentic AI infrastructure for procurement, the window between "early adopter advantage" and "unpatched liability" has closed faster than anyone expected.

Key Takeaways

• The NSA formally classified MCP's rapid adoption as having outpaced its security model, comparing it to early web protocols shipped with flexible, underspecified designs.
• The flaw disclosed by OX Security in April 2026 is architectural, not a bug. Anthropic confirmed the behavior is by design and declined to modify the protocol, explicitly shifting sanitization responsibility to downstream developers.
• Researchers poisoned 9 of 11 MCP registries with a test payload and confirmed command execution on 6 live production platforms, producing at least 10 CVEs rated high or critical.
• The upcoming 2026-07-28 MCP specification removes protocol-level sessions entirely, shifting to a stateless model. This eliminates some historical attack vectors but creates new ones that depend entirely on developer implementation.
• Any architecture decision you made before this 90-day window (April disclosure, May NSA guidance, July spec rewrite) likely needs revisiting now.

What did the NSA actually say about MCP?

The NSA's core assessment is blunt. The official press release frames MCP's proliferation as having outpaced the development of its security model. The comparison they reach for is early web protocols: flexible, underspecified, shipped for adoption speed rather than adversarial resilience. The document, identified as U/OO/6030316-26 (PP-26-1834) Version 1.0, runs approximately 17 pages and addresses MCP specifically as an infrastructure-layer concern, not a theoretical one.

That framing matters. The NSA did not issue this as forward-looking research. They issued it as a Cybersecurity Information Sheet, the same format they use for active, operationally relevant threats. The document catalogs concrete risk categories: uncontrolled automated actions where AI systems can independently decide to invoke new tools, lack of input screening that allows hidden commands to pass through undetected, context poisoning, absence of identity and access controls, data leakage across connected services, and missing human approval steps before actions are taken.

Among the top recommendations: per-message cryptographic signing. The NSA recommends signed JSON-RPC payloads with expiration and replay-protection metadata aligned to OWASP ASVS V7. The reason is straightforward. The MCP specification today relies only on TLS at the transport layer and does not bind requests to time and context. Transport encryption protects the pipe. It does nothing to verify that the message inside the pipe is the same message that was originally sent, or that it was sent recently, or that it was sent by the entity claiming to have sent it.

If that distinction sounds pedantic, consider what MCP actually does. It gives an AI agent the ability to call tools: read files, send emails, execute code, query databases. A replayed or tampered tool-call message is not an abstract concern. It is a concrete path to remote code execution.

What is the architectural flaw that OX Security disclosed?

In April 2026, OX Security published research identifying a systemic remote code execution vulnerability at the core of the MCP protocol. The key word is "systemic." This is not a buffer overflow in one library or a misconfiguration in one deployment. OX explicitly framed it as an architectural design decision baked into the official MCP SDKs across every supported programming language: Python, TypeScript, Java, Rust. Any developer building on the MCP foundation unknowingly inherits this exposure.

The scope is large. The supply chain spans more than 150 million downloads, roughly 7,000 publicly accessible servers, and up to 200,000 vulnerable instances. The STDIO transport mechanism, which is how most local MCP servers communicate with clients, does not sanitize inputs at the protocol level. An attacker who can influence the content flowing through an MCP tool description or response can inject commands that execute on the host system.

OX demonstrated this was not theoretical. They successfully poisoned nine out of eleven MCP registries with a test payload and confirmed command execution on six live production platforms with paying customers. The research produced at least 10 CVEs rated high or critical.

Why did Anthropic decline to fix it?

This is the part that shifts the conversation from vulnerability disclosure to governance. Anthropic confirmed the behavior is by design and declined to modify the protocol. Their position: the STDIO execution model represents a secure default, and sanitization is the developer's responsibility.

Read that again. The protocol vendor's official stance is that a protocol-level flaw affecting 200,000 instances is expected behavior, and that every downstream developer is individually responsible for not getting exploited by it.

This is, as far as we can tell, the first major case where an AI infrastructure vendor has formally shifted security liability onto downstream developers by architectural declaration rather than by accident. It is not a case of "we missed this, we'll patch it." It is a case of "we see it, we intend it, you handle it."

For vendor-risk teams, procurement officers, and anyone signing an MCP integration into a production environment, this reframing has real consequences. You are not adopting a protocol with a known bug that will be fixed. You are adopting a protocol whose maintainer has stated, on the record, that the attack surface you are worried about is yours to manage. The liability boundary has been drawn explicitly, in writing.

How did the industry respond to the disclosure?

The Cloud Security Alliance independently confirmed OX's findings in a separate research note and recommended that organizations treat MCP-connected infrastructure as an active, unpatched threat. Not "a risk to monitor." An active, unpatched threat.

Microsoft's Defender team published research in late June 2026 showing that poisoned MCP tool descriptions can make agents collect invoices and leak company data through routine, approved tool calls. The attack does not require the agent to do anything unusual. It exploits the fact that tool descriptions themselves are untrusted input, and agents treat them as authoritative. Microsoft described MCP as the fastest-growing part of the agentic AI supply chain.

Registry integrity is also degrading. UpGuard's tracking found that for every official MCP server, up to 15 lookalikes exist in registries. If you have installed an MCP server from a public registry in the last six months, the probability that you evaluated a spoofed or poisoned listing at some point during your search is not negligible.

What does the upcoming MCP spec rewrite change?

The 2026-07-28 release candidate, locked on May 21, 2026, is the largest MCP revision since the protocol launched. The headline change: it removes protocol-level sessions entirely, including the Mcp-Session-Id header from the Streamable HTTP transport. MCP becomes a stateless protocol.

This eliminates some real historical attack vectors. Session hijacking, weak session authentication, and session fixation all become structurally impossible when sessions do not exist. That is a genuine improvement.

But the rewrite also introduces new capabilities (application UIs, long-running async tasks) that create new attack surface. Akamai's Maxim Zavodchik noted that the expanded attack surface now depends heavily on how developers implement the new spec, because security boundaries previously enforced by the protocol are now delegated to server operators.

Notice the pattern. The original protocol shipped sanitization responsibility to developers. The new spec ships session-security responsibility to server operators. The direction of liability transfer is consistent: downstream, away from the protocol, toward whoever is closest to the user.

The new spec brings new security challenges that security teams need to model before July 28, not after. If your organization made MCP architecture decisions before this 90-day window (April disclosure, May NSA guidance, May spec lock), those decisions were made against a protocol surface that no longer exists in the same form.

What are the NSA's specific recommendations?

The NSA guidance is prescriptive enough to be useful. Beyond per-message cryptographic signing, the document covers several categories worth summarizing.

Tool allowlisting and explicit approval. The NSA recommends that AI systems should not be able to independently discover and invoke new tools. Tool access should be explicitly allowlisted, and human approval should be required before actions are executed. This is a direct response to the "uncontrolled automated actions" risk category: the scenario where an agent, through a poisoned tool description or context injection, decides on its own to call a tool it was never intended to use.

Input validation at every boundary. The guidance emphasizes that input screening must happen at the protocol layer, not only at the application layer. Given that Anthropic has formally declined to implement protocol-level sanitization, this recommendation implicitly acknowledges a gap between what the NSA advises and what the protocol provides.

Data leakage controls. MCP servers often bridge multiple services (a database here, an email client there, a file system over there). The NSA flags the risk of data flowing laterally between connected services through the agent, with the agent acting as an unintentional exfiltration channel. Their recommendation: treat each connected service as a separate trust boundary with independent access controls.

Audit and logging. Every tool call, every parameter, every response should be logged in a tamper-evident format. The current MCP specification provides no standard mechanism for this. It is, again, left to the developer.

How does OWASP's new standard fit into this picture?

OWASP shipped the AI Security Verification Standard 1.0 on June 24, 2026, containing 514 testable requirements across 14 chapters, including chapters specifically addressing MCP server authentication. This is the first verification standard designed to give organizations a concrete checklist for evaluating whether their AI agent infrastructure meets a minimum security bar.

The timing is not coincidental. OWASP ASVS V7 (referenced in the NSA's signing recommendation) provides the cryptographic verification framework. The AI Security Verification Standard layers on top with requirements specific to tool-calling, context integrity, and agent authorization. Together, they form the closest thing the industry has to a compliance baseline for MCP deployments.

If you are in a regulated industry, or if you anticipate being audited on your AI infrastructure within the next 12 months, these two documents are your starting points.

What does "secure by default" actually mean for tool-calling infrastructure?

The phrase gets used loosely. Here is what it means concretely in the context of MCP and tool-calling.

A protocol is secure by default when a developer who does nothing special, who writes no custom sanitization, who adds no extra middleware, still ends up with a deployment that does not permit remote code execution via untrusted input. The MCP STDIO transport, as designed and as its maintainer has confirmed, does not meet this bar. A developer who follows the official SDK documentation and does nothing additional is vulnerable. That is what "insecure by default" means in practice.

Secure by default also means that new tools cannot be invoked without explicit authorization. That tool descriptions are treated as untrusted input. That responses are validated before being passed back to the agent. That actions with side effects (sending an email, deleting a file, executing a query) require a confirmation step that cannot be bypassed by prompt injection.

We build Selina with this principle at the core. Tool calls are explicitly allowlisted. Actions are bounded automatically. We do not ship infrastructure where the absence of developer diligence results in an exploitable deployment. This is a deliberate architectural choice, and it is the opposite of the choice the MCP specification has made.

To be clear about what we do and do not claim: Selina's memory is encrypted at rest, but memory is NOT end-to-end encrypted. A slice of each request reaches a frontier provider at inference. Files and transfers via SelinaSEND are zero-knowledge encrypted. Memory is not. We state this because honest limits are part of the product, not an afterthought. Non-content operational metadata is kept for a short retention window, not zero. The account is protected. Content is encrypted.

We route through a stack of frontier models, routed per task. We do not name them. We do not expose tool-calling surfaces to untrusted input in the way MCP's STDIO transport does. We treat every external integration point as a separate trust boundary. These are structural decisions, not policies layered on after the fact.

What should you do right now if you have MCP in production?

Audit your MCP server inventory. If you do not have a complete list of every MCP server instance running in your environment, including which registries they were pulled from, start there. Given the 15:1 ratio of lookalike servers to official servers tracked by UpGuard, provenance verification is not optional.

Treat your MCP-connected infrastructure as an active threat surface. This is the Cloud Security Alliance's recommendation, and it is the right posture. Do not wait for the July 28 spec to finalize before acting. The current protocol is the one running in your environment today.

Implement input sanitization at every MCP boundary. The protocol will not do it for you. The protocol's maintainer has stated this explicitly. If you are passing unsanitized input through STDIO transport, you have an exploitable deployment.

Require human approval for tool calls with side effects. The NSA guidance is clear on this. Automated tool invocation without a confirmation step is the single largest risk category they identified.

Plan for the spec rewrite. The July 28 release changes the session model, the transport model, and the authentication model simultaneously. Any integration code you have written against the current spec will need review. Do not treat this as a minor version bump. It is a structural change to how MCP operates.

Evaluate whether you need MCP at all. This is the question that does not get asked often enough. MCP solves a real problem (standardized tool-calling for AI agents), but the security cost of the current implementation is high, the liability is explicitly downstream, and the spec is in active flux. For some use cases, a direct API integration with explicit authorization and auditing at every step may be simpler, more secure, and more auditable than an MCP-mediated connection.

What does this mean for the broader agentic AI ecosystem?

The 90-day sequence (OX disclosure in April, NSA guidance on May 20, spec RC locked on May 21) is itself a data point. It tells you that the adoption curve for agentic AI infrastructure is compressing the normal cycle of disclosure, guidance, and remediation into a timeline that most organizations are not equipped to handle. Standards bodies, national security agencies, and protocol maintainers are all reacting to the same underlying reality: tool-calling AI agents are being deployed into production faster than the security models around them can mature.

The MCP situation is not unique. It is the first visible example of a pattern that will repeat. Any protocol that gives AI agents the ability to take actions in the real world (read data, write data, send messages, execute code) will face the same tension between adoption speed and security maturity. The question is whether the defaults protect you or expose you.

We think the answer should be baked into the architecture, not delegated to the developer. That is how we build. We are honest that it is harder, slower, and more constrained. But "constrained" is the right word for infrastructure that can read your files and send your emails.

If you want to see what a privacy-first approach to AI memory and tool integration looks like in practice: start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io