Skip to content
Muhammad Moeed
mcp tutorials

NSA MCP Security Guidance: A Developer's Action List (2026)

The NSA published MCP security guidance on May 20, 2026. Here are the four named controls, the threats they address, and what to do in your server today.

By Muhammad Moeed · · 9 min read

On May 20, 2026, the National Security Agency’s Artificial Intelligence Security Center published a Cybersecurity Information Sheet titled Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation. It is the first government-grade security baseline for MCP, and if your team runs MCP servers in production, it is now the document recruiters, security reviews, and procurement teams will quietly ask you to follow.

Most of the coverage so far has been summary-level news. This is the developer translation. What the document actually says, the four named threats it calls out, the four controls it expects, and the specific things you can change in your MCP server this week to meet that bar.

Why this matters even if you do not work for the government

The NSA does not regulate private deployments. It publishes guidance. But every prior NSA cybersecurity information sheet on a new protocol has become the de facto baseline that enterprise security teams require from any vendor. Once your largest customer reads this, you will be asked to comply.

The faster you adopt it, the less rework you have to do when that question lands in a security review.

The four threats the NSA names

The document is specific about which failure modes are different in AI agent systems versus traditional APIs. Four are called out by name.

Threat 1: Prompt injection at protocol scale

Malicious instructions embedded in content an agent reads, documents, API responses, database rows. The agent then executes those instructions “using whatever authority it was granted at session start.” Unlike a SQL injection in a single endpoint, an MCP-driven agent might walk through five tools and run the injected instruction far from where it was read.

The unique part of this threat at protocol scale is that the agent’s session credentials persist across every tool call, so one poisoned document compromises the whole session, not just one request.

Threat 2: In-transit message tampering through gateways

When an MCP gateway terminates TLS and re-encrypts traffic on the way to the server, “messages have passed through an intermediary that could read or modify them.” TLS does not detect this because the intermediary holds a valid certificate.

This is not a hypothetical. Most production MCP deployments today use a gateway for OAuth, rate limiting, or logging. Every one of those gateways is, by definition, a man-in-the-middle.

Threat 3: Audit trail gaps

“Audit trails that capture only conversations and miss individual tool invocations leave a forensic gap.” Agents operate at machine speed. A misbehaving agent might make hundreds of tool calls between user prompts. If your logs only show the user-facing conversation, you cannot tell after the fact which call did the damage.

Threat 4: Gateway compromise

A substituted malicious gateway “appears legitimate to both clients and servers.” It speaks the protocol correctly. It just also reads and modifies every message that passes through. Without something stronger than TLS at the protocol layer, neither end can tell.

The four controls the NSA expects

For each threat there is a corresponding control. The document treats these as a single baseline, not a menu.

Control 1: Cryptographic message integrity

Every MCP message should be signed and verified at the protocol layer, not at the transport layer. Signatures must be verifiable even through intermediaries, so that tampering by a compromised or substituted gateway is detectable by the client and the server.

What to do this week: add a message signing layer to your MCP server. If you build your own, use a standard like JWS over the message body. If you use a framework, watch for the upcoming MCP spec changes around protocol-level signing in the 2026-07-28 release candidate, which lines up with this exact requirement.

Control 2: Least-privilege tool-call scoping

Each individual tool invocation should get “exactly the access that specific call requires.” No ambient session authority. So if a user authorizes an agent to read one repository, a hijacked tool call cannot then read every repository the user has access to.

What to do this week: stop attaching broad scopes to session tokens. Issue a short-lived, narrowly-scoped credential per tool call. If your MCP server is in front of a database, scope each call to a specific table or operation, not to the whole connection.

Control 3: Tamper-evident audit

Cryptographically chained, signed entries for every agent action. Designed so entries cannot be altered “without recomputing every subsequent entry using signing keys they don’t have.” This is the same shape as a transparency log or a blockchain ledger, applied to your audit trail.

What to do this week: log every tool invocation, not just the user-facing turn. Stamp each log entry with a hash that includes the previous entry’s hash. If your stack supports it, an append-only ledger like AWS QLDB or a similar tamper-evident store is the cleanest fit. If not, even a daily signed digest of your CloudWatch logs is a real improvement.

