The MCP Supply Chain You Forgot to Govern

The Model Context Protocol has become the default interface between AI agents and the systems they act on. By 2026 the ecosystem reported more than 150 million SDK downloads and a public registry of over 10,000 servers before Anthropic donated the protocol to the Agentic AI Foundation under the Linux Foundation. ¹ Every prior paper in the KellerAI catalog locates the governance problem inside a team's own artifacts. This paper locates it outside the team's control: a protocol-level default that propagates a privilege-escalation surface through every server an operator installs from a public registry, no matter how disciplined that operator's internal practices are.

The forcing event was an April 2026 OX Security disclosure titled “The Mother of All AI Supply Chains,” which reported more than ten High- and Critical-severity findings and demonstrated that a design behavior present across all four official MCP SDKs allowed a server to execute arbitrary commands on the agent host. ² Anthropic declined to patch the behavior, characterizing it as expected. ³ That response is the crux of this paper. A behavior the maintainer considers correct is not closed by a future release; it is a property of the trust model, and a property of the trust model can only be managed by governance.

This paper proceeds in three movements. First, it establishes what the protocol does and what its reference SDKs do silently, grounded in the specific CVEs of early 2026. Second, it quantifies the exposure across the registry population and shows that “a major-lab standard” is not a substitute for due diligence: most servers use static keys, most registries accept unsigned submissions, and provenance is the exception rather than the rule. Third, it diagnoses three governance failures — in the trust model, in authentication, and in provenance — and proposes a three-practice posture: a policy-enforcing gateway, per-server provenance attestation, and reservation-before-invocation credentialing. A regulatory overlay and an explicit Honest Limits section close the argument.

For the leadership-level version of this argument — the load-bearing claim, the worked incidents, and the three-line checklist — read the companion brief, The MCP Supply Chain You Forgot to Govern . ²⁵

MCP defines how an agent host discovers and invokes tools exposed by a server. The most common transport for local servers is standard input and output — STDIO — and this is where the silent behavior lives. In the reference implementations, a server is launched by the host as an operating-system subprocess from a command string supplied in the client configuration. The official Python SDK's StdioServerParameters takes a command and its arguments and executes them as a local process; the LangChain MultiServerMCPClient follows the same path. ⁴

In isolation this is unremarkable: it is how any program launches a child process. What changes the calculus is the surrounding context. On a command line, the human who types a command supplies interactive consent for each invocation. In an agentic context, the agent invokes the configured command on its own, without that consent step, and the command string itself may originate from a server the operator installed from a public registry. The trust assumption that holds on a developer's laptop — that the person running the command intends it — does not hold when an autonomous agent runs a command on behalf of a server it did not author. ⁴

The early-2026 CVE record makes the surface concrete. Agent Zero, CVE-2026-30624, exposed an unauthenticated web interface that reached a command-execution path, scored at CVSS 9.6 under CWE-77, command injection — a network-reachable route to arbitrary execution on the host with no credential and no consent. ⁵ It was not alone. CVE-2026-30625 reported a command-injection issue in Upsonic; CVE-2026-40933 reported one in Flowise; and CVE-2026-30623 tracked a stdio command-injection issue in LiteLLM, fixed in a v1.83.6 nightly build. ⁶ These are distinct products, but they share a shape: a tool-execution surface, reachable by an attacker, that the protocol's design treats as a feature.

The propagation geometry is what makes a single-server flaw a fleet problem. An agent host typically connects to several servers at once, and the host's permissions are the union of what every connected server can reach. A server that gains execution on the host inherits the host's lateral reach — its filesystem, its network position, its other connected servers and their credentials. The blast radius of one compromised server is not the server; it is the host and everything the host can touch.

The exposure is large because the adoption is large. The OX analysis estimated up to roughly two hundred thousand potentially affected instances across the protocol's 150-million-download base, and ran demonstration commands on six live platforms during its research. ² We treat the two-hundred-thousand figure as an upper-bound estimate, not a count of directly exploitable hosts — a caution we return to in Honest Limits.

