The NSA Just Confirmed Enterprise Deployments are Outpacing Their Own Security

In May 2026, the NSA published its first formal cybersecurity guidance on MCP (model context protocol), and it's worth reading carefully. The document formalizes what practitioners in AI agent deployments have been observing for the past year: MCP security enterprise deployments are highly uneven, and that unevenness is structural. The advisory's core finding is that MCP's rapid adoption has outpaced the security discipline needed to deploy it well, and that gap is exploitable.

In this article, we'll explore what the NSA's advisory says, translate its findings into practical terms for enterprise IT and security teams, and explain what a secure-by-design MCP deployment looks like in practice.

What the NSA said about MCP

The NSA's Artificial Intelligence Security Center (AISC) published this Cybersecurity Information Sheet (May 2026, U/OO/6030316-26) as the first formal US government guidance targeting MCP specifically. A CSI is an actionable advisory—not a framework or compliance mandate—designed to give practitioners enough operational specificity to act immediately. The fact that a national security agency's AI-focused center issued one for MCP reflects how quickly the protocol has moved from developer experiment to enterprise infrastructure, and the pace of that movement is precisely what concerns the advisory.

The document's central finding is that MCP's proliferation has outpaced its security model. NSA explicitly compares this pattern to early web protocols, which were adopted at scale before their security implications were understood. The advisory identifies eight risk categories:

1. Access control gaps

2. Insecure serialization

3. Poor approval workflows

4. Token and session security weaknesses

5. Misconfigurations from rapid deployment

6. Inconsistent behaviors between components

7. Poor or missing audit logs

8. Denial-of-service and fatigue-based techniques

Taken together, these categories describe a protocol being deployed into production environments with security assumptions the protocol itself doesn't guarantee.

For context: Model Context Protocol (MCP) is an application-level protocol that enables AI agents to discover and invoke external tools, query data sources, and execute actions across external systems through a standardized messaging format. It has become the de facto interface between AI reasoning environments and live enterprise data. The NSA advisory is, in effect, the first formal acknowledgment that this interface carries significant security weight, and that weight is not being consistently managed.

The access control problem at the heart of MCP

The most consequential finding in the advisory is also the most structurally important: associating a session to an identity is not defined by the MCP protocol itself. Authentication is left to implementors, and many implementations omit it entirely. The gap exists at the protocol level, and each organization must consciously decide to address it.

In practice, this means MCP components can be configured to access or process enterprise data without any required access control at all. There is currently no protocol-level support for exchanging role-based access control (RBAC) permissions at session instantiation, so organizations that want identity-scoped access must build that layer themselves. The compounding risk is significant: multiple MCP servers can be exposed to messages or information shared freely from the MCP client, increasing both the likelihood of data leakage and the potential propagation of unverified task instructions across tools.

The Center for Internet Security's MCP Companion Guide (April 2026) applied CIS Controls v8.1 to MCP environments and explicitly noted that MCP expands the identity, access control, logging, and application security surfaces by formalizing how AI systems discover and invoke privileged capabilities. By adding new endpoints to secure, MCP formalizes a discovery and invocation layer that didn't previously exist. Security teams that approach MCP as more APIs to lock down are likely to underestimate the governance surface they're managing. Access control in MCP requires deliberate architecture decisions; it won't emerge from default settings.

Real-world exploits the NSA documented

The advisory is notable for grounding its risk categories in documented incidents rather than theoretical attack models, which gives enterprise teams something concrete to calibrate against.

Tool parameter injection. Open source MCP agents exposed sensitive server data after unsanitized parameters, passed via malformed messages, were executed without contextual validation. The absence of input validation at the tool execution boundary allowed malicious actors to run arbitrary commands through legitimate interfaces. This is a well-understood vulnerability class, but one that reliably resurfaces when new protocol layers are adopted quickly without security review.

Tool invocation path confusion. MCP orchestrators that automatically resolve tool names from public registries or local module directories can be tricked into loading attacker-controlled code via naming collisions. When resolution is automatic and trust is implicit, an attacker who controls a name in the resolution path controls execution. Recent security research demonstrates that MCP clients often lack the ability to specify strict resolution policies, making tool name collisions a documented attack vector.

Cross-server data exfiltration via coercion. The WhatsApp MCP exploitation case the advisory documents involved a malicious MCP server coercing an MCP client into exposing message data from a trusted server. The attack used a two-stage approach—advertising benign behavior at install time, then switching to malicious instructions on second use—that made detection particularly difficult. This pattern is especially relevant to enterprises running multi-server deployments, where trust decisions made at onboarding persist across the lifetime of the deployment.

Unrestricted repository access via GitHub MCP tools. The GitHub MCP server grants blanket access for MCP tools to act on a user's behalf, resulting in unrestricted read and write access across all private and public repositories rather than permissions scoped to specific repos or operations. The advisory documents how this lack of granular authorization enabled compromised tools to read sensitive content from private repositories and publish it to public ones without the user's explicit awareness. The pattern is directly applicable to any enterprise using developer tooling that integrates MCP with source control or file systems.

