NSA AISC publishes MCP security design guidance for production AI

What is this?

On May 20, 2026, the National Security Agency’s Artificial Intelligence Security Center (AISC) released a 15-page Cybersecurity Information Sheet (CSI) titled Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation (reference U/OO/6030316-26 / PP-26-1834). The accompanying press release frames the document as what NSA considers the minimum baseline organizations should apply before standing up an MCP deployment in a production or high-stakes environment.

The CSI is not a vulnerability advisory and does not introduce a new attack. It is the first formal U.S. government posture document focused specifically on MCP — the application-level protocol popularized by Anthropic in November 2024 and now embedded in products like AutoGen Studio, Harvey AI, Agentverse and Microsoft Copilot. NSA’s framing is that “MCP’s rapid proliferation has outpaced the development of its security model,” and that adopters should treat current implementations the way the industry once treated early web protocols: powerful, useful, and dangerous to deploy without defense-in-depth.

How it works

The CSI is structured around three blocks: a list of design and implementation weakness classes, a set of real-world incidents that show each class is more than theoretical, and a recommendation set framed for operators rather than spec authors.

Eight classes of weakness identified by NSA.

#  Class                                What goes wrong
-- ------------------------------------ -------------------------------------------------
1  Access control                       Session-to-identity binding is optional; many
                                        servers omit authentication; no native RBAC,
                                        no CRUD-level enforcement
2  Insecure context/data serialization  Serialized payloads may carry executable code
                                        or embedded model calls; permissive
                                        deserialization echoes OWASP A08:2017
3  Poor approval workflows              Capability or data-access changes on an
                                        already-trusted MCP server often bypass user
                                        re-consent
4  Token or session security            OAuth-style bearer tokens, but lifecycle
                                        management (refresh, revocation, replay) is
                                        not mandated; idempotency left to JSON-RPC
5  Misconfigurations & poor             A "weather" server gets repurposed against
   implementation                       sensitive data; no task or data isolation
                                        between reused interfaces
6  Inconsistent behaviors               Different implementations interpret the same
                                        context differently; non-deterministic outcomes
                                        become an attacker primitive
7  Poor or missing audit logs           Spec offers basic guidance only; many servers
                                        log nothing, or only operational metadata
8  DoS and fatigue-based techniques     Prompt storms, malformed inputs, recursive
                                        tasks; "lethargy" attacks via overly complex
                                        but legitimate requests

Five real-world incidents NSA cites as illustrations — all already publicly disclosed by the original researchers, all linked from the CSI bibliography:

• Tool parameter injection in open MCP agents, where unsanitized parameters reached execution environments through malformed messages — HiddenLayer, 2025.
• Tool invocation path confusion where orchestrators resolve names from public registries or local modules, enabling actor-controlled code via naming collisions — Zhao et al. arXiv 2509.06572.
• Unrestricted GitHub MCP access, where blanket repo permissions let a compromised tool exfiltrate private repository content into public ones — Invariant Labs, 2025.
• WhatsApp MCP exfiltration, where a malicious server installed alongside a trusted one used benign-then-malicious tool descriptions to dump message history — Invariant Labs, 2025.
• CVE-2025-49596 in MCP-Inspector, an RCE via unverified inputs fixed in version 0.14.1 — Oligo, 2025.

No exploit code is reproduced in the CSI or here. The novel framing — and the reason this document matters — is NSA’s observation that MCP inverts a familiar client/server pattern: instead of clients pulling data from servers, MCP often expects servers to query and execute actions for the connected client. That inversion shifts the trust boundary in a direction most existing detection and DLP stacks were not designed for.

Why it matters

Three shifts make this CSI worth the read time even if you have followed every MCP incident this year.

First, the authority of the source. Recent MCP coverage has come from security vendors, academic groups, and our own MCP backend vulnerabilities pattern and stdio-transport-by-design RCE write-ups. NSA AISC sitting in this conversation moves MCP security from “interesting research area” to “subject of federal cybersecurity guidance.” For organizations bound by NIST AI RMF, the CSI is now part of the documentation set an auditor can ask for.

Second, the framing of MCP risk as systemic, not endpoint-level. The CSI is direct: “These are not isolated problems that can be patched at the interface or endpoint level.” Securing MCP, in NSA’s view, requires treating the agentic environment as a continuum where assumptions in the protocol, the agent, the tools, the data classification scheme and the audit pipeline all have to line up. That language matters because it pushes back on the natural tendency to “patch the server” or “add a guardrail” and call it done.