The registry population grew through 2026 from roughly three thousand servers in March to more than seven thousand public servers later in the year. ⁷ A study of more than five thousand two hundred public servers in March 2026 found that only 8.5% used OAuth, with 53% relying on static API keys — frequently unscoped. ⁸ We note the date deliberately: this measurement predates the OX disclosure, so it describes the population's posture before the industry's attention turned to the problem.

Direct exposure to the open internet compounds the registry posture. In January 2026, researchers reported more than forty-two thousand OpenClaw instances reachable on the public internet, a population of agent infrastructure exposed before any server-specific flaw is even considered. ⁹ And the organizational picture suggests the control point is thin: industry reporting found that 43% of organizations had a centralized AI data gateway, leaving a majority routing agent traffic without the single chokepoint a governed posture depends on. ¹⁰

The scale matters for one reason in particular. A vulnerability that requires a bespoke exploit per target is a slow problem. A behavior that is uniform across all four reference SDKs, present by default, and installed by a population numbering in the tens of thousands of servers is a fast one. The uniformity is the multiplier.

The protocol-level execution surface is one half of the picture. The other half is the distribution channel that delivers servers to operators, and it has already been attacked in three distinct ways.

The first known malicious MCP server appeared in September 2025: an npm package named postmark-mcp that shipped fifteen clean versions before version 1.0.16 added a silent BCC header, exfiltrating every email the server processed. ¹¹ The pattern is the classic supply-chain trust spend: an attacker builds legitimacy across many releases and cashes it in a single update that an operator, having vetted the package once, is unlikely to re-review.

The second is the LiteLLM PyPI compromise of March 2026. LiteLLM, a credential-proxying layer with roughly ninety-five million downloads a month, had its package distribution compromised, turning a heavily trusted dependency into a credential-exfiltration vector. ¹² This vector must not be conflated with the protocol flaw. It is a maintainer-credential compromise one layer below MCP — a conventional package supply-chain attack — and we frame it as related but distinct. Its relevance here is that the same agent fleet is exposed to both the protocol execution surface and the package distribution channel simultaneously, and a governance posture must cover both.

The third is the registry itself. A researcher who submitted a deliberately malicious proof-of-concept server to eleven public MCP registries found that nine accepted it, with no signing, software bill of materials, or provenance check standing between the submission and a live listing. ¹³ OWASP now codifies this class of risk directly: LLM03:2025, Supply Chain, names third-party model and tool components as a top risk for LLM applications. ¹⁴

One vector deserves special attention because it is unique to the agentic setting: the tool description as an injection surface. An MCP server advertises its tools with natural-language descriptions that the agent reads to decide when and how to call them. A description crafted to manipulate the agent — instructing it to exfiltrate context, call another tool, or ignore a guardrail — is an injection that never touches a parameter value and never trips an input validator, because the payload lives in the metadata the agent trusts by design. ¹⁵ Tool-description injection is the supply-chain attack adapted to the fact that an agent reads its tools' advertising and acts on it.

A serious counter-argument deserves a serious hearing, and this one improves the paper. Shortly after the OX disclosure, one analyst argued that the findings describe the same old command-line problem rather than a protocol flaw. STDIO executes commands by design; therefore the flaw, if any, lives in applications that pass untrusted input into an execution path, not in the protocol that defines the path. The analyst's analogy was blunt: “SQL injection isn't a flaw in SQL.” ¹⁶

We concede the technical point in full. STDIO does what it is designed to do; a server that executes a supplied command is behaving according to specification; and an operator who pipes untrusted input into a subprocess has made the error, in the narrow sense that the protocol did not force the mistake. Anthropic's characterization of the behavior as expected is, at the level of the specification, accurate. ³

The governance argument survives the concession, and it survives on three grounds. First, the protocol was positioned as a universal standard for connecting agents to the world, marketed for broad adoption rather than presented as a low-level primitive for experts who would supply their own sandboxing. Second, the reference SDKs — the implementations most operators copy — ship the execution path as the default, so the “application error” is the path of least resistance the standard itself lays down. Third, declining to act transferred the security burden to operators silently: there was no coordinated guidance, no default hardening, no announcement that adopting the standard left a privileged execution surface for the operator to govern.

