The NSA just made the case for a policy layer in front of MCP

If you build infrastructure for AI agents, the NSA’s May report on MCP security is the most important 17 pages you’ll read this quarter: Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation. It announces no new attack class, and most of what it describes will be familiar to anyone watching MCP closely. What makes it matter is that it consolidates the field’s tacit knowledge into a single, vendor-neutral, citable artefact.

This post does three things: states what the NSA actually said (not what the headlines said), is honest about the one paragraph directed at products like PolicyLayer, and maps their recommendations to where the work actually happens.

The core argument: MCP security sits outside the protocol

The NSA’s central point is architectural. MCP defines how messages move between an agent and a tool, and it deliberately leaves the controls that govern what moves, and whether it should, to the implementer. Work a protocol hands to implementers doesn’t get done by accident. Two quotes carry the weight of the whole document:

“MCP’s rapid proliferation has outpaced the development of its security model… MCP was released with a flexible and underspecified design, allowing implementers freedom of design but also introducing ambiguity for safe usage.”

“Its current security posture remains uneven and highly dependent on implementation discipline rather than protocol guarantees.”

And the recommendation that follows:

“To securely adopt MCP, organizations must move beyond the suggestions mentioned in the protocol and adopt deliberate security controls that are beyond the scope of the document.”

That last sentence is the brief PolicyLayer was founded to address. The protocol is a contract about how messages move; the security controls that govern what moves and whether it should sit outside the protocol by design. The NSA asks organisations to build, buy, or otherwise acquire those controls deliberately rather than hoping their MCP server author thought of them.

The concerns, in their own words

The report enumerates eight specific concerns. The language matters, so we’ll quote them tightly:

• Access control. “Associating a session to an identity is not defined by the protocol… Many implementations omit authentication entirely, and those that do include it often lack any role-based enforcement.”
• Insecure context or data serialization. “Serialized content including comments or prompts may open a path for injection techniques because it can include executable code or embedded model calls.”
• Poor approval workflows. “A change in capability or data access for an MCP server that is already trusted or connected often can be made without approval… a previously benign and approved AI service could later access sensitive resources on demand, without triggering any review.”
• Token or session security. “Authorization in MCP is optional… the core MCP specification does not mandate any requirement for lifecycle management.”
• Misconfigurations and poor implementation. “MCP servers often lack task or data isolation, creating opportunities for inadvertent data exposure.”
• Inconsistent behaviors. “This divergence, driven by probabilistic interpretation of prior context, can be exploited by a malicious actor who preconditions the agent to arrive at a specific or unsafe outcome.”
• Poor or missing audit logs. “Many implementations either omit logging entirely or record only minimal operational metadata.”
• Denial of service and fatigue-based techniques. “MCP provides an open door for such resource exhaustion techniques if not properly managed.”

Six of these eight are, in operational terms, one problem: there is no deterministic, content-aware decision point on the call path between the agent and the tool. Access control, approval workflows, token lifecycle, isolation, audit, and rate limiting are not separate features. They are the same enforcement primitive applied to different categories of risk. Inconsistent behaviour and serialisation injection need additional controls upstream and downstream, but everything else collapses to the same architectural component.

The recommendations, mapped

The NSA’s recommendations section lists nine controls. Three sit at the network or OS layer (filtering outgoing proxy / DLP, OS sandboxing with seccomp/AppArmor/SELinux/AppContainers, local network scanning for stray servers). Six sit at the MCP layer, and those are the ones a policy decision point on the call path executes.

NSA recommendation	What it requires at the MCP layer
Design for boundaries: align tools and models with data classification zones	Per-call decisions that know which tool, which agent, which data zone
Validate parameters: “every tool invocation or model execution request validate its inputs against well-defined schemas, expected ranges, and the intended context”	Schema-aware inspection of tools/call arguments before execution
Sign and verify MCP messages: “MCP messages should cryptographically bind requests to time and context to prevent tampering, intentional replay techniques, and unintended re-execution”	Signing and verification at a single trusted point in the path
Filter and monitor output pipelines: “Each output must be treated as untrusted input to the next phase of the pipeline”	Content-aware response inspection before results re-enter the model’s context
Instrument for logging and detection: “All tool and model invocations should be logged, including the exact parameters, identities involved, and (where feasible) cryptographic hashes of results or output”	A tamper-evident audit record that captures arguments, identities, decisions, and outcomes
Track and patch MCP related vulnerabilities: “a clear inventory of all deployed MCP agents and tools, along with versioning, patch history, and known security concerns”	A registry of the MCP servers an organisation has actually deployed

This is the surface PolicyLayer was built to cover. We’ve shipped against most of this list because the gaps were obvious to anyone who’d put an agent in front of a real tool. If you want a single sentence to take to your CISO: the NSA’s MCP-layer recommendations describe the surface area of an in-path policy decision point.

The maturity caveat

The report has one paragraph aimed squarely at this category. On page 13:

“MCP-aware security proxies remain limited and are still maturing, but may offer partial mitigations. However, given their early stage of development, they should be used with caution, especially when handling sensitive data.”

That applies to us and to every other vendor in this category, and it’s fair. The MCP-aware proxy category is young, and the protocol underneath it is still moving. Anyone in this space claiming maturity is asking you not to do diligence.

Three things are worth saying in response:

1. Deterministic enforcement beats LLM-based heuristics. The maturity concern the NSA flags is real for products that use a model to decide whether another model’s tool call is safe. PolicyLayer’s enforcement is policy-as-code: declarative rules evaluated deterministically. Same inputs, same decision, every time. That makes a control auditable, and it’s the difference between a deterministic policy and a guardrail.
2. The protocol is finally giving us the surfaces we need. Recent revisions to MCP add headers that let gateways route and enforce without parsing JSON-RPC bodies, formalise W3C Trace Context for end-to-end audit, and tighten OAuth/OIDC alignment. A proxy built today stands on materially more stable footing than one built six months ago.
3. The honest scope. We don’t claim to solve serialisation deserialisation bugs in your MCP server implementation, or stop a malicious MCP server author from shipping a poisoned tool description. We sit between the agent and the server and decide which calls run, with what arguments, by whom, with what audit. That’s a defined surface, and we do it deterministically.

If you’re piloting this category, the NSA’s caution is the right starting posture. Start narrow: a deny-by-default policy with a tight allowlist of the calls you know you need, scoped to one upstream and a handful of people, then widen the rules as real usage confirms them. Every successful proxy-class technology was adopted this way: WAFs, eBPF security agents, service mesh policy, all incrementally, scope by scope. This one should be too.

What PolicyLayer does against this list

Concretely, for each MCP-layer control the NSA names:

• Design for boundaries: every grant binds an identity to a registered upstream and a policy. The policy is deny-by-default. A tool call runs only if a rule says it should.
• Validate parameters: policies evaluate against the structured arguments of every tools/call. Regex on args.repo, numeric bounds on args.amount, schema constraints on whole objects.
• Sign and verify MCP messages: every request through the proxy is bound to a per-person scoped token. Unauthorised callers never reach the upstream.
• Filter and monitor output pipelines: response inspection before results re-enter the model’s context is on the immediate roadmap, made tractable by the recent MCP RC changes. Today, every response is recorded in the durable audit.
• Instrument for logging and detection: every request is recorded independently of the model’s own account of what it did, with the full argument payload, the policy decision, and the identity of the caller.
• Track and patch MCP related vulnerabilities: the proxy is the registry. You declare which servers exist, and an unknown upstream isn’t reachable.

AI client  ──▶  PolicyLayer proxy  ──▶  upstream MCP server
                       │
                       ├─ authenticate per-person token
                       ├─ evaluate tools/call against policy  → allow / deny
                       └─ write durable audit record

Routing a client through PolicyLayer is a config change, not an SDK rewrite:

// .cursor/mcp.json: the client points at PolicyLayer, not the upstream
{
  "mcpServers": {
    "github": {
      "url": "https://proxy.policylayer.com/mcp/<server-uuid>/",
      "headers": {
        "Authorization": "Bearer <your-scoped-token>"
      }
    }
  }
}

A policy that satisfies the NSA’s “Design for boundaries” recommendation for a GitHub upstream looks like this:

{
  "version": "1",
  "default": "deny",
  "tools": {
    "list_issues": {},
    "create_issue": {
      "require": [
        {
          "conditions": [
            { "path": "args.repo", "op": "regex", "value": "^policylayer/" }
          ]
        }
      ]
    }
  }
}

Deny by default. This token can list issues, and open them only in repos under policylayer/. Deleting a repository, reading a private org’s code, opening an issue somewhere else: anything outside the rules never reaches GitHub, regardless of what the model was talked into.

The bottom line

The NSA report is good for the category and good for PolicyLayer. It validates the thesis that MCP needs deliberate security controls beyond what the protocol provides; it enumerates the controls in language a CISO can act on; and it cautions sensibly about the maturity of the products that implement them. We agree with all three.

If your organisation is running MCP in production, do one thing with the NSA CSI: open the Recommendations section and name the owner of each control. Where the answer is “we trust the MCP server author,” you’ve found the gap the report is warning about. Every one of those controls can live at a single point on the call path. That is the whole reason the point should exist.

Related Reading

• AI Agent Containment Starts at the Environment Layer: Anthropic’s containment architecture, and why deterministic enforcement has to sit below the model
• What is MCP policy enforcement?: the category, defined
• Why prompt guardrails fail at agent safety: the probabilistic-defence problem
• MCP security beyond guardrails: runtime enforcement

Docs:

• Quick Start: register a server, write a policy, route a client
• Writing policies: the full policy language
• Core concepts: servers, grants, policies, the proxy