The case of the Model Context Protocol, commonly known as MCP, has shifted from being a niche discussion among agent developers to a serious industry concern: when a fundamental layer of the new AI ecosystem introduces execution risks, who bears the ultimate responsibility?
Anthropic introduced MCP in November 2024 as an open standard to connect AI models with tools, data sources, and external systems via a common interface. The promise was clear: reduce custom integrations and enable secure bidirectional connections between assistants and enterprise software. Since then, MCP has rapidly expanded among clients, SDKs, marketplaces, and third-party frameworks.
However, this expansion has now brought a deeper controversy. OX Security claims that the issue is not a simple isolated bug but an architectural weakness related to how official implementations allow launching local processes through STDIO. According to their research, this logic has led to over 30 responsible disclosures, more than 10 high or critical CVEs, and a potential exposure that the firm estimates at over 150 million downloads and up to 200,000 servers. These figures come from OX Security’s team, not an independent global audit, but they have been enough to ignite debate.
The problem isn’t just in the code, but in the design
What makes this case particularly uncomfortable is that it doesn’t fit neatly into the typical category of a single vulnerability. According to OX Security, if an implementation allows insecure configurations or user inputs to reach STDIO process creation, commands can be executed even if the MCP server doesn’t start correctly. From this perspective, the failure isn’t just a specific bug, but a design that is too permissive at a critical point.
Anthropic does not seem to fully share this interpretation. Their official MCP specification makes it clear that the protocol cannot impose security principles at the protocol level, and that implementers must build robust consent flows, access controls, and data protections. Their security documentation also emphasizes showing users the exact command to be executed, warning against dangerous patterns, employing sandboxing, and operating with minimal privileges. In other words, the official model shifts much of the security control to the developer and the operational team of the integration.
This creates the main friction. For Anthropic, the behavior can be considered acceptable if the developer misuses a powerful capability. For OX Security, that very capability should never have been exposed so openly in a component meant to become a common infrastructure layer of the agentic ecosystem. Open Security summarized this clash well by describing the controversy as a difference between a “design flaw” and “expected behavior based on a poor design choice.”
When the standard is open, but security isn’t guaranteed by default
In tech circles, this nuance is much more significant than it might seem. MCP isn’t just a specific application or a marginal extension; it has become a compatibility layer aiming to serve as a universal translator between models and tools. When such a component is adopted rapidly, any permissive decision at the outset can amplify through SDKs, adapters, marketplaces, and IDEs.
This cascade effect is one of the case’s most delicate issues. OX Security and several media outlets that have covered their work argue that the impact isn’t limited to the core repository but extends to projects reusing the official SDK logic or building upon it. Examples include LangChain adapters, platforms like LangFlow and Flowise, and local prompt injection scenarios within AI-assisted development environments.
This underscores the need to see the problem as part of the software supply chain, not just a discussion about coding best practices. If an official library or pattern is widely adopted and its insecure use is too easy, security stops depending solely on the final product’s provider. It depends on all involved links in the chain. And the faster the chain grows, the more probable it is that someone will implement it poorly.
The big question: security by default or caution by default?
What’s really at stake here is an engineering philosophy. In a technology aiming to connect models with external systems, should security defaults be strict in all aspects that could imply local execution, or is it enough to document risks and advise caution?
Anthropic appears to prefer the latter approach. Their specifications and security guidelines indicate that while the protocol enables certain capabilities, it cannot enforce all security controls at the protocol level; implementing teams must incorporate consent, isolation, and access controls. Their security documentation also stresses showing users the exact commands to be executed, warning about dangerous patterns, sandboxing, and using least-privilege principles. Essentially, the official model places a significant portion of security responsibility on the developer and integrator.
This is where the core disagreement arises. For Anthropic, such behavior might be acceptable if misused. For OX Security, that capability should never have been exposed so openly in a component meant to serve as an infrastructure building block. Open Security summarized this well as a contrast between “a design failure” and “expected behavior based on a poor design choice.”
When the standard is open but security isn’t built in
This subtlety is crucial in the tech industry. MCP isn’t a particular app or a fringe extension—it’s become a compatibility layer intended to act as a universal translator between models and tools. Rapid adoption of such a layer can lead to permissive designs propagating through SDKs, adapters, marketplaces, and IDE integrations.
The cascading risk is one of the most sensitive points in this case. OX Security and other outlets stress that the impact isn’t confined to the main repo but extends to projects reusing or building on the official SDK’s logic—such as LangChain adapters, LangFlow, Flowise, and local prompt injections in AI-assisted development environments.
This situation frames the issue as a software supply chain concern rather than merely a coding best practices debate. When a widely adopted library or pattern is insecurely used because it’s too easy to do so, security no longer depends solely on the final product provider but relies on every link in the chain. The faster that chain grows, the higher the risk that someone will implement it improperly.
The key question: default secure or default cautious?
The real debate is about engineering philosophy. Should a technology that connects models to external systems be secured by default, especially regarding local execution, or is it sufficient to document risks and leave caution to the developer?
Anthropic leans toward the latter. Their specifications and security guidelines show an approach where the protocol enables capabilities but doesn’t enforce complete security controls—these rest on the implementer. Conversely, OX Security argues that an architectural change at the foundational level would greatly reduce risks, insisting that security measures should be more tightly integrated from the start. Both positions have internal logic, but they differ in cost: the former spreads security responsibilities across many teams, while the latter requires more restrictive defaults from the outset.
For a tech media outlet, this is the most critical aspect of the story. AI isn’t just answering questions anymore: it’s executing actions, launching processes, modifying configurations, and interacting with real systems. When that’s the case, the discussion shifts from purely algorithmic issues to architecture, governance, and operational responsibility.
It’s not an isolated case: the industry is protecting itself legally while moving fast commercially
The MCP episode reflects a broader trend. AI companies promote these systems as new pillars of digital productivity but simultaneously shield their liability with warnings, usage limitations, and shifting risks onto users, businesses, and developers. The controversy surrounding Copilot’s terms of use—highlighted by language discouraging reliance for important decisions—is another recent example of this contradiction.
The paradox is clear: the industry wants AI to become infrastructure, yet it often manages issues as if they were mere product bugs. Infrastructure, however, doesn’t work this way: when a central layer fails or is perceived as insecure by design, the damage propagates beyond the lab into everything that depends on it.
This is why the MCP debate matters immensely. Not because it will single-handedly halt agent adoption, but because it forces the sector to confront a long-delayed question: if AI is to operate on real systems, handle sensitive data, and execute critical tasks, security can’t be left as an afterthought for the integrator. At some point, someone must acknowledge that openness isn’t enough—security needs to be built in by default.
Frequently Asked Questions
What is MCP, and why has it become so important in AI?
MCP is an open standard developed by Anthropic to connect models and assistants with external tools, data, and systems. Its significance has grown because it simplifies integrations and enables agents to interact with real software.
What exactly does OX Security claim about MCP?
They argue that the process-launch logic through STDIO in official implementations can allow arbitrary command execution when combined with insecure configurations or unsanitized inputs. They see this as an architectural issue, not just a bug.
Has Anthropic acknowledged a flaw in the protocol?
Not in the terms OX Security presents. Official documentation indicates that the protocol cannot enforce all security controls and that implementers are responsible for applying consent, isolation, and access controls.
Why does this matter beyond Anthropic?
Because MCP has become a foundational layer used across agents, SDKs, and third-party tools. If a design decision in this layer introduces risk, its impact can spread through frameworks, marketplaces, and IDE integrations that rely on the same pattern.
via: ox.security