The most telling detail is that the dissent's own recommendation is a gateway with policy enforcement. ¹⁶ The analyst and this paper disagree on whether to call the surface a protocol flaw or an application error, and agree completely on the remedy. When the technical skeptic and the governance advocate arrive at the same control, the control is the conclusion the disagreement was always pointing at.

If the exposure is not a bug, it is worth naming precisely what failed. Three governance failures compound, and each maps to a remedy in the next section.

6.1 The trust-model failure. The specification transfers trust downstream without making the transfer explicit. An operator who adopts the standard inherits the assumption that a connected server is benign, because nothing in the default flow forces a decision about whether to trust it. The protocol's own roadmap acknowledges the gap obliquely: items such as auditing and single-sign-on integration appear as future work rather than shipped guarantees, which is to say the governance primitives are known to be missing. ¹⁷ A trust model that defers its trust decisions to an operator who was never told a decision was required is a trust model that has failed silently.

6.2 The authentication gap. The registry data quantifies the second failure. As of March 2026, only 8.5% of surveyed servers used OAuth; the majority required static credentials, with 53% relying on static API keys that were frequently unscoped. ⁸ A static, unscoped key is the antithesis of least privilege: it grants whatever the key can reach, for as long as the key lives, to whatever holds it. When the holder is a server you installed from a registry that accepts unsigned submissions, the standing grant is the attack surface.

6.3 The provenance void. The third failure is the absence of required provenance. There is, for the bulk of the ecosystem, no mandated code signing, no software bill of materials, and no SLSA attestation gating a server's distribution. The exception proves the rule: the GitHub MCP server publishes SLSA provenance attestations, and it is notable precisely because it is unusual. ¹⁸ When provenance is opt-in and rare, an operator cannot distinguish a server whose build is verifiable from one whose is not — and the nine-of-eleven registries that accepted a malicious proof of concept demonstrate that the registry layer will not make the distinction for them. ¹³

Each of the three failures has a remedy, and the three remedies compose into a single posture. None of the practices is novel; each is the standard discipline applied to any privileged API. The contribution is deciding to apply them to MCP, which the protocol's framing as a developer convenience discouraged.

1. 01Policy-enforced gateway. Route every MCP invocation through a single gateway that evaluates the call against policy before it reaches a server, and forbid users and agents from configuring servers directly. The gateway is the chokepoint where a tool call is permitted, denied, or logged — the one control that closes a trust-model gap a patch cannot, because it makes the trust decision the protocol omitted into an explicit, enforced step.
2. 02Per-server provenance attestation. 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. Extend signing and SLSA/Sigstore-style attestation to the servers you run, and align the practice with established supply-chain guidance such as NIST SP 800-161 cyber supply-chain risk management.
3. 03Reservation-before-invocation credentialing. Replace standing static keys with scoped, per-invocation credentials issued at call time. The agent requests access, the gateway grants a narrow scope for that invocation, the server never holds a broad standing grant, and every call carries the identity that made it — so least privilege and attribution hold together rather than trading off against each other.

The gateway practice is where the dissent and the disclosure converge. A policy-enforcing gateway that evaluates every invocation is the control the technical skeptic recommends and the control the governance argument demands; maturity models for MCP deployment now treat the gateway as the central enforcement point rather than an optional add-on. ¹⁶²⁶ The provenance practice maps the broader supply-chain literature onto MCP servers specifically: vet, pin, and verify, with attestation where it exists, under a recognized cyber supply-chain risk-management frame. ¹⁹ And the credentialing practice closes the authentication gap by replacing the standing key with a narrow, attributable grant issued at the moment of use. ⁸

This posture is consistent with arguments KellerAI has made elsewhere in the catalog. The discipline of routing every tool call through an evaluated chokepoint is the same discipline that governs tool-call contracts and tool-call observability in the broader series; the per-invocation credential is the agentic analogue of the reserve-before-you-act pattern. The MCP supply chain is not a new governance problem — it is the tool-call governance problem arriving at the layer where the agent reaches outside its own process.

