TL;DR: On May 20, 2026, the NSA’s Artificial Intelligence Security Center dropped its first protocol-specific guidance for AI agents: A Cybersecurity Information Sheet on the Model Context Protocol. It lands three weeks after the Five Eyes joint paper on agentic AI and roughly a month before the Department of Defense’s deadline for a CMMC-for-AI implementation plan. The timing is no accident. MCP has crossed 10,000 active servers, 97 million monthly SDK downloads, and a steadily worsening list of public exploits (around 200,000 vulnerable instances exposed by OX Security earlier this month alone). The CSI walks through the same threat model security researchers have been shouting about for a year (prompt injection, tool poisoning, confused-deputy OAuth abuse, token passthrough, supply-chain compromise) and tells government contractors and critical-infrastructure operators to treat MCP like privileged access, not a developer convenience. For enterprise teams running agentic systems, this looks less like a new framework than a deadline. The threat model has been public for over a year. The market for tooling has matured. What changed on May 20 is who’s asking the questions, and how much weight their answers carry.

NSA’s MCP Security Guidance: Federal Cyber Policy Catches Up to AI Agents

U.S. cybersecurity policy tends to move in a predictable arc. A technology gets interesting, researchers find holes, incidents pile up, industry argues for self-regulation, and then a signals intelligence agency or CISA puts a name on the risk in a document with a publication number. After that, the conversation changes.

That happened to the Model Context Protocol on May 20, 2026.

The NSA’s Artificial Intelligence Security Center (AISC), the unit Fort Meade stood up in September 2023 to lead the agency’s AI security work, released a Cybersecurity Information Sheet (CSI) titled Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation. It is the first time a U.S. SIGINT agency has issued protocol-specific guidance for AI agent plumbing. Eighteen months ago, MCP didn’t exist outside an Anthropic blog post. Now it has a CSI of its own.

For anyone watching agentic AI adoption move through federal contractors, regulated industries, and large enterprises, that trajectory matters more than the document itself.

What MCP actually is, and why a signals intelligence agency cares

For readers who haven’t been chasing every AI-tooling release: The Model Context Protocol is the open standard Anthropic introduced in November 2024 to give AI assistants a uniform way to call external tools and read external data. Before MCP, every integration between an AI agent and a corporate system meant bespoke glue code. After MCP, any compliant client (Claude, ChatGPT, Cursor, VS Code, Microsoft Copilot, Gemini) can talk to any compliant server (Slack, GitHub, Salesforce, Postgres, your in-house ticketing tool, take your pick). The metaphor that stuck was “USB for AI agents.”

The reason the NSA cares is that MCP doesn’t just let an AI read data. It lets the model invoke tools that execute actions: Write files, send messages, run queries, deploy code, move money. That turns a language model from a stateless text generator into something closer to a shell user with delegated authority. The exposure follows: A prompt-injection payload that steers the model now steers whatever the model was wired up to control.

There is also the protocol’s own design to factor in. MCP was deliberately built flexible. The spec defines message formats and capability negotiation but leaves authentication, authorization, audit, and tenancy almost entirely to implementers. The Anthropic spec itself notes that the protocol “explicitly does not enforce security at the protocol level.” That choice made adoption frictionless. It also meant thousands of MCP servers shipped into production with whatever security model their authors thought up the afternoon they wrote it.

The result, in the NSA’s framing, is an inverted attack surface. Instead of clients pulling data from servers, MCP servers often initiate actions on behalf of clients, which inverts the trust assumptions most existing network and identity tooling was built around.

How MCP got from a blog post to critical infrastructure

By the spring of 2026 the MCP ecosystem looked like this:

• Over 10,000 active public MCP servers, up from roughly 1,200 a year earlier
• About 97 million monthly downloads of the Python and TypeScript SDKs combined
• Nearly 2,000 entries in the official MCP Registry, which launched in September 2025
• Native client support across Claude, ChatGPT, Gemini, Microsoft Copilot, Cursor, VS Code, JetBrains, Windsurf, Zed and most major frameworks
• 78% of enterprise AI teams reporting at least one MCP-backed agent in production, up from 31% a year earlier, per adoption tracking from DigitalApplied
• Governance handed in December 2025 to the Agentic AI Foundation under the Linux Foundation, with Anthropic, OpenAI, and Block as founding members and Google, Microsoft, AWS, Cloudflare, and Bloomberg supporting

