Shadow MCP Usage in the Enterprise

Shadow MCP is a different category of risk than shadow IT, because the thing hidden from security teams can now act on its own, inside production systems, without a human approving each step.

Start with the old problem. An employee stores customer data in an unapproved cloud spreadsheet. With 80% of company employees using shadow IT in some form, this kind of exposure is already common across most organizations. If that spreadsheet gets breached, an attacker reads the data. That is the damage ceiling: exposure, theft, a bad disclosure conversation.

Now take the new one. Say an employee deploys an MCP server, and it gives an AI agent write access to a production database. If that server gets compromised, or the agent misbehaves, an attacker (or the agent itself) can modify records, delete them, or exfiltrate them at machine speed. It happens autonomously, and it happens through connections that look like normal user activity to the authentication system watching them. The damage ceiling here is something acting on production with nobody in the loop.

The mechanism that makes this possible sits inside how MCP is built. MCP runs on a client-server architecture: the server sends tool definitions to the client, which lives inside whatever application is hosting the AI agent (Claude Desktop, Cursor, an internal company assistant). The client forwards those tool definitions to the large language model. The model decides which tool to call and what parameters to call it with. The server then executes that tool call and sends the result back. Every one of those steps, the definition handoff, the model's decision, the execution, the response, is a place where something can go wrong. None of those steps looks like an attack from outside the system. It looks like a tool doing its job.

The scale of what sits on top of that mechanism has grown fast. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, with supporting members including AWS, Google, Microsoft, Bloomberg, and Cloudflare. That move took MCP out of the hands of a single vendor and turned it into shared infrastructure, accelerating enterprise adoption across industries. It also accelerated the rise of unofficial servers standing up with no one from security in the room, as more teams built on MCP.

None of this is an argument against MCP. The protocol does what it was built to do: let agents call tools and act on real systems. Ungoverned MCP gets deployed without visibility or review, and when that happens, it creates an active threat surface, not a passive data-exposure risk, so calling it a scarier shadow IT undersells what's actually at stake.

How fast shadow MCP is spreading inside enterprises

Shadow MCP is already running inside most enterprises, at a scale that outpaces the security processes meant to catch it.

The Gravitee 2026 report surveyed CIOs, CTOs, VPs of Engineering, and Heads of Platform across US and UK enterprises. It found that a large majority of technical teams have already moved past the planning stage and into active testing or production with AI agents. But only a few of those teams can say every agent going live has full security and IT approval. That gap, between what's running and what's been reviewed, is the whole problem in one statistic.

The same study also found that almost half the AI agents surveyed firms have deployed are not watched or secured by anyone. That is a large population of agents with no one watching what they do, each one capable of calling tools against real systems, each one a candidate for going rogue without anyone noticing until something breaks.

Zuplo's analysis of how this happens in practice points to four deployment pathways, and all four route around formal review in a way that makes sense from the perspective of the person doing it:

• Developer productivity shortcuts. A developer spins up a quick local MCP server to connect an AI coding assistant to an internal database. It gets shared with teammates, sometimes with hardcoded credentials baked in, and it keeps running unmonitored because it works and nobody has a reason to touch it.
• Community MCP servers. Open-source servers for popular services like Figma, GitHub, Supabase, and Notion get installed straight from GitHub or npm, with no security audit along the way.
• Department-level deployments. A team lead deploys an MCP server to skip a procurement process that would otherwise take weeks, using shared API keys that never get rotated once they're in place.
• Unofficial implementations from unknown authors. Inside a typical 10,000-member organization, 15% of employees run an average of two MCP servers each, and 38% of those servers come from unofficial, unverified sources.

Each of these paths makes complete sense to the person taking it. None of them pass through a security review. That is how an attack surface grows invisibly inside an organization that believes its AI usage is still at the pilot stage.

What attacks on ungoverned MCP deployments look like