A regulated team does not need MCP to be named in a statute to be obligated to govern it. The framing throughout this section is deliberate: these obligations apply to systems that use MCP, not to MCP as a regulated object. The protocol is unregulated; the production system that connects an agent to a public server through it is not. We keep this section inferential and short, and we flag the mappings as obligations to verify against current text rather than settled determinations.

The NIST AI Risk Management Framework's Manage function asks an organization to manage risks from third-party components, which is what an installed MCP server is. A governed gateway, a provenance regime, and per-invocation credentials are the operational content of that management function for the MCP layer. ²⁰ For systems in scope of the EU AI Act, the post-market monitoring and risk-management obligations in Articles 72 and 9 bear on a system that incorporates a third-party execution surface; the obligation is to maintain control over the system's behavior in operation, which an ungoverned MCP connection undermines. ²¹

Under SOC 2, the Common Criteria for logical access — CC6.6, which addresses controls over access from outside the system boundary — speaks directly to a server that reaches into a host from beyond the trust boundary; an unscoped standing key granted to such a server is the kind of access the criterion expects to be controlled. ²² And under HIPAA, the Security Rule's access-control standard at 45 CFR 164.312(a)(1) governs any path by which protected health information could flow to or from a model through a tool call, making an MCP-connected agent that touches PHI a system inside the safeguard obligations. ²³ In each case the obligation is the same in substance: control, attribute, and monitor the third-party access that an MCP connection introduces.

A paper that argued for governance while overclaiming its evidence would fail its own discipline. Here is what this paper does not establish.

The two-hundred-thousand affected-instance figure is an OX Security estimate, not a verified count of directly exploitable hosts. At least one analysis cautioned explicitly against reading it as a count of instances an attacker could exploit without further conditions. ^{2 24} We use it as an upper-bound indicator of scale, and we are explicit that the governance argument does not depend on the number: whether the figure is two hundred thousand or a fraction of it, the remedy is the same, because the remedy is keyed to the trust model rather than to the incident count.

No STDIO patch is planned, and that is the paper's premise rather than a gap to be closed by waiting. Anthropic characterized the behavior as expected and declined to change it. ³ The donation of the protocol to the Agentic AI Foundation under the Linux Foundation establishes a stewardship body, but it does not, as of this writing, establish a mandatory certification program for servers or a required provenance regime. ¹ The governance primitives on the protocol roadmap — auditing, single-sign-on integration — are listed as future work, not shipped guarantees, and we have not assumed they exist. ¹⁷

The dissenting view's technical point is accurate, and we have not rebutted it on technical grounds. STDIO executes by design; a server that runs a supplied command is behaving to specification; the failure, in the narrow technical sense, is in applications that pass untrusted input. ¹⁶ Our claim is explicitly governance-level: that positioning a standard for broad adoption, shipping the execution path as the SDK default, and declining to harden or announce it transferred a burden silently. A reader who rejects the framing of “protocol flaw” can still accept every operational recommendation in Section 7.

The regulatory mappings in Section 8 are inferential. We have framed each as “obligations that apply to systems using MCP,” not as determinations that any specific framework names MCP or that any specific deployment is in scope. Whether the EU AI Act's Article 9 risk-management duties, SOC 2's CC6.6 versus CC6.7 boundary, or a given NIST SP 800-161 revision applies to a particular system is a fact-specific question that requires verification against current text and the system's own classification — not a conclusion this paper can draw on a reader's behalf. ^{20 22}

Finally, the LiteLLM PyPI compromise is a maintainer-credential supply-chain attack one layer below the protocol, not a STDIO exploit, and we have framed it as a related-but-distinct vector throughout. We name no vendor as the remedy: the recommendations describe the gateway pattern, the provenance pattern, and the credentialing pattern, not a product. The contribution of this paper is the diagnosis that MCP is a privileged integration that did not announce it was one — and the claim that the posture you would apply to any such integration is the posture it requires.

For the short, leadership-level version of this argument — the load-bearing claim, the two worked incidents, and the Gate / Verify / Attribute checklist — read the companion brief, The MCP Supply Chain You Forgot to Govern .