Putting MCP into production: what the NSA's security guidance actually says

On 20 May 2026 the NSA's AI Security Center published a Cybersecurity Information Sheet on the Model Context Protocol — Security Design Considerations for AI-Driven Automation (U/OO/6030316-26). When a signals-intelligence agency publishes design guidance on a barely year-old open protocol, the subtext is hard to miss: MCP has moved from a developer convenience to infrastructure sitting in the path of sensitive data, and its security model has not kept up. The NSA's framing is blunt — adoption has outrun the safeguards, and if you are running MCP against anything that matters, you are likely exposed in ways your existing tooling won't show you.

This is not an argument against MCP. It is the standard that connects language models to real systems, and that is worth having. It is an argument for deploying it deliberately — and the reassuring part, which this piece builds to, is that the risks are real but well understood, and almost none of the fixes are exotic. So here is the map: what the guidance identifies as the weak points, and the established engineering practice that closes each one. If you came for a verdict, it is this — MCP is safe to put in production, but only on purpose.

Why MCP is a different kind of risk

MCP inverts a familiar pattern. In most client–server systems the client asks and the server answers. In MCP the server frequently acts — it queries data and executes operations on behalf of the connected model. That inversion creates control-flow paths that traditional network and application monitoring were never designed to trace.

It is also, by design, underspecified. Like the early web protocols, MCP gives implementers freedom and leaves much to their discretion — which means the security floor sits wherever each implementer happens to put it. The protocol's own documentation concedes that it cannot enforce security principles at the protocol level. In practice that produces a recurring set of gaps:

• Authentication is optional, and where present it often lacks role-based enforcement — no built-in notion of who may Create, Read, Update or Delete what. MCP has no mechanism to exchange RBAC permissions when a connection is established.
• Tokens have no mandated lifecycle. Bearer tokens follow OAuth 2.1, but the spec requires no refresh, revocation, or replay control, so session hijacking and token reuse are left as problems for each implementer to solve — or not.
• Serialised context and tool parameters often pass without schema validation, so a "comment" or a tool description can smuggle instructions or code into an execution path.
• Servers lack task and data isolation, so the trivial weather server you deploy today can be quietly repurposed against sensitive data tomorrow.
• Logging is left to the implementer, so many deployments simply cannot reconstruct who did what.

None of these is exotic. They are the absence of controls we take for granted everywhere else — only now in a setting where the consequences are amplified, because an autonomous model is the thing making the calls.

Where it actually breaks

The guidance grounds these in demonstrated attacks, not hypotheticals. A few worth internalising:

• Tool poisoning and the rug pull. A malicious server advertises a benign tool at install, then switches to malicious behaviour after a couple of uses. Because a client trusts servers it has already connected to, and a server's capabilities can change without re-prompting for consent, the switch goes unnoticed. In one demonstrated case a malicious server's tool descriptions manipulated the client into exfiltrating a messaging app's data through a separate, trusted server — the two servers never communicated; the shared client was the conduit.
• Tool-name collisions. Where an orchestrator resolves tool names from a mix of public registries and local modules, an attacker can register a colliding name and have their code loaded in place of the legitimate tool.
• Over-broad scopes. The GitHub-server pattern grants tools blanket read/write across all of a user's repositories rather than narrow, per-repo permissions — so a compromised tool can read a private repo and publish its contents to a public one.
• Output poisoning in chains. One agent's output becomes another's input; if the downstream agent treats that output as instructions rather than data, a prompt injection cascades across the whole pipeline.
• Plain remote code execution. CVE-2025-49596 in the MCP Inspector testing tool allowed RCE via crafted messages — a reminder that the surrounding toolchain is in scope too.

The throughline is implicit trust: between client and server, between one agent's output and the next agent's input, between a tool's name and the code behind it. MCP assumes good faith at exactly the seams an attacker targets.

How to deploy it safely

The reassuring part is that almost none of the fixes are exotic either. The NSA's recommendations and ordinary sound engineering converge on a handful of principles:

• Run it where the data lives. The clearest line in the guidance: when processing private data, prefer a local instance of the MCP server. Sensitive data and the tools that touch it should not be reaching across the public internet to a third party's infrastructure. A server inside your own environment, with data never crossing your boundary, removes an entire class of leakage and custody problems at a stroke.
• Segregate by data classification. Group public tools for public data; explicitly control and isolate the tools that touch regulated or sensitive data. Don't let the weather tool and the health-records tool share a trust zone.
• Scope permissions tightly, and re-consent on change. Narrow OAuth scopes to the specific repositories, tables, or operations actually needed, and treat a change in a connected server's capabilities as requiring fresh approval, not silent acceptance.
• Validate parameters in context. Not merely type-checking inputs, but understanding what the execution environment will do with them — so a manipulated context parameter can't turn a maths tool into a file-write primitive.
• Own the token lifecycle. Short expiry, rotation, revocation, replay protection — because the protocol won't mandate them for you.
• Verify tool origin; pin resolution. Don't let dynamic tool discovery load code without origin verification, and pin tool identifiers so a naming collision can't hijack execution.
• Filter egress. A filtering outgoing proxy or enterprise DLP on connections leaving the MCP environment, with allowed resource URLs pinned, catches exfiltration that code-level controls miss.
• Log for incident response. Capture a traceable sequence of actions across sessions — enough to reconstruct what happened, detect anomalies, and answer to an auditor.

The shape of a secure MCP integration

Put together, the secure pattern isn't subtle: a tightly-scoped MCP server, running inside the client's own environment rather than a vendor's, segregated by data sensitivity, with authentication and RBAC supplied where the protocol leaves a gap, parameters validated in context, tokens with a real lifecycle, egress filtered, and everything logged. That is, more or less, the architecture a federal security agency now recommends — and it is the opposite of the quickest way to stand an MCP server up.

It is also hardening into a baseline expectation rather than a nicety: US federal procurement is already beginning to tie MCP deployments to these controls, and regulated sectors elsewhere tend to follow that lead.

That gap — between the demo you can build in an afternoon and the deployment a regulated business can actually run — is the entire job. It is also why "we'll host it for you" is the wrong answer for sensitive data: the secure pattern keeps the server, and the data, inside your boundary. The right role for an integration partner is to build and maintain it there, with scoped, revocable access — not to take custody of it.

At Vitnis that is the only way we build MCP integrations: in your environment, scoped to the minimum, secure by design, handed over clean. If you are putting MCP in front of anything that matters, the NSA's guidance is worth your CTO's afternoon — and building to it from the start is far cheaper than retrofitting it after an incident.