A single configuration field, copied verbatim into a shell, is the entire attack surface. MCP's standard input transport accepts a command parameter and executes it as-is; the client, per the specification, spawns the server as a child process. The protocol models 'connecting to a tool server' as 'a parent process spawning a child.' That is not a bug introduced by a careless engineer. It is the deliberate inheritance of the Unix process model, and the trust boundary it assumes is the local user who wrote the configuration file.
When OX Security and JFrog published their analyses of exposed MCP deployments, the number that caught attention was 200,000 instances. The number that actually matters is 7,000 โ the count of publicly reachable servers. One more figure sits between them and confuses the arithmetic: 0.45%, roughly 70 hosts, representing the share of instances running on personal or home machines. Read together without a denominator, these figures blur rather than clarify. The 0.45% describes a sampling proportion; the 7,000 describes an absolute population. The real exposure surface is the larger number, and the home deployment is a subset of it, not a rival statistic.
The architectural comparison is where the argument crystallizes. Anthropic's reference implementation runs stdio by default. Google's Home MCP integration uses server-sent events with OAuth. Home Assistant's community integration implements OAuth 2.0 with PKCE. Each choice traces a different curve on the security-versus-usability spectrum, and each curve is consistent with the commercial logic behind it. Google does not spawn a local process under SSE, so the command injection surface does not exist โ not because Google worked harder on security, but because the transport it chose never creates the condition. The curves bend, but the logic holds firm.
What made this a genuine security controversy rather than a routine vulnerability cycle is the response. Anthropic characterized the behavior as by design, and declined to add protocol-level sanitization. The technical reasoning behind that refusal is sound in a way most critics overlooked. Forcing sanitization at the protocol layer cannot express legitimate invocations such as python -m mcp_server --config /path/x.yaml, and any blacklist deployed at that layer invites an arbitrarily wide bypass surface: quoting, redirection, pipes, environment variable expansion, nested shell invocations. Filtering at the protocol layer manufactures false confidence. The history of shell escaping is a long catalogue of exactly that failure mode.
So the criticism has to relocate. The defensible charge is not that Anthropic declined to filter commands; it is that Anthropic changed nothing in the defaults. There is a broad middle ground between protocol-layer sanitization and doing nothing: restrict stdio server network egress by default, require explicit confirmation on first launch, place the public-exposure warning on the first screen of documentation instead of the tenth. Those measures do not require expressing arbitrary argument vectors. They require only that the default configuration reflect the deployment reality the ecosystem actually faces. Code does not lie, but it does omit.
That omission becomes materially dangerous through a channel that the original design assumed did not exist. CVE-2025-6514 carries a CVSS of 9.6 and an EPSS of 77%, and it does not live in the stdio transport at all. It lives in mcp-remote, the bridge layer that translates a remote URL into a local OAuth proxy. Here the flow runs in exactly the wrong direction: untrusted remote input becomes local command execution. The stdio design presumed the configuration file was written by the person running the client. The bridge layer broke that presumption while inheriting its privileges. Static analysis revealed what human eyes missed โ the vulnerability was never in the transport everyone was arguing about.
The second underweighted variable is tunneling. Tools in the ngrok family push services that should have been bound to localhost directly onto the public internet, and they do so routinely while bypassing the network address translation that household routers provide. This is not an MCP problem in origin; it is a problem with the security defaults of consumer-grade tunnel tooling, and it has existed for years across NAS devices, home automation hubs, and single-board computers. MCP simply became the newest carrier. Still, the composition is unforgiving: a protocol that executes configuration as commands, a bridge that converts remote input into local execution, and a tunnel that removes the last network boundary.
There is a technical detail in the exposure analysis that deserves its own paragraph. The inference engine runs in user space. An agent or lightweight model loader that can write files and reach the network can migrate across devices without ever escalating privileges. Traditional malware required privilege escalation to move laterally; an AI workload does not. This weakens the most widespread defensive intuition in consumer security โ that withholding root is sufficient. Operating system isolation constrains processes; it constrains AI payloads far less, because those payloads need only the permissions an ordinary user already holds. Invariants are the only truth in the void, and the invariant here is that user-space execution is sufficient for replication.
The industry consequence is not that MCP has flaws. It is that MCP pushes the security responsibility for AI agents downward, from enterprise security teams to households with no security capability whatsoever. Enterprises have SIEM, EDR, zero-trust gateways, and a staffed operations center. A household has router address translation and the hope that nothing happens. One hundred fifty million SDK downloads is not one hundred fifty million deployments โ continuous integration pipelines, container layers, and transitive dependency trees all inflate the count โ but even an order of magnitude of correction leaves a very large installed base with no monitoring. Metadata is not just data; it is context, and the context here is a population that cannot see its own exposure.
The supply-chain mechanism deserves precision, because the analogy is usually drawn too loosely. Mirai derived its destructive force from identical devices sharing identical default credentials. An AI worm does not need credentials. It needs only the protocol's legitimate execution channel. That is a categorical difference: no brute force, no password spraying, only delivery of a configuration. Detection based on anomalous behavior fails against this, because the worm is not behaving anomalously โ it is using MCP exactly as documented. Every exploit is a lesson in abstraction.
Here the evidence standard requires restraint. The self-replicating demonstrations published so far are laboratory conditions: homogeneous devices, controlled networks, no vendor firmware hardening. Moving that into the field requires cross-vendor compatibility, persistence mechanisms, command-and-control channels, and detection evasion. Each step carries an engineering threshold. The correct classification is demonstration-grade, not wild-grade, and reports that collapse the distinction are overstating the threat. The more consequential point is quieter and more structural: the Frontier Red Team that warned about AI worms operates inside the same organization whose SDK defaults create the conditions. That internal tension is the most informative organizational signal in the entire disclosure cycle, and nobody wrote it down.
Regulation has not caught up, and the gap is specific rather than general. MCP is a protocol, not a product, so no party bears product liability for its default configuration. The EU AI Act's obligations target general-purpose models and do not reach transport-layer defaults. The Cyber Resilience Act covers connected products but not protocol specifications. This is not a grey area; it is an actual vacuum. Should a single incident involving physical safety โ a lock, a camera, an alarm system โ trace back to an MCP deployment, the legal chain would have to allocate fault across the protocol author, the SDK consumer, the deploying household, and the tunnel provider. There is no precedent for that allocation because the categories do not yet exist.
The competitive reading cuts against the obvious conclusion. Yes, Google holds the safer narrative, and yes, Google also requires payment, restricts availability geographically, and demands Cloud Console configuration โ which means it has voluntarily surrendered the do-it-yourself household market to Home Assistant and the community projects filling that space. Those community integrations, several of which hold direct write access to home configurations and automations, extend capability without accepting responsibility. When they fail, the reputational cost flows back to the parent project. Anthropic's true competitor is not Google Home MCP. It is the custom private integration that developers will return to if protocol adoption becomes friction-heavy. That, not architectural elegance, is why resistance to protocol-layer change is rational.
What should be watched is narrow and testable. Whether Anthropic adds hardening in the layers it actually controls โ SDK defaults, documentation, sample code โ over the next one or two release cycles, which is the only hard indicator of its real position. Whether an OAuth extension enters the formal specification, which would reframe the by-design response as provisional. Whether the major home automation vendors publish a position, which determines the true homogeneous surface for worm propagation. And whether a low-cost defensive baseline emerges that a household can actually execute โ binding servers to localhost, enforcing tokens, disabling inbound reachability at the router โ because the current guidance, while correct, requires users to know they opened a tunnel in the first place. A recommendation that is accurate but unexecutable is a recommendation that transfers risk rather than reducing it.
The block confirms the state, not the intent. The protocol will keep executing exactly what it is told.