MCP became the default and the NSA published its threat model

The NSA's May advisory says MCP's adoption outran its security model. The scan data says the gap is in how teams deploy it, and the July specification revision does not close it.

Finley Jones, Co-founder, CCO/CMO, Taskpool International Ltd. @finjonesceo Published 17 September 2026.

Status as of 17 September 2026: scan percentages below come from vendor research with incompatible methodologies and are flagged where they conflict. Next review December 2026.

Six things were deleted from the Model Context Protocol on 28 July 2026. Sessions, the initialize handshake, the GET stream endpoint, SSE resumability, the ping method, the log-level method. The same release shipped a formal deprecation policy promising at least twelve months between deprecating a feature and removing it, and the registry that policy created still says, correctly, that nothing has been removed under it yet.

Both of those are true at once, which tells you something about how to read the rest.

Two months earlier, on 20 May 2026, the NSA's Artificial Intelligence Security Center published a Cybersecurity Information Sheet on MCP. It is public, unsensational, and its central finding is one most engineers would concede without argument: MCP's proliferation has outpaced the development of its security model, and the protocol shipped with a flexible and underspecified design. Read it against the deployment data and the diagnosis sharpens. MCP deliberately mandates almost nothing, and it has been installed at enormous scale by teams who assumed it did.

How widely is MCP already installed?

Lead maintainer David Soria Parra's December 2025 ecosystem update put MCP at over 97 million monthly SDK downloads, 10,000 active servers, and first-class client support across ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot and Visual Studio Code. An independent pull of the official Registry API on 24 May 2026 returned 9,652 latest server records across 28,959 server and version records. Those are the freshest counts I can source. If you have seen a 2026 SDK download figure published by Anthropic, send it.

Wiz's State of AI in the Cloud 2026 found MCP servers in 80% of cloud environments and self-hosted AI agents in 57% of organisations, with 5% of those environments running at least one MCP server reachable directly from the internet. Wiz then contradicted its own headline number in July. Its 28 July blog puts exposure at about one in six of those environments, and reports unauthenticated servers run by Fortune 500 companies exposing employee PII, internal business records, write and delete operations on production systems, and in some cases cloud credentials. The gap between 5% and 17% is methodology rather than a three-month spike, and the second number is the one I would plan against. At either rate an attacker no longer has to establish whether a target runs MCP.

The NSA sheet names AutoGen Studio, Harvey AI, Agentverse and Copilot as products shipping it, across business, finance, legal and software development.

What the document actually names

The sheet's novel risks are three properties rather than three bugs. Dynamic tool invocation, where agents can autonomously call new tools at runtime. Implicit trust relationships, where one agent's output is assumed valid by another without explicit verification. Context sharing, where long-lived or overlapping context windows leak, blend or misalign across tasks. The first of those is the property that makes agents useful, written down by someone who has to defend it.

Buried in a footnote under Access control is the one that generalises worst. Unverified task propagation: tasks passing between MCP servers or agentic components without validation of their origin, scope or intent, leading to overreach, leakage of sensitive context, or unintentional activation of unrelated downstream tools. A trust decision made at the first hop is inherited silently by every hop after it, and nothing in the protocol carries the provenance forward.

The remedies are mostly unglamorous. Implementation rigour, proper coding practices, clearer protocol specifications, better validation tooling. One is not. The sheet tells implementers to extend MCP with cryptographic signatures inside the JSON payload, carrying expiration timestamps and replay-protection metadata. That is an instruction to build a message-integrity layer the protocol does not have, issued to a population that has not switched on the authorisation the protocol already offers. I do not expect it to be widely adopted.

The incidents are not hypothetical

CVE-2025-49596, the MCP Inspector remote code execution flaw, carried a CVSS score of 9.4, was reported by Oligo Security and Tenable, and was fixed in version 0.14.1. Recorded Future found 560 exposed Inspector instances on Shodan, mostly in the US and China, though not all were necessarily on a vulnerable version.

The bigger blast radius was elsewhere. CVE-2025-6514 in mcp-remote, CVSS 9.6, found by JFrog and published on 9 July 2025, reached more than 437,000 downloads, and JFrog described it as the first real-world case of full remote code execution on a client operating system from connecting to an untrusted remote MCP server. CVE-2025-54136, which Check Point called MCPoison, scored 7.2 and worked by swapping a Cursor MCP config the user had already approved. Backslash Security documented a localhost binding class it named NeighborJack, affecting hundreds of servers reachable by anyone on the same local network. Coffee shop wifi, essentially.

August 2025's Nx compromise is the mature version of this. Attackers exploited a flawed GitHub Actions workflow to publish malicious Nx versions to npm on 26 August 2025 with a post-install script, and the payload weaponised the AI command-line agents already sitting on developer machines, claude, gemini and q, prompting them to inventory sensitive files and exfiltrate the results to public repositories. Wiz observed over a thousand valid GitHub tokens, dozens of valid cloud credentials and npm tokens, and roughly twenty thousand additional files leaked, with 2,180 accounts and 7,200 repositories exposed across three phases. The workflow that made it possible was contributed by pull request on 21 August and is estimated to have been generated by Claude Code. The agent tooling was not the target. It was the mechanism, and nobody has explained why the malicious PR went after an outdated branch still carrying the reverted workflow rather than the branch where it was introduced.

