AI & MCP
The NSA's MCP security baseline: what it means for your gateway
Cameron McClellan
May 27, 2026 - 7 min read
The NSA published a 15-page Cybersecurity Information Sheet in May 2026 specifically about the Model Context Protocol. The document is the first formal guidance on MCP security from a US national security agency. It defines four operational requirements for any organization running AI agents in production.
This is not a framework with aspirational goals. These are specific, implementable controls. And because a government agency published them, they are about to appear on enterprise security questionnaires.
The threat model these requirements address
AI agents operating through MCP have a different attack surface than conventional software. An agent that authenticates once and runs autonomously can make hundreds of tool calls before any human reviews what it did. At machine execution speed, the consequences of a compromised credential or a tampered message aren’t bounded by human response time.
The specific failure modes are documented. Prompt injection attacks embed malicious instructions in content the agent reads, such as documents, API responses, database records. The agent follows those instructions using whatever authority it was granted at session start. Tool call results can be modified in transit when no message-level integrity check exists: TLS secures the channel, not the content passing through intermediaries. Audit trails that capture only conversations and miss individual tool invocations leave a forensic gap.
The NSA’s four requirements map directly to these failure modes. Message integrity verification closes the in-transit modification gap. Per-call permission scoping limits the damage a hijacked agent action can cause. Tamper-evident audit creates a forensically reliable record of what actually executed. Trust chains prevent an attacker from substituting a malicious gateway that appears legitimate to both clients and servers.
The requirements themselves aren’t novel. A Dev.to analysis maps them to existing IETF specifications, OpenAPI extension points, and OWASP guidance. The security community has been discussing these problems for the past year. What changed is that the NSA formalized them, which gives organizations a named baseline to test against rather than informal community consensus.
The four requirements
1. Cryptographic message integrity
The requirement is to cryptographically sign and verify every MCP message at the protocol layer. Not just TLS. Message-level signatures on the content itself.
TLS secures the channel between two endpoints. It does not authenticate individual messages if there’s any intermediate processing between those endpoints. A gateway terminates TLS to inspect traffic. When it does, it decrypts, processes, and re-encrypts. Both sides see a valid TLS session throughout. But the messages have passed through an intermediary that could read or modify them.
If that intermediary is compromised, message content can be altered in transit without detection. TLS only tells you the channel is encrypted. It says nothing about whether the content was modified by something in the middle.
Message-level signing closes this gap. The sender signs the message content with their private key. The receiver checks the signature. Any modification between signing and verification invalidates the signature, regardless of how many intermediaries handled the message.
In an MCP deployment, every tool call from a client carries a verifiable signature. If your MCP gateway processes that message and passes it to the MCP server, the server can verify the signature was made by the original client. Tampering is detectable even if the attacker controls a node in the processing chain.
2. Least-privilege at the tool-call boundary
The requirement is to scope every tool invocation to the minimum permissions required. No ambient authority. The agent doesn’t carry a broad session token covering everything it might need. Each tool call gets exactly the access that specific call requires.
The failure mode this prevents is direct. An agent authenticates once with a broad credential and makes tool calls using those credentials for the duration of the session. Any one of those calls can be hijacked. Prompt injection attacks embed instructions in content the agent reads. When the agent follows those instructions and makes a tool call, that call inherits the full scope of the agent’s ambient authority.
Per-call scoping closes this attack surface. The agent can read from a specific database table in response to the current prompt, but that authorization doesn’t extend to writes or to different tables. Permissions are attached to the specific invocation, evaluated against what that call actually needs.
This is harder to implement than session-level authentication. That difficulty is precisely why it’s a requirement. Ambient authority is a systemic vulnerability in agent deployments. It’s one of the main reasons prompt injection attacks can escalate to serious consequences.
3. Tamper-evident audit for every agent action
The requirement is a cryptographically provable audit trail covering every agent action. Signed entries. Every tool call, every invocation result, every decision the agent made. Not just conversations.
This requirement exists because AI agents operate at machine speed. By the time a security incident is investigated, the agent may have made hundreds of tool calls across dozens of systems. The audit trail is the only complete record of what happened.
Regular logs are not sufficient. A log entry that says “agent wrote file X” is only trustworthy if the log itself hasn’t been modified. If an attacker compromises the logging infrastructure, they can delete or alter entries. An investigation based on unsigned logs cannot prove those logs reflect what actually happened.
Tamper-evident audit uses cryptographic chaining. Each entry is signed, and each subsequent entry includes a hash of the previous one. To remove or alter any entry, an attacker would need to recompute every subsequent entry using signing keys they don’t have. The integrity of any entry can be verified by any party holding the root public key.
For security teams, this means an incident investigation produces a verifiable record. Not “our logs say the agent did this.” A cryptographically provable statement about what occurred.
4. Trust chains between clients, gateways, and servers
The requirement is end-to-end trust across the full MCP stack. The NSA explicitly names the gateway as a trust boundary, not a routing layer. That distinction is the point.
A routing layer forwards traffic. A trust boundary verifies identity before forwarding traffic. These are different functions with different security properties.
Without verified trust chains, the gateway is a single point of compromise. If an attacker substitutes a malicious gateway, MCP clients connect to it thinking they’re connecting to the legitimate one. The malicious gateway forwards traffic to legitimate MCP servers. Everything looks normal from the outside. But the attacker sees and can modify every message in transit.
Trust chains prevent this. The gateway presents a certificate that chains to a root authority the client already trusts. The client verifies this certificate before sending any traffic. An attacker without control of that root authority cannot produce a valid certificate. Substitution is detectable.
The same verification runs in the other direction. The gateway verifies the identity of MCP servers before routing traffic to them. A server that can’t present a valid certificate doesn’t receive requests. This blocks traffic redirection through DNS manipulation or other network-layer attacks.
What makes this a compliance surface now
The document is advisory. But NSA guidance on security architecture and cryptographic standards follows a well-established path: the security community codifies it, NIST incorporates the substance into Special Publications, and FedRAMP, CMMC, and sector-specific frameworks reference those publications in their compliance baselines.
Those frameworks bind the organizations that are deploying MCP today. Whether your org cares about CMMC, HIPAA, SOC 2, ISO, or FedRAMP, the NSA’s recommendations are a signal of where the regulatory winds are blowing.
How Speakeasy maps to the baseline
The Speakeasy AI control plane is built to meet all four requirements from the start of a deployment. The architecture assumes adversarial conditions: agents will be targeted, messages can be tampered with in transit, audit trails need to be provable to parties who weren’t present when they were written.
The MCP gateway handles message integrity verification, per-invocation permission scoping, and trust chain validation. Every tool call is verified against its cryptographic signature before forwarding. Each invocation carries only the authorization it needs for that specific call, not a broad session credential. Clients verify the gateway before sending traffic; the gateway verifies servers before routing; a server that can’t be authenticated doesn’t receive requests.
Agent hooks instrument every tool invocation in a signed, append-only log. Authentication decisions, tool calls, policy evaluations, and invocation results are all recorded in cryptographically chained entries that can be verified by any party holding the root key: a record designed to survive forensic review, not just application logging.
Organizations deploying MCP through Speakeasy have a documented architecture that maps directly to each of the NSA’s four requirements.