That picture isn’t an experiment or a single-vendor protocol anymore. MCP is the default wiring for production AI agents across the industry.

By the time the AISC document hit the wire, the public record on MCP exploits was long and getting longer. Some of the lowlights:

• April 2025, WhatsApp data exfiltration. Invariant Labs demonstrated tool poisoning against a “fact of the day” MCP server that quietly drained chat histories on every invocation.
• mcp-remote command injection, CVE-2025-6514. An RCE affecting roughly 437,000 installations including Cloudflare and Hugging Face environments, documented by SentinelOne.
• April 2026, STDIO transport flaw. The Hacker News reported a design issue in Anthropic’s MCP STDIO transport enabling arbitrary OS command execution across supported SDKs, affecting more than 7,000 publicly accessible servers and 150+ million SDK downloads.
• nginx-ui MCP authentication bypass, CVE-2026-33032. A CVSS 9.8 unauthenticated takeover of nginx servers running the popular nginx-ui management tool, exploited in the wild within days of disclosure. Dark Reading covered it as the first major MCP exploit at internet scale.
• May 2026, OX Security disclosure. Approximately 200,000 vulnerable MCP instances reachable from the internet, spanning IDE plug-ins, internal tooling, and cloud services.

For an industry-data view of the same trend, see our coverage of Wallarm’s Q3 2025 API ThreatStats report on MCP. Broken authentication shows up in 52% of MCP incidents, and MCP-related vulnerabilities jumped 270% quarter over quarter.

That is the backdrop the NSA was working against. By the time the CSI dropped, every category of attack the document warns about had already shown up in production incident reports.

What’s actually in the May 20 CSI

The threat taxonomy in the CSI is not novel. Most of it has been spelled out in research papers since early 2025: Prompt injection, tool poisoning, rug-pull updates, server spoofing and tool shadowing, confused-deputy OAuth flaws, token passthrough, credential aggregation, supply-chain compromise. The MITRE-style vocabulary is already settled.

What’s new is who is publishing it, the formal weight that carries, and the specificity of the recommended controls. Four themes do most of the work in the document.

1. Identity and authorization, done properly

The CSI treats MCP servers as OAuth 2.1 Resource Servers, distinct from the authorization server that issues tokens. That separation matters because it forces a discipline most early MCP deployments skipped: Tokens must be audience-bound, scoped to the specific resource, and validated on every inbound call. Sessions can’t be used as authentication.

The single behavior the AISC most wants stopped is token passthrough, the pattern where an MCP server takes a token a user handed it for one service and reuses it to call downstream APIs on the user’s behalf. The pattern is convenient and widespread, and it’s the textbook setup for a confused-deputy attack. The MCP server becomes a deputy with legitimate credentials, applied to actions the user never sanctioned. The CSI is explicit: Per-client consent, audience-restricted tokens, and explicit token exchange whenever the server needs to call something downstream.

None of that is exotic cryptography. It’s OAuth 2.1 done by the book. The reason it appears in an NSA CSI is that MCP servers in the wild routinely don’t.

2. Servers are untrusted code

The CSI’s posture toward MCP servers is direct: Treat each one as untrusted code with the minimum privilege necessary to do its job. Run them in containers. Cap CPU and memory. Prefer read-only filesystems. Restrict outbound network egress and lock down DNS resolution. Sign and verify packages. Assume that a server can lie about what its tools do and behave differently once the user has clicked “approve.”

That framing is grounded in real incidents. The “rug pull” pattern, where a server quietly updates a tool description after approval, has been demonstrated repeatedly. SentinelOne documented a malicious MCP package that operated undetected for two weeks while exfiltrating email data in September 2025. The May 2026 OX Security disclosure found roughly 200,000 vulnerable MCP instances across IDEs, internal corporate tools, and cloud services.

The implicit argument is that an MCP server’s trust level should be roughly the same as third-party code you let touch production data. Most enterprises wouldn’t dream of running that code without containerization, signing, and runtime isolation. The fact that the same code calls itself an AI tool integration doesn’t change the math.

3. Put a gateway in the path