OWASP now carries an MCP threat taxonomy alongside its Top 10 for Agentic Applications for 2026.

Where the deployment numbers point

Every figure below comes from a different vendor scanning a different population, so treat the spread as the finding rather than any single percentage.

Endor Labs, across 2,614 implementations, found 82% using file operations prone to path traversal. Astrix Research analysed more than 5,200 open-source servers: 88% require credentials, 53% rely on long-lived static secrets, and 8.5% use OAuth. Equixly put command injection at 43% of tested servers, BlueRock Security put SSRF at 36.7% of more than 7,000, and Enkrypt AI found critical vulnerabilities in 33% of 1,000 scanned. A separate scan of more than 500 servers found 38% with no authentication at all. AgentAuditKit's scan of 2,303 public MCP configs found 52.3% declaring a remote server with no authentication, and none using RFC 9728 discovery.

The specification is not the problem here. The March 2025 revision mandated OAuth 2.1 with PKCE for HTTP transports, and the June 2025 revision made Resource Indicators required for authorisation servers, so a token minted for server A cannot be replayed against server B. Those controls have existed for over a year. The deployed population largely does not use them, and most installs do not arrive through the official registry with its signing and vendor verification. They arrive from community registries, mirrors and arbitrary GitHub URLs.

88% of organisations reported confirmed or suspected AI agent security incidents in the past year. Gartner's Aaron Lord projects that 15% of enterprise generative AI applications will suffer at least one major security incident annually by 2029, up from 3% in 2025, tying the rise to MCP-driven attack surface. Both figures are aggregator-reported and I have not seen the underlying instruments.

Why identity tooling does not catch this

The authority is ambient. MCP grants the model runtime ambient authority across multi-hop trust chains that perimeter and identity controls do not cover. Your identity system knows who made a request, but not which MCP server it transited, what tools that server exposed, or whether the tool description the model read at session start matched what you reviewed at deployment. A credential reaches the runtime, the runtime picks the tools, and the tools inherit whatever the credential permits.

Token passthrough is the common concrete failure. Forwarding an upstream token to a downstream call, rather than performing OAuth 2.0 token exchange under RFC 8693 to mint a credential scoped to the target audience, lets a token issued for one audience reach systems it was never scoped for. Well specified, widely ignored.

One dispute remains open, and it is not a deployment failure. On 15 April 2026 OX Security disclosed a systemic vulnerability in the STDIO transport across Anthropic's official SDKs in Python, TypeScript, Java and Rust, where user-controlled configuration values pass to shell execution without sanitisation, and the command runs even when the target process fails to start. More than 150 million package downloads, roughly 7,000 publicly reachable servers, an estimated 200,000 vulnerable deployments and at least 14 assigned CVEs. One of them, CVE-2026-30615 in Windsurf, needed no user interaction at all: attacker-controlled HTML modified the local MCP configuration and registered a malicious STDIO server on its own. Anthropic confirmed the behaviour was intentional during coordinated disclosure in January 2026, holds that STDIO execution is a secure default when developers restrict what can appear in the command field, and updated SECURITY.md nine days after first contact without changing the SDK. OX's counter-position is that a command allowlist or manifest-only execution in the official SDKs would propagate protection to every downstream project in a single change.

That argument is why the MCP Dev Summit in Seoul on 13 and 14 August 2026 turned into a confrontation rather than a routine industry meeting, held at the Grand InterContinental Seoul Parnas alongside Open Source Summit Korea. Forkast's pre-summit framing cited more than 21,000 exposed internet-facing server instances and nearly 92% of audited production servers without basic OAuth, both higher than anything else I found, from an outlet writing a curtain-raiser.

What July changed, and the part that will annoy you

The 2026-07-28 revision is the largest since launch: a stateless core that scales on ordinary HTTP infrastructure, extensions covering server-rendered UIs through MCP Apps and long-running work through Tasks, authorisation aligned more closely with deployed OAuth and OpenID Connect practice, and the deprecation policy. Roots, Sampling, Logging and Dynamic Client Registration carry the twelve-month clock and become eligible for removal no earlier than a revision released on or after 28 July 2027, while the legacy HTTP+SSE transport follows its own published schedule.

If you are writing a multi-year control plan, that lifecycle is the difference between a protocol you can plan against and one you cannot. It is also where the convention gets broken on the way in. The release that established the twelve-month window used a clean break to delete six features outright rather than deprecating them first, which is defensible engineering and means the policy's first advertised guarantee is one the release itself did not have to honour. A client speaking the new revision cannot talk to a server speaking the old one, and the reverse fails too, so supporting both is the only migration path. The mix-up-attack defence the security analyses prioritise, SEP-2468, is client-side work, so in most enterprises the team that would implement it is not the team running the servers.

What the revision does not do is mandate the controls. An MCP server is only as secure as the team that deployed it. That is a design choice rather than an oversight, and it puts the burden precisely where the scan data says nobody is carrying it.

