The NSA published formal security guidance on MCP in May 2026, flagging trust boundary failures, unauthenticated endpoints, and prompt injection risks that conventional security tooling cannot detect — and a spec overhaul arriving July 28 won't fix what's already deployed.
When the NSA publishes formal security guidance on a developer protocol that's less than two years old, that is not a routine advisory. It is a signal that something has gone badly wrong at scale.
In May 2026, the NSA's AI Security Center released "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation" — a document that names specific vulnerability classes, flags systemic architectural problems, and warns that MCP adoption has significantly outpaced its security model. The publication, hosted on defense.gov, is aimed at enterprise security teams. But the problems it describes affect every developer who has connected an AI agent to an external tool or database using MCP.
This matters now because enterprises are not experimenting with MCP anymore. They are running it in production.
The Model Context Protocol was designed to solve a specific problem: how do you give an AI agent access to external tools — databases, APIs, file systems, code repositories — in a consistent, interoperable way? Anthropic published the initial specification in late 2024, and adoption accelerated faster than anyone anticipated.
By mid-2026, MCP had effectively become the de facto standard for AI agent tool integration. Frameworks like LangGraph, AutoGen, and CrewAI all support it natively. Salesforce, Jira, and Confluence integrations are being built on top of it. Cursor, Claude Code, and similar agentic developer environments depend on it.
The problem is that MCP was designed for flexibility, not security. And when something becomes the default plumbing before its security model is mature, the attack surface scales with adoption.
The NSA guidance identifies several structural failures — not edge cases, but design-default vulnerabilities that exist in standard implementations.
The inverted client-server model. Traditional network security assumes a pattern: clients request, servers respond. Your firewall rules, your SIEM alerts, your DLP policies — all of these are built around that assumption. MCP inverts it. MCP servers can query and execute actions for clients. The NSA's guidance notes this creates attack paths that are "not well-traced" by existing security infrastructure. Your security stack is looking for the wrong traffic direction.
Trust boundary failures in multi-server architectures. When an agent traverses multiple MCP servers — which is the norm in production multi-agent systems — privilege isolation between those servers is often absent or inadequate. A compromise in one MCP server can enable lateral movement to others, because the agent carries context and credentials across server boundaries without explicit re-authorization at each hop.
Serialization and tool injection. Serialized tool responses from MCP servers can carry malicious payloads. More critically, attackers can poison tool descriptions themselves — embedding instructions that manipulate the agent's reasoning and cause it to execute unauthorized commands. The agent doesn't experience this as an attack. It experiences it as a task.
Authentication gaps at industrial scale. Research cited across multiple security publications indicates that approximately 40% of internet-accessible MCP services lack any form of authentication. A significant portion of public MCP servers — estimates range from 30% to 82% depending on the study — carried exploitable flaws. These are not niche deployments. Many are developer tools and enterprise integrations.
Two documented CVEs illustrate the range of the problem.
CVE-2025-49596 affects MCP-Inspector, a widely used developer tool for testing MCP servers. The vulnerability allows remote code execution through unvalidated tool parameters — the kind of flaw that exists when security is treated as someone else's problem during development.
CVE-2026-35394 affects Mobile MCP, which enables mobile automation via AI agents. Again: remote code execution via insecure transport. The pattern is consistent — early MCP implementations used STDIO transports with unvalidated inputs, and the results are being documented in the CVE database.
Supply chain attacks have also emerged. The decentralized nature of MCP server registries allowed malicious or typosquatted servers to be distributed, enabling attackers to gain footholds in developer environments through a dependency they never audited.
This is the part most enterprise security teams are not yet grasping.
Standard firewalls cannot detect prompt injection. A firewall inspects packet headers and port numbers. A prompt injection attack — where malicious instructions are embedded in a support ticket, a repository issue, or website metadata that the agent is asked to process — travels through legitimate HTTPS traffic, passes through your firewall without triggering a single alert, and tells the agent to exfiltrate credentials or modify production records.
The NSA's guidance frames this directly: prompt injection is no longer a chatbot issue. It is an execution issue. When an agent has access to databases, code repositories, payment systems, or internal communications, a successful prompt injection bypasses the model entirely. It executes actions on production infrastructure using the agent's existing permissions.
Your SIEM is looking for anomalous network patterns. Your DLP is scanning for known data patterns leaving the network. Neither will catch an agent that has been told — by a malicious string in a customer email — to copy your API keys to an attacker-controlled endpoint.
Akamai's security research, published in 2026, identified additional attack surfaces specific to the upcoming stateless MCP architecture. Even after the July 28 spec overhaul fixes legacy issues, new attack classes emerge: workflow hijacking through manipulation of client-held state objects, privilege escalation by exploiting the _meta object to bypass role enforcement, and asynchronous denial-of-service through misuse of new task extensions. Fixing the protocol does not fix what's already deployed.
On July 28, 2026, a new MCP specification is scheduled for release. It introduces stateless architecture at the protocol layer, mandates OAuth 2.1 for authentication, and removes features like unsolicited server-initiated prompts that previously enabled session hijacking and unauthorized tool execution.
This is a meaningful improvement. The removal of unauthenticated defaults alone addresses a large class of the documented vulnerabilities. OAuth 2.1 enforcement brings MCP authentication to a standard that enterprise security teams can work with.
But the July 28 spec has two limitations that matter immediately.
First, existing deployments are not automatically updated. The specification deprecates legacy implementations with a 12-month window. That means the current, vulnerable MCP ecosystem continues operating at scale until at least mid-2027. Organizations planning to wait for the new spec before addressing security are making an error. The attack surface that exists today will not disappear on July 29.
Second, the spec fixes the protocol layer — it does not fix the execution layer. An agent with a valid OAuth 2.1 token that has been manipulated via prompt injection will still execute unauthorized commands. Authentication solves the unauthenticated-endpoint problem. It does not solve the prompt-injection-as-malware problem.
OWASP, CoSAI (Coalition for Secure AI), Cisco, and Checkmarx have all published guidance on securing MCP-based agent infrastructure. The convergence across these independent sources suggests a working defensive posture.
Authentication is table stakes. Any MCP server binding to 0.0.0.0 — all network interfaces — is publicly accessible until it isn't. Restrict to 127.0.0.1 or internal segments. Apply mandatory authentication to every endpoint. This sounds obvious and it is often ignored.
Treat every MCP server as a third-party dependency. The principle of least privilege applies here the same way it does in IAM. A read-only agent should not hold credentials that permit write-level API calls. Audit what permissions each MCP server actually requires, then enforce that ceiling explicitly.
Deploy execution-layer inspection. Standard firewalls cannot inspect prompt content for injection. Agent Runtime Protection tools — SDK-based wrappers or dynamic code rewrite systems — inspect every LLM call and MCP tool invocation before execution. Cisco has been advancing tooling in this space. This is the category to watch.
Log tool invocations, not just prompts. Because prompt injection exploits logic rather than syntax, monitoring what the agent is actually doing — the specific tool calls it makes — is more effective than scanning the prompt text itself. Every MCP tool invocation should be logged in your SIEM, with alerting on unexpected tool call patterns.
Threat model for cross-agent poisoning. In multi-agent systems, a compromised tool output in one agent's processing loop can propagate to downstream agents, bypassing traditional security controls entirely. This is what Checkmarx calls "cross-agent context poisoning." Security models that treat each agent as an isolated unit are incomplete.
The following represents the author's analysis and should not be taken as financial or investment advice.
The MCP security situation is a predictable outcome of how developer tooling gets adopted. A protocol solves a real problem, gets traction, becomes the default, and then the security model — which was never the priority — has to catch up to a deployment base that is already mission-critical.
[OPINION] The NSA publishing formal guidance on a developer protocol is a clear marker of how seriously MCP has been integrated into systems that matter. Security advisories from the NSA are not published about toys. They are published about infrastructure.
The most concerning element is not the CVEs. CVEs are fixable. The most concerning element is the gap between what conventional security tooling can detect and what MCP-based prompt injection actually looks like. Enterprise security teams are genuinely underprepared for an attack class where the "malware" is a sentence in a customer email that tells a production agent what to do next.
The July 28 spec is progress. Mandatory OAuth 2.1 and stateless architecture are real improvements. But the 12-month deprecation window means that organizations treating the spec update as a security event are missing the point. The spec update is a protocol event. The security work — execution-layer inspection, privilege isolation, cross-agent threat modeling — is separate, ongoing, and cannot wait for a deprecation timeline.
Any team running MCP-based agents in production today needs a posture review. Not after July 28. Now.
The NSA did not publish guidance on MCP because the vulnerabilities are theoretical. They published it because the vulnerabilities are real, documented with CVEs, and exist in production systems that are already integrated into enterprise infrastructure.
The July 28 spec overhaul will improve the protocol. It will not retroactively secure what is already deployed, and it will not solve the execution-layer attack class that conventional security tooling cannot detect. Those problems require deliberate defensive architecture: execution-layer inspection, strict least-privilege enforcement, cross-agent threat modeling, and tool invocation logging.
MCP is not going away. The agent ecosystem depends on it. The question is whether the security layer catches up before the attack surface is fully exploited — and right now, it is behind.
_meta privilege escalation, async DoS — https://www.akamai.com