Output poisoning for downstream automation. MCP agents have produced outputs that downstream agents or systems may be interpreted as executable instructions rather than passive content, enabling cascading prompt injection across chained pipelines. The advisory describes hidden instructions embedded in tool outputs that influence how subsequent agents interpret and act on earlier results, pushing risk further down multi-agent workflows where one agent's output becomes another's input. Recent research cited in the advisory characterizes this as systemic rather than isolated: compromised descriptors, tool outputs, or shared context can subvert intended operation across many agent pipelines simultaneously.

CVE-2025-49596 (MCP Inspector remote code execution, fixed in v0.14.1) illustrates the same underlying pattern: common vulnerability classes reappear wherever security hygiene is absent.

What the NSA recommends enterprises do

The advisory frames its recommendations as baseline controls, not aspirational guidance. Given that a US national security agency has now published them, these controls are likely to appear on enterprise security questionnaires and vendor assessment frameworks in the near term.

The NSA's recommendations, translated for practitioner use:

• Use only actively maintained MCP server projects. Establish a formal process for monitoring MCP-related CVEs and vendor security advisories as part of your standard security operations.

• Define explicit trust boundaries between MCP components. Treat each component as a different trust zone. Don't assume components within the same deployment share a trust posture.

• Validate all tool parameters against well-defined schemas. Not just input types, but execution context and environment. Unsanitized parameters are the most documented attack surface in the advisory.

• Sandbox tool execution using OS-level frameworks like AppArmor, SELinux, seccomp, or AppContainers. Least-privilege execution is not optional for tools that can invoke privileged capabilities.

• Sign and verify MCP messages with cryptographic signatures in the JSON payload.

• Filter all tool output as untrusted input to the next pipeline stage. Trust shouldn't be inherited across tool calls.

• Instrument comprehensive audit logging tied into existing SIEM systems, with session identity attached to every logged invocation.

• Scan regularly for unauthorized or unauthenticated MCP server deployments within your environment.

Most of these controls can't be reliably achieved through DIY MCP server implementations without significant ongoing security investment. Each one represents an architecture decision that needs to be made, implemented, and maintained as the protocol and threat landscape evolve.

Why managed MCP platforms change the calculus

The NSA advisory describes what a secure MCP deployment looks like. It doesn't describe how to build one. That's left to the organizations doing the deploying. For teams building on top of open source or self-hosted MCP servers, each of the controls listed above represents an independent engineering problem: authentication infrastructure, RBAC systems, audit log pipelines, sandboxing configurations, parameter validation schemas, and token lifecycle management all need to be built, integrated, and kept current. That's a recurring operational burden, and the variance in how different teams handle it is exactly what the advisory is documenting as a systemic risk.

This is the governance gap the advisory has formally identified. Organizations deploying AI agents to live business data need an MCP layer that treats security as an architectural property, not an implementation task. CData Connect AI provides authenticated, policy-controlled access to hundreds of enterprise data sources through a managed MCP platform built for this kind of production deployment. The controls the NSA flags as typically absent (RBAC, audit logging tied to session identity, parameter scoping, and token lifecycle management) are architectural features of Connect AI, not configurations organizations layer on after the fact.

The broader industry context reinforces why centralized governance is gaining traction over point solutions. A 2026 survey found that only 24% of organizations have full visibility into which AI agents are communicating with each other, and more than half of all agents run without security oversight or logging. The architectural risk class the NSA identified is the same one illustrated by hosted MCP gateway incidents (like the Smithery path traversal case) in practice: when MCP infrastructure is managed at the platform level, the exposure surface for that class of incident is fundamentally different from what organizations face maintaining their own servers.

Questions to ask before deploying MCP in production

Before deploying MCP in a production environment that touches live enterprise data, the NSA advisory's risk categories map directly to questions worth answering with specificity, not intent.

• Is authentication required (not optional) for every MCP server connection in the deployment?

• Does the implementation enforce RBAC at the tool level, not just at the session level? Session-level authentication without tool-level authorization leaves meaningful gaps.

• Are all tool invocations logged with parameters and identity, and are those logs integrated into existing SIEM infrastructure?

• Are MCP servers sandboxed and operating under least-privilege access, with explicit OS-level controls in place?

• Is there a formal process for monitoring MCP-related CVEs and vendor security advisories?

• Has a network scan been run to identify unauthorized or unauthenticated MCP server deployments within your environment?

Any "no" on this list corresponds to a risk category the NSA has documented as exploitable. The incidents behind each of these questions have already occurred in production environments.

Frequently asked questions

Connect to enterprise data sources with governed MCP access

CData Connect AI gives AI agents authenticated, policy-controlled access to hundreds of enterprise data sources through a managed MCP platform built for production deployments. If the NSA advisory has prompted a review of your MCP security posture, Connect AI provides the access controls, audit trails, and governance infrastructure the advisory recommends without requiring you to build them from scratch. Start a free trial or explore the documentation.