The NSA published nine MCP security recommendations in PP-26-1834 (May 2026), eight of which are implementable today with Kubernetes-native controls: namespace isolation, Pod Security Standards, Kyverno admission policies, and OpenTelemetry SIEM integration. Only Recommendation #6, cryptographic message signing, requires MCP protocol specification changes not yet available in any SDK.
On May 20, 2026, the NSA Artificial Intelligence Security Center published its first document specifically addressing Model Context Protocol security: a 17-page Cybersecurity Information Sheet (PP-26-1834) covering nine concrete recommendations for organizations running MCP servers in production. This is not a general AI security posture document. It names MCP by protocol, identifies specific threat vectors, references documented CVEs, and calls out the serialization risk surface as active rather than theoretical.
For platform engineers already running MCP infrastructure, this document codifies what should already be in your security posture and identifies two gaps - one fixable with current tooling, one that requires the MCP specification itself to evolve.
What the NSA Published and Why It Matters
The NSA AISC released “Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation” (U/OO/6030316-26, PP-26-1834) on May 20, 2026. The document is publicly available from NSA.gov.
The adoption numbers in the document explain why an intelligence agency is paying attention. MCP now sees approximately 97 million monthly SDK downloads as of March 2026, with around 57 million weekly downloads across the TypeScript and Python SDKs. Over 5,800 community and enterprise MCP servers exist in the wild, and 51,000+ npm projects depend on @modelcontextprotocol/sdk. MCP workloads span business, finance, legal, software engineering, and applications handling sensitive PII.
The NSA draws an explicit parallel to early web protocols: adoption moved faster than security standardization, and the gap is now large enough to warrant an intelligence agency warning. Unlike many security advisories, this one comes with specific implementation requirements, not just a risk inventory.
The CSI identifies five threat categories that anchor its analysis:
- Serialization and deserialization risks - Malicious payloads in serialized tool responses enabling injection or remote code execution
- Trust boundary violations - Multi-server architectures where a compromised tool server gains lateral access through implicit trust
- Agent misuse - Dynamic tool invocation creating trust relationships that were never explicitly authorized
- Token lifecycle management gaps - Bearer tokens vulnerable to lifting and replay attacks
- Denial-of-service via prompt storms - Resource exhaustion through MCP request flooding
CVE-2025-49596 (remote code execution via unsanitized parameters) appears by reference as documented evidence that serialization risks are exploitable, not hypothetical. The AISC describes these as “an active vulnerability surface, not a theoretical risk.”
The Nine NSA MCP Security Recommendations
graph TB
subgraph PROTO["Protocol Layer — Requires MCP Spec Evolution"]
R6["#6 Cryptographic Message Signing\nnonces + expiry timestamps + crypto binding"]
end
subgraph APP["Application Layer — Implementable Now"]
R1["#1 Code Audit and Maintenance"]
R4["#4 Parameter Validation"]
R7["#7 Output Sanitization"]
end
subgraph INFRA["Infrastructure Layer — Implementable Now"]
R2["#2 Trust Boundary Definition"]
R3["#3 Data Classification Alignment"]
R5["#5 Execution Sandboxing"]
R8["#8 SIEM Integration"]
end
subgraph GOV["Governance Layer — Implementable Now"]
R9["#9 Inventory Management"]
endThe nine recommendations span four implementation layers. Eight are actionable today with existing Kubernetes tooling. Recommendation #6 requires protocol-level changes to the MCP specification itself.
Rec #1: Code Audit and Maintenance
Use only actively maintained MCP server projects and apply rigorous code audits before deployment. In practice: verify image provenance with Sigstore/cosign, enforce SBOM attestations at admission time, and block pods that pull from unverified registries.
The code audit requirement extends to your supply chain. An MCP server pulling dependencies at runtime from npm or PyPI without a lockfile violates this recommendation regardless of how well the server code itself has been audited. Lock files are not optional for production MCP servers.
Rec #2: Trust Boundary Definition
Define explicit trust boundaries between all MCP components. Every MCP server should operate in its own namespace with RBAC scoped to exactly what it needs and NetworkPolicies restricting both ingress and egress to known counterparts.
Two MCP servers in the same namespace that have never been audited for inter-dependency are implicitly trusting each other through the absence of a policy. Trust must be explicit, not assumed by default.
Rec #3: Data Classification Alignment
Align MCP tools with data classification zones. The document recommends preferring local MCP servers (running on the same machine as the agent host) for sensitive data, rather than routing that data through remote MCP servers where it traverses additional network hops and trust boundaries.
In Kubernetes terms: namespace-level classification labels and admission policies that restrict which namespaces can schedule MCP server pods with access to classified Secrets or sensitive PVC mounts. A mcp-server pod that can read classification: confidential Secrets should only be schedulable in a namespace labeled data-classification: confidential.
Rec #4: Parameter Validation
Validate all parameters against defined schemas and block ambiguous parameter forwarding. An MCP server that accepts an arbitrary parameters object and forwards it to a downstream API without validation is a proxy for injection.
The implementation path is a gateway with External Authorization: agentgateway with its ExtAuthz policy engine can enforce per-tool parameter schemas before requests reach the MCP server. Kubernetes admission control alone does not help here because parameter validation must happen at request time, not at pod scheduling time.
Rec #5: Execution Sandboxing
Sandbox tool execution using OS-level security frameworks: Landlock, seccomp, and network namespaces. Apply least privilege at the process level, not just the container level.
This recommendation connects directly to the MCP STDIO transport problem: any MCP server using STDIO transport runs as a subprocess with the parent process’s full OS privileges. The NSA’s position is that unsandboxed subprocess spawning is not acceptable for production deployments. Use Streamable HTTP transport and enforce Pod Security Standards with the restricted profile.
The working pod spec below demonstrates the full security context:
apiVersion: v1
kind: Pod
metadata:
name: mcp-server-example
namespace: mcp-servers
labels:
app.kubernetes.io/part-of: mcp-server
mcp.kaden-projects.com/server-name: example-server
mcp.kaden-projects.com/version: "1.2.0"
annotations:
mcp.kaden-projects.com/last-audit-date: "2026-05-27"
spec:
securityContext:
runAsNonRoot: true
seccompProfile:
type: RuntimeDefault
containers:
- name: mcp-server
image: registry.example.com/mcp-servers/example:1.2.0
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
runAsUser: 1000
runAsGroup: 1000
resources:
limits:
cpu: "500m"
memory: "256Mi"
requests:
cpu: "100m"
memory: "128Mi"readOnlyRootFilesystem: true forces any writeable operations to explicitly mounted volumes. Dropping all capabilities prevents the container from acquiring elevated kernel access even after compromise. runAsNonRoot: true at the pod level is a backstop that prevents any container in the pod from running as root even if the container image’s default user is root. Setting cpu and memory limits on every MCP server pod also directly addresses the prompt-storm denial-of-service vector identified in the threat categories.
Rec #6: Cryptographic Message Signing
Add cryptographic signatures to MCP messages with expiration timestamps and replay protection metadata. The NSA envisions verifiable cryptographic identity bound to scope, trust level, and issuer - replacing the current bearer token model with something that cannot be lifted and replayed.
This is the one recommendation that cannot be implemented today. Current MCP SDKs have no protocol-native per-message signing support. Bearer tokens are the authentication primitive, and bearer tokens are exactly what this recommendation identifies as insufficient: they are liftable and replayable without cryptographic binding to the originating request context.
The NSA is signaling where the MCP specification needs to go. For now, the nearest practical mitigation is short-lived tokens with narrow scope, rotated frequently, and transmitted only over mTLS channels. That is a partial defense, not an implementation of this recommendation.
Rec #7: Output Sanitization
Treat all tool outputs as untrusted and filter before passing downstream. An MCP server is a black box from the agent’s perspective. Whatever it returns should be treated with the same suspicion as raw user input before being passed to another tool or used to construct a system prompt.
The sanitization requirement is especially critical in multi-agent chains where one agent’s tool output becomes the next agent’s input. A tool that returns a response containing injection payloads targeting a downstream LLM can propagate through an entire chain before anyone notices. Output filtering at the MCP gateway layer - before the response reaches the agent - is the architecture that intercepts this class of attack at the right level.
Rec #8: SIEM Integration
Integrate MCP telemetry into SIEM and threat detection systems. Every tool call, tool response, agent identity assertion, and authentication event should produce a structured log entry that your security team can query.
The Kubernetes-native path: OpenTelemetry for structured MCP telemetry, Falco for runtime behavioral detection (unexpected process spawning, unexpected network connections from MCP server pods), and an aggregation pipeline to Elasticsearch, Splunk, or equivalent. Any pod labeled app.kubernetes.io/part-of: mcp-server that spawns a child process outside its defined execution model is an anomaly worth alerting on immediately.
Rec #9: Inventory Management
Maintain a formal inventory of deployed MCP servers with versioning and patch history. You cannot audit or patch what you do not know exists.
The Kyverno policy below enforces the minimum metadata required to maintain that inventory. Every MCP server pod that reaches the admission webhook must declare its server name, version, and last audit date. Pods that cannot supply this metadata are blocked from the cluster:
apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata:
name: require-mcp-server-inventory-labels
spec:
matchConstraints:
resourceRules:
- apiGroups: [""]
apiVersions: ["v1"]
resources: ["pods"]
operations: ["CREATE", "UPDATE"]
matchConditions:
- name: has-mcp-label
expression: "object.metadata.labels.exists(k, k == 'app.kubernetes.io/part-of' && object.metadata.labels[k] == 'mcp-server')"
validations:
- expression: "has(object.metadata.labels['mcp.kaden-projects.com/server-name'])"
message: "MCP server pods must have mcp.kaden-projects.com/server-name label for inventory tracking (NSA CSI Rec #9)"
- expression: "has(object.metadata.labels['mcp.kaden-projects.com/version'])"
message: "MCP server pods must have mcp.kaden-projects.com/version label for patch tracking (NSA CSI Rec #9)"
- expression: "has(object.metadata.annotations['mcp.kaden-projects.com/last-audit-date'])"
message: "MCP server pods must have last-audit-date annotation for code audit compliance (NSA CSI Rec #1)"Combine this with Kyverno background scanning to generate PolicyReports that surface existing non-compliant deployments. Background scan mode means you get visibility into the MCP servers that are already running in your cluster without requiring a re-deploy.
The “Continuum” Argument: Why Endpoint Fixes Are Not Enough
The NSA’s most consequential architectural claim is that securing MCP requires treating the agentic environment as a continuum. The document states that misaligned assumptions at any stage can propagate and compound into exploitable conditions - and explicitly warns these “are not isolated problems that can be patched at the interface or endpoint level.”
This framing has concrete implications for your security posture. Patching individual MCP servers does not address the trust assumptions between them. Adding authentication to a single tool endpoint does not address what happens when a tool returns a malicious response that the next component processes without validation. The attack surface is the entire chain, not the individual endpoints.
graph TD
A["Compromised MCP Server\nReturns Malicious Output"] --> B{"Rec #7: Output Filter?"}
B -->|"Filter present"| Z1["Attack Blocked"]
B -->|"Filter absent"| C["Downstream Agent\nProcesses Tainted Context"]
C --> D{"Rec #2: Trust Isolated?"}
D -->|"Namespace boundary"| Z2["Lateral Access Blocked"]
D -->|"Shared trust"| E["Second Tool Called\nWith Tainted Parameters"]
E --> F{"Rec #4: Params Validated?"}
F -->|"Schema enforced"| Z3["Malicious Params Rejected"]
F -->|"Forwarded as-is"| G["Production System\nReceives Attacker Input"]
G --> H{"Rec #5: Sandboxed?"}
H -->|"Restricted pod"| Z4["Blast Radius Contained"]
H -->|"Privileged container"| I["Full System Compromise"]
style A fill:#ef4444,color:#fff
style I fill:#ef4444,color:#fff
style Z1 fill:#22c55e,color:#fff
style Z2 fill:#22c55e,color:#fff
style Z3 fill:#22c55e,color:#fff
style Z4 fill:#22c55e,color:#fffWithout layered controls, a single compromised component propagates unchecked through the agentic environment. Each NSA recommendation inserts a circuit breaker at a specific propagation point in the chain.
Two weeks before the NSA MCP CSI, all six Five Eyes cybersecurity agencies published “Careful Adoption of Agentic AI Services” (May 1-3, 2026). That 30-page joint guidance identifies five risk categories for agentic deployments: privilege risk, design and configuration risks, behavioral risks, structural risks, and accountability risks. The NSA CSI does not reference the Five Eyes document by name, but it operationalizes the same principles for MCP specifically. Together they form a two-layer framework: Five Eyes for organizational governance posture, NSA CSI for MCP-specific technical controls.
How Do NSA MCP Recommendations Map to Kubernetes Controls?
Eight of the nine recommendations have direct Kubernetes implementation paths:
| NSA Recommendation | Kubernetes Control | Tooling |
|---|---|---|
| #1 Code Audit | Image provenance verification | cosign / Sigstore, SBOM enforcement at admission |
| #2 Trust Boundaries | Namespace isolation | NetworkPolicy + RBAC per MCP server |
| #3 Data Classification | Namespace labels + policy | Kyverno/OPA classification enforcement |
| #4 Parameter Validation | MCP gateway | agentgateway + ExtAuthz |
| #5 Execution Sandboxing | Pod Security Standards | seccomp + read-only FS + dropped capabilities |
| #6 Message Signing | Not implementable | Requires MCP specification evolution |
| #7 Output Sanitization | Filtering proxy | MCP-aware egress proxy + DLP integration |
| #8 SIEM Integration | Telemetry pipeline | OpenTelemetry + Falco + Elasticsearch/Splunk |
| #9 Inventory Management | GitOps + admission control | Kyverno ValidatingPolicy + cosign |
graph LR
R2["Rec #2\nTrust Boundaries"] --> K2["Namespace Isolation\nNetworkPolicy + RBAC"]
R4["Rec #4\nParameter Validation"] --> K4["agentgateway\nExtAuthz Policy Engine"]
R5["Rec #5\nExecution Sandboxing"] --> K5["Pod Security Standards\nseccomp + read-only FS"]
R7["Rec #7\nOutput Sanitization"] --> K7["Egress Proxy\nDLP Integration"]
R8["Rec #8\nSIEM Integration"] --> K8["OpenTelemetry + Falco\nElasticsearch / Splunk"]
R9["Rec #9\nInventory Management"] --> K9["Kyverno Admission\nGitOps Manifests"]
R6["Rec #6\nMessage Signing"] -->|"requires spec evolution"| K6["No Implementation\nAvailable Today"]
style R6 fill:#6b7280,color:#fff
style K6 fill:#6b7280,color:#fffOnly Rec #6 (cryptographic message signing) has no current Kubernetes implementation path. The remaining eight map directly to primitives already available in your cluster.
The NetworkPolicy below implements Rec #2, restricting MCP server pod egress to the gateway namespace and DNS only:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: mcp-server-egress-restrict
namespace: mcp-servers
spec:
podSelector:
matchLabels:
app.kubernetes.io/part-of: mcp-server
policyTypes:
- Egress
egress:
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: mcp-gateway
ports:
- protocol: TCP
port: 8080
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
ports:
- protocol: UDP
port: 53MCP server pods in the mcp-servers namespace cannot initiate connections to any destination except the gateway namespace on port 8080 and kube-dns on port 53. A compromised MCP server cannot exfiltrate data to an external host or reach your database pods directly because the egress path does not exist at the network layer.
What This Means for Your Existing MCP Deployments
The NSA document validates the approach we have documented across four posts in this series and adds three new requirements that most existing MCP deployments will need to close.
timeline
Apr 20 : Kyverno + MCP Policy Enforcement
: Admission control for MCP server pods
Apr 27 : MCP STDIO RCE by Design
: Architecture flaw in subprocess execution model
May 1-3 : Five Eyes Agentic AI Guidance
: Governance framework across 5 risk categories
May 8 : TrustFall Config Poisoning RCE
: One-click RCE via project-scoped MCP config
May 20 : NSA MCP CSI PP-26-1834
: First US intel agency MCP security document2026 government guidance on agentic AI and MCP security, mapped against our coverage timeline. The NSA document consolidates the threat surface documented across four posts and adds formal inventory, message integrity, and SIEM telemetry as new requirements.
Our Kyverno enforcement post covers Rec #9 (inventory labeling via ValidatingPolicy) and Rec #2 (namespace isolation and NetworkPolicy). Our STDIO RCE analysis maps directly to Rec #5: the STDIO execution model is the primary example of unsandboxed tool execution the NSA recommends against. Our TrustFall coverage illustrates Rec #1 (code audit) and Rec #2 (trust boundary violations at the developer workstation level).
What the NSA document adds that the series has not explicitly covered until now:
Formal inventory with patch history (Rec #9, extended). The Kyverno policy enforces labels at admission time, but inventory means more than labels. Every MCP server version in your environment should be catalogued in a GitOps repository with associated CVEs, audit date, and upgrade plan. Labels are how you enforce it; the GitOps repository is where you track it over time.
SIEM integration for MCP telemetry (Rec #8). Your cluster likely logs pod events and API server activity. Most MCP deployments do not produce structured logs of tool calls, agent identity assertions, or tool response statuses. This telemetry pipeline is the gap most environments will need to close specifically for MCP workloads.
Output sanitization at the gateway (Rec #7). Filtering what comes back from MCP servers is infrastructure responsibility, not application responsibility. An agent developer should not be tasked with sanitizing tool responses before using them. That responsibility belongs at the gateway layer, where filtering can be consistent across all MCP servers regardless of which team wrote them.
Immediate audit checklist
Run these checks against your current MCP deployment:
- Every MCP server pod carries
mcp.kaden-projects.com/server-name,mcp.kaden-projects.com/version, andlast-audit-dateannotations - Every MCP server namespace has a NetworkPolicy restricting egress to the gateway namespace and DNS
- No MCP server pod runs with
privileged: trueor without a seccomp profile - MCP server images are verified with cosign before admission
- Your SIEM receives structured tool call logs from each MCP server
- You have a documented inventory of every MCP server, its data access scope, and its last patch date
- STDIO transport is blocked via admission policy in all production namespaces
If any check fails, prioritize in the order listed: inventory first, then network isolation, then sandbox enforcement, then telemetry pipeline.
Frequently Asked Questions
Does the NSA MCP document apply to my organization if we are not in national security?
Yes. The CSI is a public guidance document intended for organizations adopting MCP in production environments, explicitly including business, finance, legal, and software engineering sectors. The nine recommendations are universal security controls applicable to any MCP deployment handling sensitive data, not just national security applications.
Can I implement all nine NSA MCP recommendations today?
Eight of the nine are implementable now using existing Kubernetes primitives and tools: admission control, network policies, Pod Security Standards, SIEM pipelines, and GitOps inventory tracking. Recommendation #6 (cryptographic message signing with replay protection) requires changes to the MCP protocol specification and is not supported by any current MCP SDK. This is where the protocol needs to evolve, and no amount of infrastructure configuration closes this gap today.
How does the NSA MCP guidance relate to the Five Eyes agentic AI guidance published two weeks earlier?
The Five Eyes guidance (May 1-3, 2026) provides a governance framework for agentic AI across five risk categories: privilege, design and configuration, behavioral, structural, and accountability risks. The NSA MCP CSI (May 20, 2026) operationalizes those principles specifically for the MCP protocol. Together they form a two-layer framework: Five Eyes for organizational governance posture, NSA CSI for MCP-specific technical controls.
What should I do first to comply with the NSA MCP recommendations?
Start with inventory (Rec #9): catalog every MCP server running in your environment, its version, its data access scope, and its last audit date. Then enforce trust boundaries (Rec #2) with Kubernetes namespace isolation and NetworkPolicies. These two controls give you visibility and containment before tackling the more complex recommendations like parameter validation and SIEM integration. Without inventory, you cannot prioritize what to harden first.
Is MCP STDIO transport safe to use in production after this NSA guidance?
No. The NSA recommends sandboxing all tool execution (Rec #5), and STDIO transport executes server commands as subprocesses with the caller’s full OS privileges. This is the execution model the sandboxing recommendation is specifically designed to eliminate. Use Streamable HTTP transport in production, which routes through a gateway where you can enforce authentication, input validation, and traffic inspection. Block STDIO transport in production namespaces using admission control policies.