MCP Has No Auth Requirements. The NSA Just Published a Guidance Doc.

The Model Context Protocol wasn’t designed to be the nervous system of enterprise AI. It happened that way anyway. And now the NSA has weighed in.

On May 20, 2026, the NSA’s Artificial Intelligence Security Center published a Cybersecurity Information Sheet titled “Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation.” It’s a measured document — not a ban, not a panic advisory. But read it carefully and the message is clear: MCP’s rapid adoption has significantly outpaced the development of its security model, and most enterprise deployments are carrying gaps they haven’t fully characterised.

What MCP Actually Does (And Why Security Teams Should Care)

MCP is the application-layer protocol that lets LLMs interact with tools, APIs, databases, and external systems in a standardised way. Think of it as the connective tissue in agentic architectures: an agent requests a tool, MCP routes that request to the right server, the server executes, the result comes back. Claude, GPT-4o, and a growing number of enterprise AI deployments all speak some version of it.

The appeal is obvious. Standardised tool integration means you can build one MCP server for your internal knowledge base, your ticketing system, or your code execution environment, and any compliant agent can use it. Ecosystem benefits accumulate fast. By early 2026, thousands of MCP servers existed for everything from Slack and GitHub to database query engines and network scanners.

Security teams largely weren’t in the room when those servers got built.

Security property	REST API baseline	MCP (protocol spec)
Authentication	Required (common convention)	Optional
Authorisation / RBAC	Implementation responsibility	Not defined
Session-to-identity binding	Established patterns	Not defined
Transport security	HTTPS enforced by convention	No mandate
Tool manifest signing	N/A	Not defined

The NSA CSI spends considerable space on this table’s implications. Optional authentication isn’t a theoretical concern. It means production MCP servers exist right now, accessible from agent runtimes, with no credential check on who’s asking.

The Trust Boundary Problem

Here’s the wrinkle the NSA highlights that isn’t obvious until you’ve actually deployed agents at scale. An MCP server is not just a passive tool executor. It’s a trust boundary — or should be. When an agent invokes a tool through MCP, it’s accepting the result as authoritative input that may influence subsequent reasoning and actions. Poison the input, and you influence the agent’s downstream behaviour without ever touching the model itself.

This is the tool poisoning scenario. An attacker who can substitute or modify a tool’s response — whether through a compromised registry, a man-in-the-middle on an unencrypted MCP connection, or simply a malicious server that mimics a legitimate one’s name — can cause the agent to exfiltrate data, escalate permissions, or take destructive actions it would not otherwise take.

Dynamic discovery makes this worse. Many MCP deployments use discovery mechanisms where agents enumerate available tools at runtime rather than working from a fixed manifest. Without signed provenance anchored in something the agent can actually verify, “I discovered a tool called query-hr-database” is a claim the agent can’t validate. It just… trusts it. Because the protocol doesn’t require anything else.

The NSA notes that this is architecturally analogous to the early web services era, where service discovery was frequently unauthenticated and the attack surface that created is still being cleaned up twenty years later. We’re repeating that pattern in compressed timescale.

What the NSA Actually Recommends

The guidance is practical. Four things get the most emphasis:

Least-privilege tokens per action. Every tool invocation should carry a scoped credential that permits exactly what that action requires, not a session-level credential that grants everything the agent is allowed to do. If the tool needs read access to a database table, the token proves read access to that table. Not write. Not other tables. This is harder to implement than it sounds when you’re retrofitting it onto an existing deployment, but the NSA is explicit: broad-scope credentials in MCP tool calls are a known exploitation path.

Signed provenance for dynamic discovery. If your agent is discovering MCP servers or tools at runtime, those registries should require signed manifests with verification chains anchored in hardware roots of trust. Pinning is the minimum viable version of this: hardcode a list of permitted tool sources and reject anything not on it. Imperfect, but much better than open discovery.

Treat the registry like a hardened API gateway. Rate limits, anomaly detection, strict schema validation on request and response, full audit logging of every tool invocation. The NSA frames this as applying existing enterprise security patterns — the same controls you’d put on a sensitive internal API — to MCP infrastructure that often has none of them.

Segment agent networks. This is the one practitioners already know but rarely implement before a security incident motivates them. Agents with MCP tool access should not have network paths to sensitive data stores that aren’t mediated by the tool itself. If your agent shouldn’t be able to query your production customer database directly, it shouldn’t have a route there. Lateral movement from a compromised agent runtime is a realistic scenario, not a theoretical one.

The Harder Conversation

The NSA guidance is good. If you follow it, your MCP deployment is materially safer. But there’s a harder conversation embedded in it that the document doesn’t quite surface.

Most of the gaps the NSA identifies aren’t fixable by practitioners alone. They’re gaps in the protocol spec — things that require the MCP working group to define authentication requirements, standardise session identity binding, and build manifest signing into the core protocol rather than treating security as someone else’s problem. Until that work is done, every enterprise MCP deployment is applying compensating controls around a protocol that lacks defence in depth by design.

That’s not a reason to wait. Compensating controls work. Deploy them. But if you’re evaluating MCP for high-sensitivity agentic use cases — systems where tool misuse could mean data exfiltration, privilege escalation, or production-impacting actions — the honest risk assessment right now is that you’re buying into an ecosystem where the security model hasn’t caught up to the deployment scale.

The NSA published this guidance because governments and critical infrastructure operators are already running MCP. So are most large enterprises. The ship has sailed. The question is whether the security model sails with it.

Read the full CSI at the NSA’s website. Then audit your MCP servers. Start with which ones don’t require authentication.

References

• NSA Artificial Intelligence Security Center, “Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation,” Cybersecurity Information Sheet, May 20, 2026. Press release | Full PDF
• AI Weekly, “NSA warns MCP poses enterprise security risks,” May 2026.