The MCP Supply Chain You Forgot to Govern

The Model Context Protocol is now the default way agents reach the outside world. Anthropic introduced it in late 2024, and by 2026 the ecosystem reports more than 150 million SDK downloads and a public registry of over 10,000 servers, before the protocol was donated to the Agentic AI Foundation under the Linux Foundation. Most teams treat installing an MCP server the way they treat adding a package: a convenience, governed by whatever discipline they already apply to dependencies. That treatment is the problem.

In April 2026, OX Security published an analysis it titled “The Mother of All AI Supply Chains,” reporting more than ten High- and Critical-severity findings and demonstrating that a design behavior present across all four official MCP SDKs let a server execute arbitrary commands on the host running the agent. The behavior is the same one you would expect from any program that launches a local subprocess from a command string — but in the MCP context that command string is supplied by a server you installed from a public registry, and the agent invokes it without the interactive consent a command-line user would give.

Anthropic declined to patch the behavior, characterizing it as expected: the protocol does what a tool-execution protocol is designed to do. That response is technically defensible and strategically revealing. It means the exposure is not a bug that a future release closes. It is a property of the trust model, and a property of the trust model can only be managed by governance — by the discipline you wrap around every server you connect, not by a version bump you wait for.

Two incidents from early 2026 make the abstraction concrete, and they fail in different ways on purpose. The first is Agent Zero, CVE-2026-30624: an unauthenticated web interface let an attacker reach a command-execution path with a CVSS score of 9.6 under CWE-77, command injection. This is the MCP execution surface exposed directly — no credential, no consent, a network-reachable path straight to the host. It is not the only one: parallel command-injection findings landed in Upsonic (CVE-2026-30625) and Flowise (CVE-2026-40933), and a stdio command-injection issue was fixed in LiteLLM (CVE-2026-30623).

The second is the LiteLLM PyPI compromise of March 2026. LiteLLM is a credential-proxying layer that sees roughly 95 million downloads a month; its package distribution was compromised, turning a trusted dependency into a credential-exfiltration vector. This is a distinct vector and must not be conflated with the protocol flaw — it is a maintainer-credential compromise one layer below MCP, the classic software supply-chain attack. The point of pairing them is precisely that they are different: the execution surface gives an attacker a target, and the package supply chain gives the attacker a delivery mechanism. An agent fleet is exposed to both at once.

The pattern that connects them was first seen in September 2025, when the first known malicious MCP server, an npm package named postmark-mcp, shipped fifteen clean versions before version 1.0.16 added a silent BCC to exfiltrate every email it processed. Trust earned over fifteen releases was spent in one. That is the shape of supply-chain risk, and MCP did not invent it — it only widened the blast radius by wiring it to an agent that acts without asking.

The assumption that does the quiet damage is this: a standard from a major lab arrives secure by default, so adopting it transfers the security work to the lab. The registry data says otherwise. A study of more than five thousand public servers in March 2026 found that only 8.5% used OAuth; the remaining majority relied on static API keys, frequently unscoped. A static, unscoped key in a server you did not write, invoked by an agent that acts on its own, is a standing grant of whatever that key can reach.

Distribution is no safer than authentication. A researcher submitting a deliberately malicious proof-of-concept server to eleven public MCP registries found that nine of them accepted it. There is, for the most part, no required signing, no software bill of materials, and no provenance attestation gating a server's entry into a registry — the GitHub MCP server's SLSA attestation is notable precisely because it is the exception. OWASP now tracks this directly: LLM03:2025, Supply Chain, names third-party model and tool components as a top risk class for LLM applications.

A dissenting reading is worth honoring, because it sharpens the argument rather than weakening it. One analyst argued that the OX findings describe the same old command-line problem — stdio executes commands by design, so the flaw lives in applications that pass untrusted input, not in the protocol; “SQL injection isn't a flaw in SQL.” The technical point is correct, and we concede it. The governance point survives it: the protocol was positioned as a universal standard, its reference SDKs ship the execution path as the default, and declining to act transferred the burden to operators without announcing it. Tellingly, even that dissent's own recommendation is a gateway with policy enforcement — which is to say, governance.

Because the exposure is a property of the trust model, the response is a posture, not a patch. Three practices convert an ungoverned MCP surface into a governed one. None is novel; all are the standard discipline applied to any privileged API. The work is in deciding to apply them to MCP, which most teams have not.

1. 01Gate it. Route every MCP invocation through a policy-enforcing gateway that evaluates the call before it reaches a server. No user or agent configures servers directly; the gateway is the single point where a tool call is permitted, denied, or logged. This is the one control that closes a trust-model gap a patch cannot.
2. 02Verify it. Treat each server as a third-party dependency under a software supply-chain regime: vet it before adoption, pin it to a known version, and verify its provenance with attestation where it exists. A registry that accepts an unsigned proof-of-concept is not a substitute for your own verification step.
3. 03Attribute it. Issue scoped, per-invocation credentials rather than standing static keys, and log every call with the identity that made it. Reservation-before-invocation means the agent requests access, the gateway grants a narrow scope, and the server never holds a broad standing grant — and every action has a name attached.

The companion in-depth paper develops each practice against its evidence base — the registry studies, the CVE record, and the regulatory frameworks that already oblige a regulated team to do this work whether or not it calls the protocol by name. For the gateway architecture, the provenance regime, and the per-invocation credentialing model in full, read the in-depth companion .

An MCP server deserves exactly the same posture you would apply to any privileged API integration: a gate that decides what it may do, a verification step that establishes what it is, and an attribution trail that records what it did. None of that is exotic. The reason it feels novel for MCP is that the protocol arrived framed as a developer convenience rather than as a privileged integration, and that framing let teams skip the posture they would never skip for, say, a third-party service granted shell access.

The exposure scope cited in the OX analysis — up to roughly two hundred thousand potentially affected instances across the 150-million download base — is an estimate, and we treat it as one rather than as a count of directly exploitable hosts. The governance argument does not depend on the precise number. Whether the figure is two hundred thousand or a fraction of it, the response is the same, because the response is keyed to the trust model, not to the incident count.

MCP is not uniquely dangerous. It is a privileged integration that simply did not announce it was one. Govern it like the privileged integration it is, and the supply chain you forgot to govern becomes one you do.