The architectural recommendation that will reshape the most deployments is the introduction of a policy-enforcing gateway between MCP clients and the servers they talk to. The gateway:

• Verifies cryptographic signatures on server packages before execution
• Maintains an allowlist of tools and rejects anything unknown
• Pins tool descriptions and re-prompts users when descriptions change (defeating rug-pull updates)
• Applies egress policy and redacts secrets in transit
• Emits structured logs for every request and response, with correlation IDs

This is the same architectural move enterprises have made for API traffic and email over the last decade: A chokepoint where policy gets enforced and visibility gets generated. The CSI’s claim is that MCP needs the same treatment, and most current deployments don’t have it.

The market has been moving in that direction already. Cisco AI Defense added an MCP catalog and AI BOM features in February. Cisco’s open-source MCP Scanner shipped specifically because supply-chain risk in the MCP ecosystem outran existing software composition tooling. FastMCP and a handful of other open-source gateways have been picking up adoption. The CSI doesn’t endorse a vendor. It endorses the architectural pattern, and that alone will pull procurement budgets into the category.

4. Humans in the loop, by default, for anything destructive

The CSI is firm that agents should not invoke destructive or high-impact tools without a human checkpoint. The MCP specification itself uses softer language (“SHOULD” rather than “MUST” require human oversight), and a year of incidents shows that “SHOULD” is regularly read as “skip it for the demo.”

The guidance pushes the opposite default. Explicit user consent surfaced in the UI for any tool invocation that writes data, moves money, sends external communication, or executes code. Tool-level allowlists, time-boxed approvals, and audit trails of who approved what and when. The goal is to make an agent’s authority match user intent at the moment of action, not to slow it down.

The threat vocabulary worth carrying around

The CSI puts a federal stamp on a threat taxonomy the security community has been refining since early 2025. Eight terms a CISO or platform lead should be able to define cold.

Prompt injection. Attacker-controlled text (in a document, an email, a webpage, a Jira issue) contains hidden instructions that an agent reads and follows. The April 2025 Invariant Labs WhatsApp demonstration remains the canonical example.

Tool poisoning. Malicious instructions live inside a tool’s metadata, in the description the model reads when deciding whether to call the tool. The user never sees the poisoned text. The agent reads it every time the tool is considered. As one researcher put it, “while a traditional prompt injection requires the attacker to repeatedly deliver malicious content, a poisoned tool description ships inside a package, configuration file, or remote MCP server, and it works on every single invocation, silently, across every session, for every user, until somebody notices.”

Rug pulls. A previously approved tool updates itself to do something new. The agent (and often the user) never re-confirms.

Server spoofing and tool shadowing. A rogue server registers with a name similar to a trusted one. The client picks the wrong one, and credentials end up flowing to the attacker.

Confused deputy. OAuth misconfiguration lets an MCP server act with permissions it shouldn’t have, typically by reusing tokens or skipping per-client consent checks. The pattern the CSI most wants stamped out.

Credential aggregation. One MCP server centralizes OAuth tokens for half a dozen downstream services. Compromising the server compromises everything connected to it.

Token passthrough. The pattern the NSA most wants to see ended. As covered above, it breaks audit trails and turns every downstream API into a confused-deputy target.

Supply-chain compromise. Typosquatting on registry names, malicious packages disguised as legitimate community servers, dependency hijacks. The MCP supply chain looks structurally similar to npm in 2018: Fast growth, weak provenance, expanding blast radius.

Every category above has shown up in publicly documented exploits in the past twelve months. The CSI’s contribution is to give security and compliance teams a vocabulary their auditors will recognize.

How this fits with the Five Eyes paper and CMMC for AI

The MCP CSI didn’t arrive in a vacuum. It is one piece of a regulatory triangle that came together in the last six weeks.

On May 1, 2026, CISA, the NSA, ASD’s ACSC, the Canadian Centre for Cyber Security, NZ NCSC, and UK NCSC jointly published a 30-page paper on careful adoption of agentic AI. It was the first time all five Five Eyes nations had coordinated on a single AI attack surface. The paper sets the high-level doctrine: Agentic AI gets zero trust, defense in depth, least privilege, the same controls as other privileged systems. It avoids picking a specific protocol.

