Dora NodaThe NSA doesn't usually publish design guidance for a developer chat plugin. On May 20, 2026, its Artificial Intelligence Security Center did exactly that — a Cybersecurity Information Sheet aimed squarely at the Model Context Protocol, the thing your coding agent uses to call tools. That alone is a signal worth sitting with: an agency that writes guidance for nation-state-grade systems looked at MCP and decided it needed the same treatment.
The CSI doesn't read like a vulnerability disclosure. It names four structural risks baked into how MCP is shaped — not bugs a patch fixes, but consequences of the protocol's own design. And if you've been following MCP security news at all in 2026, you've already met concrete instances of every one of them: a Sentry DSN that hijacked coding agents 85% of the time, a Semantic Kernel RCE with a 9.9 CVSS score, an SDK flaw that turned 200,000 servers into potential shells. The NSA's document is the framework that explains why those kept happening — and what a self-hosted platform whose MCP server holds real deploy and rollback authority needs to check against it before the next one does.
What the NSA actually published
The CSI is titled "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation," published by NSA's AI Security Center (AISC) on May 20, 2026. It isn't a CVE advisory. It's a design-level threat model — the kind of document written for people architecting systems, not patching them after the fact.
The document names four systemic properties of MCP that create risk independent of any single implementation:
- Inverted client-server pattern — MCP servers don't just answer requests, they can initiate actions and shape what the client does next.
- Unverified task propagation — a task's authority and scope don't automatically get re-checked as it hops between tools or agents.
- Trust boundary ambiguity — tool descriptions, metadata, and outputs get treated as trusted context an agent reasons over, with no clear line between "instructions from my operator" and "text a remote server sent me."
- Session-replay and serialization risk — long-lived session tokens and loosely validated serialized payloads create replay and injection surface at the transport layer.
None of these are exotic. What makes the CSI worth reading closely is that each one already has a real, dated 2026 incident behind it — which means this isn't a hypothetical threat model. It's a retrospective one.
The four risks, mapped to what already happened
Inverted client-server pattern
Ordinary client-server systems have a clean trust direction: the client asks, the server answers, and the server doesn't get to unilaterally decide what the client does next. MCP breaks that. A server can hand back content that shapes the calling agent's next action — a tool description, an error message, a piece of returned data — and the agent treats it as input to reason over, not just a payload to display.
This is exactly the mechanism behind "agentjacking," the attack Tenet Security's Threat Labs disclosed in June 2026: researchers hijacked Claude Code, Cursor, and Codex 85% of the time using nothing but a public Sentry DSN, because the error-reporting server's response became something the agent acted on rather than just logged. No breach, no credential theft — just a server-initiated instruction riding in on data the agent already trusted.
What it means for a deploy/rollback MCP server: anything a tool call returns — a build log, a health-check response, a deploy status message — is untrusted input the moment it re-enters the agent's context. If your MCP server's own tool outputs (or a tenant app's logs, surfaced back through a tool) can contain attacker-controlled text, that text can direct the agent's next tool call unless you strip or quote it before it goes back into context.
Unverified task propagation
A task that starts with one agent's authority doesn't automatically shrink or get re-verified as it's handed to the next tool or sub-agent in a chain. The CSI's concern is specifically about overreach: a task scoped to "read the deploy log" propagating into "restart the service" three hops later, with nothing in between checking whether that widened scope was ever actually authorized.
The clearest 2026 instance isn't a single CVE — it's the shape of the broader MCP supply-chain exposure OX Security disclosed in May 2026: a flaw rippling across Python, TypeScript, Java, and Rust implementations, touching a supply chain with more than 150 million downloads and an estimated 200,000 vulnerable server instances. At that scale, "which task, with which scope, reached which tool" stops being something a human can audit after the fact unless the platform logged it structurally from the start.
What it means for a deploy/rollback MCP server: scope has to be checked at every hop, not just at session start. A deploy tool call that triggers a follow-up notify or rollback call needs its own authorization check — not an inherited assumption that because the first call was allowed, everything downstream is too.
Trust boundary ambiguity
This is the one that turns a prompt into code execution. MCP tool descriptions and metadata are supposed to be documentation for the agent — but they're delivered as data, indistinguishable in kind from a user's actual instructions once they're in context. An agent has no structural way to tell "the operator told me to do this" from "a tool's description told me to do this."
Microsoft's own security team demonstrated exactly this failure mode disclosing two Semantic Kernel CVEs on May 7, 2026 — CVE-2026-26030 (CVSS 9.8) and CVE-2026-25592 (CVSS 9.9–10.0). In both, an internal method got exposed to the model as a callable tool, and a model-controlled argument reached a dangerous operation with nothing in between to check whether the model should have been allowed to supply that argument at all. The trust boundary the NSA is naming abstractly is the exact seam both CVEs sat on.
What it means for a deploy/rollback MCP server: every argument an agent supplies to a tool call needs validation against a schema and an authorization check for that specific action — not just "is this well-formed JSON," but "is this agent, in this session, allowed to pass this value to this tool." Tool descriptions should never be treated as safe to interpolate into anything that executes.
Session-replay and serialization risk
MCP sessions can live a long time, and serialized payloads moving through them don't always get re-validated on the way back in. A session token issued once at connection time, then reused across dozens of tool calls over hours, is a wider replay window than a protocol designed around short-lived, per-action credentials would allow. It compounds with the SDK-level RCE disclosed in April 2026, where the STDIO transport passed server-configuration parameters straight to a host shell — more than 7,000 public MCP servers implicated, the same 150 million downloads and 200,000 vulnerable instances OX Security's later disclosure would also cite. A stolen or replayed session token pointed at a server with that class of bug isn't a data leak. It's a shell.
What it means for a deploy/rollback MCP server: session tokens should be short-lived and scoped to a task, not the whole session lifetime. Serialized inputs — anything crossing the transport boundary — need strict schema validation before deserialization, not after. Sandboxing the tool-execution layer itself (Docker's MCP Gateway, for instance, caps every tool call at 1 CPU / 2GB specifically because the SDK-level bug wasn't going to be patched at the protocol layer) is the containment answer for exactly this risk class.
The checklist a deploy-authority MCP server actually needs
Put together, the four risks reduce to four concrete design checks — not a compliance box, a build-time audit:
- Tool outputs re-entering context are untrusted input. Sanitize or structurally separate anything a tool returns before it can influence the agent's next action.
- Authorization is per-hop, not per-session. A multi-step chain (deploy → notify → rollback) re-checks scope at each step, not just at the first.
- Tool arguments get schema validation and an authorization check. "Well-formed" and "allowed" are different questions; MCP servers that only ask the first one are the ones showing up in CVE disclosures.
- Sessions are short-lived and sandboxed. Scope tokens to a task, validate serialized payloads before deserializing them, and run tool execution in a resource-capped sandbox so an RCE in the transport layer doesn't become an RCE on the box running production.
None of this is free. Per-hop authorization checks add latency to every multi-step agent chain, and schema validation on every tool argument is more code to write and maintain than trusting the model's output. The NSA's document isn't arguing those costs away — it's arguing that for a tool server sitting in front of deploy and rollback authority, skipping them is the more expensive choice once you count what a single unverified hop costs when it's wrong.
Why this is worth acting on now, not after an audit flags it
A CSI isn't a mandate. Nothing forces a self-hosted platform to redesign its MCP server against it this quarter. But the pattern connecting agentjacking, the Semantic Kernel CVEs, and the SDK-level RCE isn't a coincidence of timing — it's four instances of the same four structural gaps the NSA just wrote down in one place. Auditors evaluating AI-agent tooling against SOC 2 or similar frameworks are increasingly going to ask about exactly these properties, whether or not "NSA CSI" appears by name in the questionnaire.
For a platform whose whole pitch is that an agent's tool calls execute against infrastructure the operator actually owns — not a vendor's black-box sandbox — that ownership cuts both ways. You don't get to point at someone else's shared responsibility model when a deploy tool's trust boundary turns out to be thinner than it looked. Treating the CSI's four risks as a pre-ship checklist, before a tenant's agent-driven deploy pipeline is the incident instead of the case study, is the cheaper version of this problem to have.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. If you're building an MCP server with real deploy and rollback authority, check out the repo on GitHub and see how the architecture handles agent-tool trust boundaries from the ground up.