The incidents that have already hit MCP integrations in production share a structure. Legitimate permissions get used for illegitimate ends. Untrusted input gets treated as a trusted instruction. Something gets exfiltrated. None of it requires malware or stolen credentials.

The GitHub MCP incident, disclosed in May 2025, is the clearest version of this. Researchers at Invariant Labs found a critical vulnerability in the official GitHub MCP server, the reference integration that AI agent clients like Claude Desktop use to interact with repositories on a developer's behalf. An attacker hid a prompt injection payload inside an issue on a public repository, and it was just plain text, no exploit code needed. When a developer's agent reviewed that issue as part of its normal work, it followed the instructions hidden inside it: retrieve files from a specified private repository, then post them via a pull request back on the public one. Private repository contents, an employee's relocation plans, and salary data were all pulled out through a single public comment. No credentials were stolen. No zero-day was involved. The agent just did what it was told, by the wrong party.

The Git MCP server exploit chain surfaced in January 2026, this time against Anthropic's own official Git MCP server. Cyata researcher Yarden Porat published three separate CVEs: unrestricted git_init and arbitrary repository creation (CVE-2025-68143), argument injection (CVE-2025-68144), and path traversal allowing a bypass of repository scoping (CVE-2025-68145). Each carried a CVSS score between 6.3 and 6.5. A separate, unrelated flaw in the Microsoft Azure DevOps MCP Server (CVE-2026-32211, CVSS 9.1) surfaced later and is not part of this chain, but it's worth being precise about which vulnerability belongs to which product, since both involve Git tooling and both involve MCP.

The MCP STDIO supply chain vulnerability, disclosed by OX Security in April 2026, is the widest of the three. OX Security described it as "the mother of all AI supply chains." The MCP STDIO transport executes operating system commands without sanitizing or validating them first, which opens the door to remote code execution across Anthropic's MCP implementations in Python, TypeScript, Java, and Rust. That's a vast supply chain, with hundreds of millions of downloads behind it and hundreds of thousands of potentially vulnerable instances still out there.

Security researchers have a name for the pattern connecting all three: a "toxic agent flow." You get individually authorized actions chained together, and when that happens, the outcome is one nobody authorized. Each step in the chain looks clean on its own. A WAF sees normal traffic. A DLP tool sees nothing matching a known pattern. You only see the damage once the whole sequence has already played out.

The formal threat taxonomy enterprises now have to work with

These incidents are not scattered one-offs. They map onto a structured taxonomy security researchers have now formalized, so you can stop treating MCP threats as novel surprises and start treating them as a catalogued category with known attack patterns.

The OWASP MCP Top 10, currently in beta and running from MCP01:2025 through MCP10:2025, tracks risk categories specific to MCP deployments. Its existence marks a shift: shadow MCP has moved from an emerging worry into a structured vulnerability category with its own audit framework, the same status that web application security and API security hold under other OWASP projects. A few of its categories map onto the incidents this article already covered. If malicious instructions get hidden inside tool metadata or definitions at install time, that is tool poisoning, and the LLM follows hidden commands embedded in what looks like a harmless tool description. Tool shadowing, also called tool name collision, is when a malicious server registers tools with names similar to legitimate ones, tricking the model into calling the impersonator instead of the real thing. Command injection happens when unsanitized agent input passes straight through to underlying systems, so an attacker can run OS-level commands, the same mechanism behind the MCP STDIO vulnerability. Shadow MCP servers themselves now carry their own designation in the framework (MCP09:2025), treating the governance gap, unauthorized servers running outside formal review, as a named technical risk category rather than a process footnote.

Two structural conditions make this list dangerous rather than theoretical. The first is privilege drift. Joint research from Oso and Cyera looked across millions of workers and billions of application permissions, and it found that most granted permissions go completely unused over a 90-day window; nearly one in three workers can modify or delete sensitive data they have no operational reason to touch. MCP servers typically inherit those same over-permissioned baselines, or exceed them, because nobody scopes down what the agent can do before turning it loose.