Three weeks later, on May 20, 2026, the same NSA that co-signed the Five Eyes paper published a protocol-specific implementation manual. The pattern is familiar from earlier policy cycles: A generic joint statement followed by a country-specific, implementation-specific deep dive. The CSI doesn’t replace the Five Eyes paper; it operationalizes one corner of it.

Next on the calendar is the Department of Defense’s CMMC-for-AI implementation plan, with a status update due to Congress on June 16, 2026. The FY 2026 NDAA directed the DoD to build an AI security framework that will be folded into the Defense Federal Acquisition Regulation Supplement (DFARS) and the Cybersecurity Maturity Model Certification program. The plan is expected to apply to the entire defense industrial base. Crowell & Moring’s analysis describes it as “CMMC for AI,” a parallel certification track for AI/ML systems handling controlled unclassified information.

Put those three together and the story is: The Five Eyes set the doctrine, the NSA wrote the protocol-specific guide, and the DoD is about to make a version of it mandatory for the contractors that account for a meaningful slice of MCP’s enterprise footprint. If you’re a defense contractor running agents on MCP, the CSI is now the answer key for the audit that’s coming.

Why this lands in May 2026 specifically

A few separate trends collided to make May 2026 the right window for an MCP-specific federal document.

Exposure crossed a line. When OX Security disclosed roughly 200,000 vulnerable MCP instances in early May, it pushed the conversation past “some early adopters made mistakes” and into “this is protocol-level exposure at enterprise scale,” including IDE integrations and cloud services. Federal guidance follows numbers that big.

MCP also became multi-vendor critical infrastructure. The December 2025 handoff to the Agentic AI Foundation removed the “this is just an Anthropic protocol” excuse for not regulating it, in the same way the IETF turns specifications like BGP into critical infrastructure. Critical-infrastructure protocols get government guidance.

And the Defense Industrial Base started shipping agents in earnest. The AISC’s 2025 paper on agentic AI was generic; the May 2026 paper is implementation-specific. That progression maps to the maturity curve of actual deployments inside defense contractors and federal civilian agencies, who needed concrete guidance, not principles.

The CSI is the federal cyber apparatus catching up to a category of risk that hit critical scale.

What enterprise teams should actually do this quarter

The CSI is written for designers and architects. For the security and platform teams already running agents, here’s the practical translation.

Start with an inventory. Every server inside your environment, every external server your agents call, every developer who registered something to a public registry, every IDE configuration with MCP enabled. The count will be higher than your security team thinks. The closest analogy is the Log4j discovery exercise in late 2021, a class of dependency that nobody mapped because nobody had to.

The most leveraged single fix this quarter is to kill token passthrough. If any of your MCP servers receive a user token from a client and reuse it to call upstream services, that’s the change that closes the most exposure. Implement OAuth 2.1 token exchange so every downstream call uses a token minted for that specific audience, with scopes that match the action.

Next, stand up a gateway. A policy-enforcing layer between MCP clients and servers is the architectural move the CSI keeps circling back to. The market has moved fast here: Cisco AI Defense added MCP catalog and AI BOM features earlier this year, FastMCP and other open-source projects have gateway components, and the major cloud providers have managed offerings. The specific tool matters less than the pattern: A chokepoint where signatures get verified, tools get allowlisted, descriptions get pinned, secrets get redacted, and traffic gets logged.

Pin versions and hash tool descriptions. Rug pulls die when every approved server is pinned and every tool description is hashed at approval time. If anything changes, re-prompt. This is supply-chain hygiene applied to tool definitions.

Move human-in-the-loop checks into the UI. Policy that lives only in a PDF gets ignored. Policy enforced by the user interface gets followed. Any agent action with material impact (sending email, writing files, modifying production data, executing code) should surface a clear consent prompt with enough context for the user to make a real decision. The MCP spec already supports this, and most production deployments under-use it.

Wire logs into the SIEM you already have. The JSON-RPC traffic MCP runs over doesn’t slot neatly into legacy log pipelines, but that’s a tooling problem to solve, not an excuse to skip logging. Every tool invocation should produce a structured log line: Who, what, when, which tool, which scopes, which downstream services. Correlation IDs should let you trace a single agent action across host, client, server, and downstream API.