Control 4: End-to-end trust chains

Gateways should be treated as “trust boundaries, not routing layers.” Clients verify the gateway. The gateway verifies each downstream server. Trust is composed deliberately at each hop instead of inherited from TLS termination.

What to do this week: stop using your gateway as a pass-through. Have each downstream MCP server present a verifiable identity (a signed JWT, a workload identity from your cloud, or mTLS with private CA), and check it at the gateway. Then have the gateway present its own identity back to the client.

The action list, in one place

If you want a single checklist to hand a developer, this is it.

  1. Sign every message. Add JWS or equivalent message-level signatures to your MCP traffic. Do not rely on TLS alone.
  2. Scope every tool call. No more long-lived session tokens with broad scope. Issue per-call credentials with the minimum permission required.
  3. Log every invocation. Capture each tool call, not just the user turn, and chain the entries cryptographically.
  4. Verify every hop. Treat your gateway as a trust boundary that must be authenticated at both ends, not a transparent pipe.
  5. Pin your gateway identity. Clients should verify the gateway’s identity before sending traffic, the same way you verify a TLS certificate.
  6. Plan for the 2026-07-28 spec. The new MCP release candidate moves several of these guarantees to the protocol layer. Read it now so the migration is one week of work, not three.

If you are running an MCP server today and you can check off only one of these, start with item 3 (log every invocation). It is the cheapest to ship, it gives you forensic capability if something goes wrong, and it is the foundation everything else builds on.

What the NSA guidance does not solve

It is worth saying out loud. The NSA document is a baseline, not a complete picture. Three things it does not address.

Tool description trust. A tool with a polite description like fetches public weather could still call any URL it wants once invoked. The NSA controls protect the message and the audit trail, not the runtime behavior of the tool itself.

Cost denial-of-service. A malicious prompt that nudges an agent to call an expensive tool a thousand times is a real attack pattern. The NSA controls let you detect this in the audit log, but they do not stop it.

Supply chain. The MCP server binary you installed from a community package could itself be malicious. None of the NSA controls protect against that. Standard supply-chain hygiene (signed releases, dependency review, sandboxed execution) still applies.

For supply-chain and runtime risks, the broader MCP server security guide covers patterns the NSA document leaves out.

Frequently asked questions

Is this guidance mandatory?

For most teams, no. The NSA does not regulate private MCP deployments. But every prior NSA Cybersecurity Information Sheet has become the de facto baseline that enterprise procurement and security review teams require. If you sell to enterprise, plan for it.

How is this different from regular API security?

MCP agents have persistent session credentials and execute tools far from where the input was read. So a prompt-injected document at step one can drive a credential-laden tool call at step five. Traditional API security assumes the request body is the only attack surface, which is not true here.

Does the upcoming MCP 2026-07-28 spec already handle this?

Partially. The release candidate introduces stateless transport, the Extensions framework, authorization hardening, and a formal deprecation policy. Protocol-level message signing is on the roadmap but not yet in the RC. Treat the NSA controls as the destination and the new spec as one step on the way.

What about MCP servers running on AWS or Azure?

The NSA controls map cleanly onto cloud primitives. AWS IAM and Secrets Manager give you Control 2 (per-call scoping). AWS QLDB and CloudTrail handle Control 3 (tamper-evident audit). AWS Verified Permissions or mTLS with Private CA handle Control 4 (trust chains). The deployment pattern is well-documented in AWS’s own Deploying MCP servers on Amazon ECS guide, though the NSA controls go beyond what that post covers.

Do I need a security team to implement this?

The first three controls (signing, scoping, logging) are within reach of any backend team. The fourth (trust chains) usually wants security review because it touches identity and certificate handling. Start with the first three. The fourth can wait two weeks.

Where can I read the document directly?

The NSA published it as a Cybersecurity Information Sheet through the AI Security Center on May 20, 2026. The official press release links to the PDF. The executivegov summary is the most readable secondary source.

Where to go next

The shortest path from where you are today to where the NSA wants you is to spend one afternoon on tamper-evident logging and one on per-call scoping. Those two changes meet half the baseline and give you the forensic capability you would want even if no one ever asked.