More than 4,300 MCP servers are already active across enterprise environments, and roughly 43% of them expose command injection risk, while only about 30% have been remediated after disclosure. That is not a marginal issue sitting at the edges. It reflects a core system layer scaling faster than the controls designed to govern it.
What is actually changing underneath this is how AI systems behave once they are deployed. Models are no longer confined to producing outputs that get reviewed or interpreted later. They trigger actions, interact with tools, and execute against systems outside their own boundary. That shift moves risk directly into execution pathways, where inputs can influence real operations rather than just generated responses.
MCP made that shift easier to implement. It standardized how models connect to external systems, which reduced friction for development teams and accelerated adoption across internal and third-party environments. At the same time, it increased the number of dependencies shaping system behavior, often without a clear record of how those dependencies interact under different conditions.
Enterprise AI systems are moving toward architectures where governance is defined by the full system, not just the model at the center. MCP reflects that shift directly, acting as the layer where execution, dependencies, and trust intersect. This analysis shows where pressure begins to surface once that structure is scaled in production.
Key Findings
Around 43% of MCP servers show exposure to command injection, with remediation reaching only about 30% within observed disclosure and patch cycles
More than 4,300 active servers expand the operational surface area across both internal systems and third-party environments
Session tokens appear in URL parameters in several implementations, introducing exposure through logs, proxies, and intermediary systems
Protocol design leaves room for inconsistency, particularly around authentication enforcement and message integrity handling
Transport methods shape risk differently, with local execution paths introducing dependency exposure and network-based communication opening additional interception vectors
Third-party MCP servers introduce dependency risk through updates, configuration changes, and token management practices that sit outside enterprise control
Multi-agent environments allow one compromised server to influence another through chained execution, creating cascade effects across systems
Agentic AI Request Forgery (AARF) allows instructions to propagate across trusted workflow steps, influencing downstream actions without direct user intent
What the Report Covers
The report goes beyond describing MCP as a protocol and focuses on how it behaves once it is used in real systems. It starts by examining how execution is actually carried out, showing that MCP servers do not just return data but can run commands, access files, and interact with external services. In that context, command injection becomes more than a standard vulnerability. An attacker can influence how a tool interprets input, which can then trigger unintended execution paths that extend beyond a single system boundary.
One of the more important areas the report highlights is how these risks compound in multi-agent environments. When multiple MCP servers are chained together inside a workflow, the output of one server becomes the input of another. A compromised server does not stay isolated. It can influence downstream behavior, creating a cascade where one manipulated step alters how the entire system responds. As Zenity researchers have observed, the risk does not stay contained within a single server but can move across workflows through trust relationships that were not originally designed for adversarial conditions.
The report also looks closely at token handling practices, particularly where session tokens are passed through URL parameters. That design choice introduces quiet exposure, because those tokens can be logged, cached, or intercepted by intermediary systems without direct visibility from the team operating the environment. The issue is not just access control, it is the number of places where sensitive information can persist once it leaves the initial request.
Another part of the analysis focuses on why remediation rates remain low despite clear vulnerability disclosure. A large portion of MCP servers are built and maintained by third parties, which means enterprises using them do not control how quickly fixes are applied. There is also no consistent disclosure or patching process across the ecosystem, which leaves organizations dependent on external timelines while still carrying the operational risk internally.
Across these sections, the report builds a picture of MCP as a system layer where execution, dependency management, and trust relationships intersect. It does not treat these issues as isolated vulnerabilities. It shows how they emerge from the way the system is structured and how it is used in practice.
Our Take
AI Security Take
MCP shifts responsibility into places that are harder to see and even harder to control. Once execution is distributed across servers, tools, and external services, the question is no longer whether the model behaves correctly. It becomes whether the system it relies on behaves in a way that can be trusted under changing conditions.
This maps directly to the GOVERN function in the NIST AI RMF, which emphasizes accountability across system components, including third-party dependencies. It also connects to Article 9 of the EU AI Act, where organizations are required to maintain continuous risk management for systems that can influence real-world outcomes. MCP sits inside both of those expectations because it connects decision logic to execution.
Where this becomes operational is in how drift actually appears. A server updates without notice, a token handling pattern changes, a new dependency is introduced through a tool integration. None of these changes are necessarily visible at the model level, though they alter how the system behaves. Over time, that creates a gap between how the system is expected to operate and what it actually does.
A practical step that holds up across environments is to inventory every MCP server connected to production systems, starting with third-party servers where implementation and patching are outside direct control. From there, teams can begin to layer approval processes, authentication requirements, and monitoring in a way that reflects how these systems actually operate.
For teams looking to move from awareness into structured control, the GAIG Marketplace provides a view into platforms that are building around these exact challenges, helping enterprises evaluate how to govern, monitor, and secure MCP-driven environments as they continue to scale.
