The NSA doesn’t usually publish design guidance on a protocol that’s barely 18 months old. It did for MCP, naming eight specific risk categories. Two CVEs disclosed before that guidance even shipped already prove the failure modes it warned about. Here’s what they show, what OWASP already has a name for, and what a real internet scan found.
The NSA does not routinely publish design guidance for a protocol that is barely 18 months old. It did exactly that for MCP, the Model Context Protocol, in May 2026, naming eight specific MCP security risk categories rather than issuing a general warning about AI. That alone is worth noticing. What makes it worth acting on is that two CVEs, both disclosed months before the guidance shipped, already show the exact failure modes the NSA named actually happening in production tools developers use every day.
MCP security, in other words, is not a hypothetical concern waiting for its first real incident. It is already a documented one, with a government agency, two independent security research teams, and an open standards body all pointing at the same underlying pattern from different directions.
This piece walks through what the NSA actually flagged about MCP security, the two disclosed vulnerabilities that map directly onto its warnings, what OWASP already calls the underlying pattern, how many MCP servers a recent internet scan found sitting exposed with no authentication, what the protocol’s own creator says about who is responsible for vetting it, and what the NSA’s own MCP security mitigations actually require in practice, not just in principle.
What the NSA actually flagged about MCP security
Anthropic released MCP in November 2024 as a standard way for AI models to connect to external tools and data. By May 2026, the NSA had published a dedicated guidance document titled “Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation,” warning that MCP adoption had outpaced the MCP security safeguards built around it. That gap between adoption speed and MCP security safeguard maturity is the whole story so far, and it is worth sitting with before getting into specifics.
The protocol reverses a familiar trust direction
Most integrations are built so a client asks a server a question and gets an answer back, and the server’s job ends there. MCP flips part of that: servers can also take actions on behalf of a connected client, and the client is expected to trust that the server’s description of what a tool does matches what it actually does, without an independent way to verify that description before acting on it.
That reversal is structural to the protocol itself, not a bug in any one implementation, and it is the root of most MCP security risk described below. A team can write flawless code around MCP and still inherit this risk, because the risk lives in what the protocol assumes about trust, not in how carefully any one integration was built.
Eight risks, named in one document
The NSA’s guidance names eight specific MCP security problems: uncontrolled automated actions, lack of input screening, context poisoning, lack of identity and access controls, data leakage, lack of human approval steps, credential reuse risk, and susceptibility to overload attacks.
Two of those MCP security risks, lack of human approval steps and lack of input screening, map almost exactly onto the two CVEs below, both disclosed roughly a year before the NSA’s document existed. That timing matters for how a security team should read this guidance: it is not a forecast of theoretical MCP security risk, it is a government agency cataloguing failure modes that had already been demonstrated, and naming them so the next one is easier to anticipate.
The first CVE: a remote server took over the client machine
MCP security vulnerabilities do not usually arrive already labeled by a government agency’s threat model. This one did, months in advance.
What JFrog actually found
JFrog Security Research disclosed CVE-2025-6514 on July 9, 2025, and it remains one of the clearest MCP security case studies available: a critical flaw, CVSS 9.6, in mcp-remote, a widely used proxy that lets MCP clients connect to remote servers. When mcp-remote received a maliciously crafted authorization_endpoint URL from an untrusted server, it passed that URL to a system function without sanitizing it first. On Windows, this triggered arbitrary command execution with full parameter control, simply by connecting to a server that turned out not to be trustworthy. Versions 0.0.5 through 0.1.15 were affected; the fix shipped in 0.1.16.
The exact risk this maps to
This is the NSA’s “lack of input screening” MCP security risk, demonstrated in the wild before the guidance existed to name it: data from an external system passed through to something that could execute it, with no check in between. The MCP security lesson here is not that mcp-remote was carelessly built.
It is that the protocol’s basic trust model, treat a connected server’s responses as safe to act on, produces exactly this failure class whenever an implementation skips a validation step, and that a proxy sitting between a client and an untrusted server is itself part of the MCP security surface, not just plumbing. Teams that audit their own MCP servers for security but treat the connecting infrastructure as neutral are auditing half the problem.
The second CVE: trust granted once, silently extended forever
The NSA’s MCP security guidance also warns about missing approval steps. A second CVE shows precisely how an attacker exploits that gap once it exists.
The exact mechanic Check Point disclosed
Check Point Research disclosed CVE-2025-54136, nicknamed MCPoison and now a standard reference point in MCP security writeups, on August 5, 2025, after reporting it to Cursor on July 16. The flaw: once a user approved an MCP server configuration in Cursor’s editor, any later change to that configuration’s command or arguments was trusted automatically, with no re-approval prompt.
An attacker could commit an innocuous, easily approved configuration to a shared repository, wait for a teammate to approve it, then quietly swap in a malicious command that would execute the next time anyone reopened the project. Cursor shipped a fix in version 1.3 on July 29, 2025, now requiring approval for any configuration change, however small, a small but telling MCP security improvement made only after the flaw was found and disclosed.
OWASP already has a name for this pattern
The OWASP Cheat Sheet Series’ MCP security entry calls this exact pattern a rug pull attack: a server alters its tool definitions after approval, converting a previously trusted tool into a malicious one. MCPoison is a rug pull attack against a real, popular development tool, not a theoretical entry on a list.
OWASP’s broader MCP security guidance names nine risk categories in total, including tool shadowing, where a malicious server’s tool description manipulates how an agent interacts with tools from a different, trusted server; the confused deputy problem, where an MCP server executes actions using its own broad privileges rather than the requesting user’s narrower ones; and sandbox escapes, where a local MCP server running with full host access enables file traversal or credential theft.
Each is a distinct way the same underlying trust assumption gets abused, and a serious MCP security review checks a deployment against all nine, not just the one that happened to make headlines.
How many MCP servers are just sitting exposed
Individual CVEs show what can go wrong. A recent internet scan shows how often the conditions for an MCP security failure already exist, unpatched and unmonitored, with nobody watching.
The protocol’s own default is no authentication
Censys published a scan on May 27, 2026, identifying 12,520 internet-accessible MCP services across 8,758 unique IP addresses as of late April that year. The researchers were direct about why so many turned up: the protocol does not require authentication or authorization by default, and every server they found was discoverable without any credential at all.
Censys was careful to note it never attempted to execute anything against these servers; it only enumerated the tools, resources and prompts each one exposed, which was already enough to demonstrate the scale of the exposure. That distinction matters for how to read the number: 12,520 is not a count of confirmed compromises, it is a count of MCP security exposure waiting for someone less careful than Censys to come along.
What internet-accessible actually means in practice
Every one of those 12,520 services is a live illustration of the NSA’s “lack of identity and access controls” risk category, not a lab exercise. An MCP security review that only checks the servers a team deliberately built and documented misses this category entirely, because most of what shows up in a scan like Censys’s was never meant to be reachable from the open internet in the first place.
It got there through a default configuration nobody revisited, a firewall rule scoped too broadly, or a development server someone forgot was still running after the demo ended. None of those are exotic mistakes. They are the same mundane misconfigurations that have exposed databases and admin panels for two decades, now happening to a protocol that also hands the exposed service a description of what actions it is allowed to take.
Even MCP’s creator says the vetting is on you
None of this is Anthropic being caught off guard on MCP security. The company has been explicit from early on about where responsibility sits.
“Does not security-audit or manage any MCP server”
Anthropic’s own Claude Code security documentation states plainly that while Anthropic reviews connectors against its own listing criteria before adding them to its directory, it “does not security-audit or manage any MCP server.” Its guidance to users is to write MCP servers themselves or use ones from providers they already trust, and to treat “allow always” approvals as a decision that should require actual trust in the server, not convenience.
The documentation also acknowledges directly that a server developer can change a tool’s behavior after a user has approved it, the same mechanic MCPoison exploited in the wild a year earlier. Coming from the company that designed the protocol, that is about as clear a statement as MCP security gets: the platform provides the mechanism, not the guarantee.
A malicious server does not need a CVE to cause damage
Unit 42, Palo Alto Networks’ threat research team, published proof-of-concept work on December 5, 2025, demonstrating three distinct attack techniques against a single malicious MCP server connected to a coding copilot: resource theft through hidden prompts, conversation hijacking through persistent prompt injection, and covert tool invocation the user never sees. None of these required a software bug.
They worked because the server was doing exactly what a malicious MCP server is designed to do, and the client trusted it the way MCP expects clients to trust servers, which is itself the central MCP security problem this entire piece keeps circling back to. That is the uncomfortable part of MCP security that a patch cannot fix: a server behaving exactly as MCP allows can still be an attack, and no CVE will ever be filed for a protocol working as designed.
What the NSA’s mitigations actually require
Naming eight risks is the easy half of the NSA’s MCP security guidance. The six mitigations it recommends are more specific, and more work, than a policy statement.
Minimum access, not default access
The guidance calls for granting only the minimum access necessary to each server and separating systems and data by trust level, rather than connecting every tool a team might eventually want to a single client with broad standing permissions. In practice this means treating an MCP server’s requested scope the way a security team would treat an over-broad OAuth request from any other third-party integration: as something to question by default, not approve by default.
This is also where credential reuse risk, one of the NSA’s eight named MCP security categories, tends to show up in practice. A token issued once and never rotated or scoped down remains valid long after the project that requested it has changed shape, and MCP security reviews that check access at connection time but never again miss exactly this drift.
A review process before deployment, not after an incident
The NSA also recommends rigorous review before a new MCP tool is deployed, input screening against defined rules, comprehensive activity logging integrated with existing security monitoring, and processing sensitive data locally where possible instead of routing it through an external service. Every one of those is a process an organization has to build and staff, not a setting it can toggle once.
That is precisely where most teams already stretched across a growing MCP footprint start to fall behind, not because the guidance is unclear, but because nobody has the dedicated time to run it consistently against every server already connected. The same resourcing gap shows up in Fyld’s SBOM and CRA deadlines piece: a real compliance obligation with a fixed date attached tends to get resourced, while an open-ended MCP security review with no external deadline competes for attention against everything else on a roadmap and often loses.
Building the review process is a capacity problem, not just a technical one
None of the six mitigations above are exotic. Minimum-access scoping, pre-deployment review, input screening, logging integrated with existing monitoring: these are established security practices applied to a new protocol.
What is genuinely new is the pace. MCP servers get added the way browser extensions used to, one useful tool at a time, and an MCP security review process that only runs when someone remembers to trigger it will always run behind an integration surface that grows every sprint. Fyld’s own 2026 cybersecurity trends piece covers the same widening gap between how fast AI tooling gets adopted and how slowly the security practice around it tends to mature, of which MCP security is the sharpest current example.
It is worth being direct about scope here: none of this is a compliance sign-off or a promise that a given MCP deployment meets a specific regulatory bar. It is dedicated engineering time applied to an MCP security review process that otherwise competes with everything else on a security team’s plate, which is usually the actual reason it does not happen consistently, rather than any gap in what the team already knows how to do.
The pattern connecting the NSA’s document, both CVEs, and Censys’s scan is the same one Fyld’s own Non-Human Identity piece and Secrets Sprawl piece both describe from different angles: new AI infrastructure keeps inheriting the assumption that something on the other end of a request can be trusted by default.
MCP security specifically just makes that assumption structural to the protocol itself, which is exactly why the NSA felt the need to name it in writing so early in the protocol’s life. Get in touch to talk through what reviewing your own MCP footprint against the NSA’s guidance would actually take.