Third, alignment with the broader allied effort. The CSI references the Australian Signals Directorate’s Careful Adoption of Agentic AI Services (covered in our CISA Five Eyes guidance piece) and the OASIS Coalition for Secure AI’s work on MCP scope control. Five Eyes posture on agentic AI is converging, and MCP is now an explicit subject within that convergence.

Defenses

NSA’s nine recommendations are operational; below is a translation focused on what a defender can do this week. None of this requires NSA-tier access — every control listed is implementable with existing tooling.

1. Inventory and pick supported servers. Many popular MCP servers are now archived per the MCP servers-archived list. Build a registry of every MCP server in production, map it to its upstream repo, and flag anything unmaintained for replacement or removal. For internal projects, enroll them in the MCP Registry preview so discovery does not run blind.

2. Design for trust boundaries. Agents, plugins, models and end users live in different trust zones. Align tools with data classification: public-only tools for public data; sensitive tools explicitly gated and segregated. Prefer local MCP servers when private data is in scope, and put a filtering egress proxy (Squid, tinyproxy) or DLP in front of any server that can talk to the public internet.

3. Validate parameters in context, not just shape. Schema validation is necessary but not sufficient. NSA’s example — a math-interpreter agent where a context parameter triggers unintended file I/O — captures the issue: validate inputs against the execution environment, not only the type system. Block parameter forwarding when the source is ambiguous.

4. Sandbox every tool execution. Treat every MCP-invoked tool as potentially high-risk. Use OS-level isolation (AppContainer on Windows, seccomp / AppArmor / SELinux on Linux). Apply least privilege to the agent process itself: if a server does not need file-system or internal-network reach, deny those paths at runtime.

5. Sign MCP messages; do not assume the wire. TLS protects transport, but the protocol does not enforce integrity. Add cryptographic signatures inside the JSON payload, with expiration timestamps and replay-protection metadata. OWASP ASVS V7 (Session Management) maps directly here.

6. Treat every tool output as untrusted input to the next step. Output filtering should run between each tool in a multi-component pipeline, with checks for length, disallowed keywords, rate limits, and detection of indirect prompt injection or toolchain pivot attempts. Compromised tool descriptors and hidden instructions in outputs are how tool poisoning and toxic flows propagate across chained agents.

7. Log everything, route it to the SIEM. Capture exact parameters, identities, and cryptographic hashes of outputs for every tool and model invocation. Without this, incident response becomes archeology. The CSI is explicit that audit gaps are one of the most common implementation failures.

8. Track MCP CVEs as a separate workstream. New MCP-specific vulnerabilities are landing in the CVE feed monthly. Subscribe to the relevant feeds, maintain a versioned inventory of every deployed MCP agent and tool, and treat MCP patches with the same SLA as authentication or crypto libraries.

9. Scan your network for unknown MCP servers. Use scanners like MCP Scanner, Ramparts, CyberMCP or Proximity to detect unauthenticated servers, deployments running unapproved versions, and instances with open inbound or outbound traffic paths. MCP servers can change ports dynamically; differential scans are the right cadence.

A useful tenth, implied by the CSI’s emphasis on continual approval and consent: re-approve when capability changes. A trusted server that quietly adds a new tool description or scope after install is the WhatsApp incident pattern. Treat capability deltas the way you treat code deltas.

Status

Item	Reference	Date	Notes
NSA AISC press release	NSA	2026-05-20	Announces release of the CSI
CSI document (PDF)	NSA	2026-05-20	U/OO/6030316-26, 15 pages
Executive Gov coverage	Executive Gov	2026-05-21	Summarizes serialization, trust-boundary, agent-misuse risks
Intelligence Community News coverage	ICN	2026-05-22	Mirrors press release
Companion guidance	Australian Signals Directorate / CISA	2026	Careful Adoption of Agentic AI Services (referenced in CSI)
OASIS COSAI WS4	CoSAI	2026	MCP scope-control and agent-misuse work referenced in CSI
MCP spec version cited	modelcontextprotocol.io	2025-11-25	Auth, lifecycle, tools subsections

The right framing for this CSI is not “NSA found a flaw in MCP” — there is no zero-day in the document. It is “the U.S. government’s AI security center now treats MCP as critical infrastructure to be governed, with a published baseline that defenders, auditors and acquisition teams can point to.” If MCP is in your stack, this document is now a load-bearing reference; if MCP is on your roadmap, it is the cheapest, fastest read available before you commit.