The NSA Published an MCP Security Playbook. A Field Guide to PP-26-1834's Nine Requirements.
On May 20, 2026 the NSA released a Cybersecurity Information Sheet naming nine specific security controls for production MCP deployments, with a September 30 federal-contractor deadline. This is a plain-language field guide to what each requirement asks for and what it means for the way you actually build.
On May 20, 2026, the National Security Agency published a Cybersecurity Information Sheet titled “Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation” — document U/OO/6030316-26, reference PP-26-1834, Version 1.0. It is fifteen pages, and it is the first time a US defense or intelligence agency has named MCP-specific security controls in a public document.
That matters for two reasons. The first is institutional weight: the NSA is the sixth major body — after NIST, the CIS, OWASP, CoSAI, and the Five Eyes alliance — to publish MCP security guidance, but it is the one with the most direct procurement leverage. The second is the deadline. The guidance comes with a federal-contractor compliance expectation of September 30, 2026. For contractors deploying MCP-connected AI systems, that is roughly four months to demonstrate they have addressed the nine named requirements.
This is a field guide to those nine requirements: what each one is asking for, why it is there, and what it implies for the way you build an MCP deployment. The NSA’s own framing is worth keeping in mind throughout — that MCP’s “rapid adoption has outpaced its security model,” which is “flexible and underspecified, with security left as an afterthought for implementers.” The nine controls are the agency’s attempt to specify the afterthought.
The Nine Requirements, in Plain Language
The nine controls fall into four natural groups: what enters and leaves the deployment (filtering), what gets recorded (logging), how execution is contained (isolation), and how messages are trusted (integrity). Reading them this way makes the design intent clearer than the flat list does.
Filtering — controlling what crosses the boundary
Filtering outgoing proxy with DLP and content inspection. The NSA wants a proxy in front of external MCP connections that can inspect content and apply data-loss-prevention rules. This is the agency naming, in effect, “you need a gateway” — a single chokepoint where outbound MCP traffic can be examined rather than letting each agent connect to arbitrary servers directly.
Content controls. URL-length caps, injection-pattern detection, rate limiting, and tool-level policy enforcement (allow/deny lists). These are the concrete knobs the filtering proxy is expected to expose.
Indirect prompt-injection detection. The proxy should scan tool output — not just input — for indirect prompt injection and tool-chain pivots, where a tool’s response is crafted to hijack the agent that consumes it. This is one of the harder controls to implement well, because it requires semantic inspection of responses before they reach the model.
Logging — recording what happened
Output logging. Log MCP tool output before it is passed onward to the agent. The intent is that the exact bytes a tool returned are preserved, not just the fact that a call occurred.
Tool inventory pinning. Detect tool-name collision and definition drift. A registered server’s tools should be fingerprinted, and a change to a previously approved definition should be detectable — directly addressing the rug-pull class of attack (the Cursor “MCPoison” CVE is the textbook example).
Detailed audit logging feeding a SIEM. Structured logs and event emission designed to flow into security-information-and-event-management systems, including the eventual goal of signed action receipts so the record is tamper-evident, not merely present.
Isolation — containing execution
- Sandboxing via OS-level containment. The NSA explicitly names Linux containment primitives — Landlock, seccomp, network namespaces — and per-tool execution constraints. Each MCP server’s execution should be boxed so that a compromise cannot move laterally or escalate.
Integrity — trusting the messages
Per-message signing. Cryptographic signatures on MCP messages themselves, with expiration timestamps, nonces, and replay protection. The NSA is explicit that TLS is not sufficient here: it wants integrity at the protocol-message layer, not just the transport layer.
Local MCP discovery scanning. The ability to identify open local MCP listeners — to know what MCP endpoints exist on a host in the first place, since you cannot secure servers you do not know are running.
Four Operational Requirements Behind the Nine
Some analyses of the guidance (notably Speakeasy’s) compress the nine controls into four operational principles, which are useful as a mental model:
- Cryptographic message integrity — sign and verify every MCP message at the protocol layer, not just TLS.
- Least privilege at the tool-call boundary — scope every invocation to the minimum permissions required, with no ambient authority.
- Tamper-evident audit — a cryptographically provable trail covering every agent action, where “action” includes more than tool calls.
- Trust chains — end-to-end trust across the full MCP stack, with the gateway explicitly named as a trust boundary.
The phrase “every agent action” in the audit principle is the one worth pausing on. A tool call is one kind of agent action. In a multi-agent system there are others — delegating to a sub-agent, spawning a task, approving an authorization, recording a message between agents. The NSA’s audit requirement, read literally, covers the coordination layer as well as the tool-invocation layer, which is a meaningfully larger surface than most current logging captures.
What This Means for How You Build
Translating nine controls into engineering decisions, three architectural commitments do most of the work.
A gateway is now table stakes, not an optimization. Requirements 1, 2, and 3 all assume a single inspection point between agents and external MCP servers. Without a gateway there is nowhere to run DLP, enforce rate limits, or scan tool output for injection. The NSA does not mandate a product, but it mandates a position in the architecture — and that position is a filtering proxy. The agency even acknowledges the maturity gap candidly: “MCP-aware security proxies remain limited and are still maturing.”
Logging has to be structured and SIEM-bound from the start. Requirements 4, 5, and 6 are not satisfied by application logs. They call for per-invocation structured records (tool name, parameters, identity, result) in a form a SIEM can ingest, with definition fingerprinting and, ultimately, signed receipts. Retrofitting this onto a deployment that logged free-text is expensive; designing for a structured JSONL-style audit stream up front is cheap.
Isolation should be per-server, not per-session. Requirement 7’s call for OS-level containment is satisfied by running each MCP server in its own sandbox with seccomp profiles and network namespaces. Container-per-server isolation meets this bar; session-level isolation generally does not, because it shares execution context across servers.
It is worth being honest about where the ecosystem is incomplete. Requirement 8 — per-message signing with expiration timestamps — is the control most implementations do not yet ship, and the NSA effectively flags it as “not yet implemented in the ecosystem.” That is a roadmap signal for tooling authors rather than a checkbox most teams can tick today. Open-source self-hosted gateways such as MCPProxy already cover the filtering, structured-logging, inventory-pinning, and Docker-per-server isolation requirements (roughly seven and a half of the nine), with message signing and signed receipts as the known remaining gaps — which is a reasonable picture of where the category stands, not just one tool.
How This Connects to the Rest of 2026’s Compliance Calendar
PP-26-1834 does not arrive in isolation. Its September 30 deadline sits inside a dense regulatory quarter. The EU AI Act’s transparency obligations (Article 50) land on August 2, 2026. DORA has been in active enforcement for financial entities since January 2025, and supervisors are now asking banks to evidence AI testing in practice — with MCP-connected workflows squarely in scope. The EU AI Act’s high-risk logging obligations, while pushed to December 2027 under the Omnibus VII agreement, ask for the same lifetime event records.
The encouraging part is that these frameworks converge. The infrastructure that satisfies the NSA’s nine controls — a filtering gateway, structured per-invocation audit logs, per-server isolation, tamper-evident records — is substantially the same infrastructure DORA’s ICT risk requirements and the EU AI Act’s logging mandate ask for. They arrive at the same operational shape because the underlying risk is the same: being able to reconstruct, for any past moment, which agent did what, with which tool, on which data, and on whose authority.
For federal contractors, the near-term task is concrete: map your current MCP deployment against the nine requirements, identify which of the four architectural commitments you are missing, and prioritize the gateway and structured-logging work, since those unblock the largest number of controls at once. September 30 is closer than it looks.