Treat MCP credentials as identity infrastructure. This was Jake Williams’s point in an IANS Research piece earlier this year: MCP is generating non-human identities at a velocity existing IAM can’t match. The teams handling this well are the ones treating MCP credentials with the same rigor as service-account credentials. The same boring discipline that protects everything else.

None of those moves is exotic. The CSI’s contribution is to make them defensible in a budget meeting.

What the CSI doesn’t fix

Some gaps the document can’t close on its own.

Multi-tenancy is still unresolved at the protocol level. If you run MCP servers serving more than one organization, the spec gives you no tenant isolation model. That’s custom engineering. The Agentic AI Foundation’s 2026 roadmap flags enterprise readiness as a priority, but tenant isolation is not yet on the formal list of pillars.

Standardized audit formats are missing. Every gateway and every implementer logs differently. There is no protocol-level requirement for what a usable audit record looks like. SIEM integration is custom work, project by project.

The skills gap is wide. MCP became enterprise infrastructure faster than the security industry could train people to defend it. Most security teams have nobody on staff who’s spent serious time with the protocol internals. The CSI gives those teams a defensible baseline; it does not solve the staffing problem.

Configuration portability is unsolved. Moving an MCP deployment between environments, or between developer workstations, currently means hand-syncing configuration. That’s a fragility issue more than a security one, but it makes consistent policy enforcement harder.

Where this goes next

A few predictions.

The NSA CSI is the first MCP-specific document from a major government agency. It will not be the last. Expect CISA, NIST, and ENISA equivalents inside six months, and at least one sector-specific overlay (FedRAMP, FFIEC, HHS) before the end of the year. Once one SIGINT agency publishes guidance like this, the rest of the policy ecosystem tends to follow.

Compliance is about to become a meaningful constraint on MCP deployments inside regulated industries. SOC 2 auditors will start asking about MCP server inventories. ISO 27001 reviews will want to see tool allowlists. PCI auditors will want to know whether agents have any path to cardholder data. The CSI gives auditors a vocabulary they did not previously have for MCP-shaped risk.

The market for MCP-specific security tooling, which barely existed a year ago, is going to consolidate fast. Gateways, scanners, registries, runtime sandboxes: There are already a dozen open-source projects and as many startups in each category. Expect a wave of acquisitions inside the next year.

And the protocol itself will harden. The 2026 MCP roadmap lists transport scalability, agent communication, governance maturation, and enterprise readiness as priorities, with SSO-integrated authentication explicitly named. The CSI gives the foundation public-sector air cover to push those changes faster, even where individual vendors would prefer to keep things flexible.

The takeaway

The NSA’s MCP guidance reads, more than anything, like a notice that the grace period is over.

For two years, the AI agent industry got to run on a protocol that traded security for adoption velocity and called the trade-off a feature. Much of the time, the trade-off paid off. Adoption happened, useful things got built, and the protocol became a standard.

Then the bill came due. Researchers found the gaps, attackers used them, incidents accumulated, governance moved to a foundation, and the federal cyber apparatus, on its usual lag, started writing things down with publication numbers attached.

Teams that read the CSI as a checklist for “what we ship to government customers” are reading it too narrowly. The same threat model applies to every commercial MCP deployment. The same controls work for a fintech connecting agents to customer data as for a defense contractor connecting agents to classified-adjacent systems. The only difference is whether you implement them before something embarrassing happens or after.

The next two quarters will sort the AI platform teams that treated MCP as a developer-experience win from the ones that treated it as a security architecture problem. The NSA’s May 20 release made the first framing harder to keep.

If you run agents in production, the practical move now is to audit where MCP lives in your stack, decide who’s accountable for it, and make sure you can answer the questions the CSI is about to put on every auditor’s checklist.

Further reading

• NSA: Security Design Considerations for AI-Driven Automation Leveraging MCP
• CISA: Five Eyes guide to secure adoption of agentic AI
• Anthropic: Introducing the Model Context Protocol (November 2024)
• Anthropic: Donating MCP to the Agentic AI Foundation
• Crowell & Moring: CMMC for AI? Defense policy law imposes AI security framework on contractors
• Model Context Protocol: Security Best Practices
• SentinelOne: Model Context Protocol Security: Complete Guide
• WorkOS: Everything your team needs to know about MCP in 2026
• IANS Research: AI agents and the identity security crisis