The second is credential handling. Research cited by DataStealth found thousands of API keys and passwords exposed through insecure MCP credential handling, and more than half of MCP servers rely on long-lived static secrets instead of short-lived, rotated credentials. Static secrets are hard to rotate, easy to over-scope at the start, and still valid long after a breach has been discovered elsewhere in the environment. Putting the OWASP categories next to these two conditions reveals a wide-open door, propped open by permissions nobody is tracking and keys nobody is rotating.

Why traditional security tools don't detect shadow MCP activity

Security teams with mature WAF, DLP, SIEM, and IAM deployments might assume those tools already cover this. They do not, because none of them were built to observe or govern a tool-calling agent operating inside a session that already passed authentication.

The structural reason comes down to where MCP traffic sits. As Prophaze documents, that traffic operates within identity boundaries the organization already sanctioned. To the authentication system, the agent is using legitimate credentials to make legitimate-looking API calls, so it reads as normal user activity. The problem lives in the sequence of actions and the intent behind them, which no single request a monitoring tool might flag would reveal.

DLP tools inspect data at rest or in transit, and they look for known patterns. They have no way to recognize that an agent has chained three individually authorized actions into an outcome nobody authorized, because each of those three actions looks clean in isolation.

WAFs inspect HTTP traffic for known attack signatures. JSON-RPC 2.0 traffic carrying MCP tool calls doesn't match those signatures, and the payload that actually causes harm, like a prompt injection buried inside a GitHub issue, arrives in a place a WAF was never built to inspect.

Traditional IAM issues credentials to users and verifies identity at login. It has no native way to track tool-call depth, agent session context, or intent drift once that session is underway. An agent operating under a user's SSO token looks identical to the user, for as long as the session lasts, regardless of what the agent decides to do with it.

An observability gap underlies all of this. Zuplo notes that producing monitoring metrics granular enough to tell MCP-generated traffic apart from ordinary human or machine API calls is a genuine engineering problem on its own. Most organizations don't have the instrumentation to make that distinction at all, in real time or otherwise. Every threat covered so far in this piece is, from the perspective of existing security tooling, invisible by design.

The compliance exposure that shadow MCP creates immediately

Shadow MCP is a compliance liability right now, under obligations that already exist, and not ones still being written.

Unauthorized MCP deployments leave gaps in the audit trail and break data flow mapping, so they conflict directly with rules you already have to follow. GDPR requires organizations to account for how personal data moves and who has access to it. A shadow MCP server that creates an unlogged data bridge between an agent and a production system fails that requirement before it processes a single request, because the data flow was never mapped and the access was never attributed to anyone who could be held accountable for it.

The EU AI Act is the sharpest near-term pressure point. August 2, 2026 is the operative legal date for the Act's transparency rules under Article 50, and for the European AI Office's core enforcement powers over general-purpose AI models. If you violate prohibited AI practices, you can face penalties up to 7% of global annual turnover. The Act's recitals address multi-agent chains directly: in a sequence of AI agents acting together, the compliance boundary extends to every agent in that chain, not just the one a human directly supervised. Nobody approved an unreviewed MCP server sitting inside that chain, but that does not place it outside the law. It sits inside the chain of obligation along with everything else.

So a board has to take shadow MCP seriously, not just leave it on the security team's own priority list. A CISO can explain a vulnerability. A regulator asking for a data flow map that doesn't exist, or an audit trail that was never logged because the server wasn't supposed to exist in the first place, is a different kind of conversation.

Closing that gap takes real-time visibility into MCP activity as it happens, not an audit log reviewed after the fact. Platforms built for this, including Runlayer's AI control plane, work by giving security teams a way to see shadow MCP activity as it emerges and enforce policy at the level of the individual tool call, rather than waiting for a quarterly review to catch what a server has been doing all along. That kind of visibility is what turns MCP governance from a paperwork exercise into something that actually matches the speed at which these servers get deployed.