The defence of mandating nothing, and where it fails

MCP spread this fast because it was unopinionated. A protocol requiring OAuth 2.1, per-tool scoping and signed server provenance from day one would have been a better security artefact, and it would probably have lost to something easier. The frictionlessness that produced 97 million monthly SDK downloads is the same property that produced an 8.5% OAuth rate.

The usual move here is to reach for HTTP shipping without TLS, SMTP without authentication, npm without signing, and call it a law of protocol adoption. That analogy is doing more work than it can carry. HTTP had no TLS to switch on. MCP has had mandatory OAuth 2.1 for HTTP transports since March 2025 and required Resource Indicators since June 2025, and the deployed population still does not use them. The failure is not that the standard arrived late. It arrived, and nobody installed it.

How to secure an MCP deployment

Everything below exists today and is mostly unimplemented. Each item costs something, so the costs are stated.

Use token exchange, not passthrough. OAuth 2.1 with PKCE for user-facing flows, RFC 8693 exchange to mint a credential scoped to the target audience on each downstream call. Cost: an authorisation server that supports exchange, and added latency on every hop.

Scope every token to one server and one tool. Deny-by-default per-tool scopes. The blast radius of a compromised server is defined entirely by this, and so is the volume of access requests your platform team now fields. The opposing case is real: teams that tried this in 2025 wrote a lot of application-layer plumbing to make it work, and some of it is now redundant against the July revision.

Validate Resource Indicators on both sides. The client sets resource, the authorisation server binds the aud claim, and both reject cross-audience tokens. Cost: clients that do not set it stop working, and some of those clients will be ones you bought rather than built.

Pin server provenance. Install from the official registry with signing and vendor verification, or vendor the source and review it yourself. An arbitrary GitHub URL in a config file is a supply chain decision. Cost: you fall behind upstream, and npx -y pkg@latest in a config is a rug pull waiting to happen either way.

Allowlist STDIO commands yourself. Anthropic's position is that sanitisation between configuration and the spawn call belongs to the developer, so do it: a fixed allowlist of executables, no interpolation of configuration values into the command field, and no path where attacker-influenced HTML or a poisoned repo file can write your MCP config. Cost: you are carrying a control the SDK maintainers have declined to carry, in every language you ship.

Treat all tool output as untrusted input. Prompt injection through tool responses is not solvable at the model layer, so the mitigation is authorisation: an injected instruction should not be able to reach anything the token does not already permit. The NSA sheet's version of this is to log and inspect the output of each tool before it is passed to the next.

Restrict egress at the network layer. A filtering outbound proxy or enterprise DLP, with named resource URLs and access methods for external connections. This is the control that would have contained the Hugging Face incident, and it applies here for the same reason.

Inventory the servers you are running. With four in five cloud environments containing them, the first question is where MCP already is, not how to secure it. Every scanner in the NSA's list is free.

What changes now

The NSA sheet, the OWASP lists and the July revision landed within four months of each other, so the correction is underway at the standards layer and the deployed population is where the work remains. What none of those documents settle is the STDIO question, and that one is not waiting on adoption. Anthropic has said it will not change the SDK. OX has said a one-line default would fix it everywhere. Until that resolves, every organisation running local MCP servers is writing its own version of a control that could exist once, and most of them will write it badly or not at all.

The figure in this post I trust least is the 88% incident rate. It is aggregator-reported, I could not find the survey instrument, and it is the kind of number that gets repeated until it becomes furniture. If you have the primary source, or a better one, I want it. The argument about what happens when the agent hits a wall it cannot get past is in Duration, not difficulty, is what breaks agents.

FAQ

Does MCP require OAuth? Not universally. Authorisation is optional in the specification, and where it is implemented for HTTP transports the March 2025 revision mandates OAuth 2.1 with PKCE, with Resource Indicators required of authorisation servers since June 2025. Local STDIO servers are outside that requirement entirely, which is part of why the measured OAuth rate across public servers sits at 8.5%.

Did the July 2026 specification fix MCP's security problems? No. It aligned authorisation more closely with deployed OAuth and OpenID Connect practice and added a formal deprecation lifecycle, but it mandates no controls. It also removed sessions, the initialize handshake, the GET stream endpoint and stream resumability, so old and new implementations cannot interoperate and migration requires supporting both.

What did the NSA actually recommend? Choose maintained projects, define trust boundaries between components, validate parameters against schemas and execution context, sandbox tool execution with seccomp, AppArmor, SELinux or AppContainers, sign and verify messages with expiry and replay protection, treat every tool output as untrusted input to the next stage, log all invocations into your SIEM, track MCP CVEs formally, and scan your own network for unauthenticated or unauthorised servers.

Is it safe to install an MCP server from a GitHub URL? Treat it as an unsigned dependency with shell access. The April 2026 STDIO disclosure covered roughly 7,000 publicly reachable servers built on the official SDKs, and the September 2025 appearance of the first confirmed malicious MCP package means the supply chain threat is no longer theoretical. Install from the official registry with signing and vendor verification, or vendor and review the source.