Shadow AI and Unapproved MCP Usage in Enterprises

In 2012, the shadow IT crisis meant an employee syncing files to a personal Dropbox account. The blast radius of that act was bounded: whatever one person could copy, and wherever they chose to store it, set the outer limit of the damage. Shadow MCP breaks that bound entirely. An unapproved Model Context Protocol server is not a passive leak: it hands an autonomous agent read and write control over internal systems, so compromise becomes an active, machine-speed event instead of a static exposure. Zuplo states the contrast directly: a compromised shadow IT instance lets an attacker read data, while a compromised shadow MCP server hands that attacker a remote control for infrastructure itself.

Shadow MCP as a Categorically Different Problem from Shadow IT

The difference is not a matter of degree. A rogue Dropbox folder just sits there, and it holds only what someone dragged into it, waiting to be found. A rogue MCP server acts. It can query a database, push a commit, call an API, move money, or touch a customer record, all without a human clicking anything in the moment it happens. Shadow IT created exposure. Shadow MCP creates agency, and agency that nobody approved, logged, or reviewed is a fundamentally different category of enterprise risk than a file sitting in the wrong cloud account.

How frictionless MCP deployment makes the governance gap structural, not incidental

MCP was built to remove friction, and it does that job well. You can stand up a server in minutes with lightweight Python or TypeScript SDKs, and if you want to wire it into an AI coding environment, you just edit a configuration file. There is no approval workflow built into that process, no installation log generated, and no record that any of it happened. A developer can spin up a server so an AI coding assistant can query an internal database directly, with no ticket filed and no review requested. A product manager can connect Claude to a customer analytics tool through a community MCP server pulled straight off GitHub, and IT never hears about it. A data scientist can wire a LangChain workflow to call production APIs through an unapproved MCP endpoint, treating it as just another step in a notebook rather than a new piece of production infrastructure. None of these three people are doing anything malicious. They are doing their jobs the fastest way the tooling allows, and that is the point: the gap is not a training problem or a discipline problem, it is a direct consequence of how the protocol was designed to be adopted. Governance has not caught up to that design. Only a minority of enterprises have any AI governance policy in place at all, the Cloud Security Alliance found, and the Gravitee study of 750 CIOs, CTOs, and engineering leaders found that a large majority of technical teams have already moved past planning into active testing or production for AI agents, while only a small fraction report that every agent going live has full security and IT approval. The exposure window that opens as a result is long. Reco AI's 2025 State of Shadow AI Report, cited by the Cloud Security Alliance, found that unauthorized AI tools remain active for a median of more than a year before anyone detects them, so a shadow MCP server stood up today is statistically likely to keep running, undetected, through more than one full business cycle.

Why perimeter defenses don't see MCP traffic at all

Firewalls were not built to recognize this kind of activity, and no exploit is required to slip past them. The blindness is architectural. MCP agents operate at the identity and application layers, issuing API calls that originate from trusted sources and land at trusted destinations over HTTPS on standard ports, which is exactly the traffic pattern perimeter tools are designed to wave through. A firewall inspecting that traffic just sees valid HTTPS moving from a legitimate source IP to a legitimate destination. It has no way to parse the intent behind the API call, and no way to judge whether the specific action the agent just took lines up with enterprise policy. MCP agents reach corporate resources through API gateways and service endpoints that network controls have already marked as trusted, so when a misconfigured or compromised agent works inside those approved channels, perimeter defenses that block traffic by IP address and port number have nothing to flag. The scale of that blind spot is large: the Cloud Security Alliance estimates that a large majority of enterprise AI usage is invisible to security teams, a figure that conventional CASB or single sign-on enforcement cannot close when agents authenticate through service accounts rather than personal logins. What is missing is a way to authorize and verify what an agent is permitted to do, at the moment it tries to do it, rather than relying on where the traffic came from.

The attack vectors that become live once an MCP server is outside governance

Once a server sits outside that kind of authorization boundary, anyone who finds it can use a specific set of threats, and none of them has a direct equivalent in the old shadow IT playbook. Tool poisoning is the clearest example: an attacker plants malicious instructions inside a tool's description or metadata, the model reads and acts on those instructions, and the user never sees any of it happen. In April 2025, Invariant Labs showed this with a poisoned math tool: it silently read SSH keys and exfiltrated them through a function parameter, needed no user interaction, and left no persistent trace. A related risk is the rug pull: a tool approved one week can update its own behavior the next, and because the MCP protocol currently has no mechanism that forces a re-review of updated tools, that change triggers no alert and no re-approval of any kind. Credential aggregation compounds the damage any single breach can do. A server holding credentials for Slack, GitHub, Postgres, and Salesforce all at once becomes a single point of catastrophic failure, where compromising it one time breaches four systems simultaneously. Tool-supplied URLs introduce a fourth vector, turning ordinary MCP tool calls into server-side request forgery: a connector routes a request to an internal endpoint or a cloud metadata service, exposing instance metadata that an agent should never have been able to reach.

The incidents that prove shadow MCP risk is no longer theoretical

By mid-2026, this risk had moved from hypothetical to documented, tracked across named CVEs, confirmed data exfiltration, and a first-of-kind regulatory filing. It widens from there into the software supply chain. Attackers compromised the Nx build system through npm and weaponized victims' own locally installed AI CLI tools, including Claude, Gemini, and Q, as a reconnaissance mechanism baked into the compromised package, showing how a supply-chain attack can co-opt AI tools that were already sitting on a developer's machine. OX Security's disclosure in April 2026 went further still: it exposed a systemic architectural flaw that left a very large number of instances vulnerable across a supply chain spanning hundreds of millions of package downloads, so this is a supply-chain-wide problem, not one team's misconfiguration. The Drift AI chatbot incident showed what credential aggregation looks like once it is exploited at scale: attackers compromised OAuth tokens tied to the Drift integration used by Salesloft and used them to reach the Salesforce environments of hundreds of separate organizations through a single point of entry. The clearest signal of where this is heading came in May 2026, when CB Financial Services filed what appears to be the first SEC Form 8-K triggered by unauthorized employee AI use, not by an external cyberattack, as reported by Wilson Sonsini Goodrich & Rosati and cited separately by the Cloud Security Alliance. That filing establishes something enterprises cannot afford to miss: the sensitivity of the data touched by shadow AI can be enough on its own to trigger a materiality disclosure, with no breach or intrusion required to get there.

Why shadow MCP is fundamentally a non-human identity crisis

The agents doing the acting are not identity-bearing entities in most enterprise identity and access management systems, a structural failure that produces every vector and every incident above. They run on shared API keys, inherited credentials, or delegated user tokens, and no one built any of these with autonomous agent use in mind. That is why these incidents are so hard to detect, attribute, and contain. Non-human identities, meaning service accounts, API keys, OAuth tokens, machine certificates, and agent credentials, already outnumber human users by a wide margin in a typical enterprise, and that ratio grows even more extreme in cloud-native environments. Every shadow MCP deployment adds more untracked credentials on top of an inventory that was already unmanaged before the agent showed up. A Gravitee survey found that only a small fraction of organizations treat AI agents as independent, identity-bearing entities, with most instead relying on shared API keys or inherited credentials, so a single compromised key can authenticate an unlimited number of agents across an unlimited number of systems. The Cloud Security Alliance found that 68% of organizations cannot clearly distinguish AI agent activity from human activity, which makes reconstructing what happened after an incident nearly impossible. Credential hygiene suffers accordingly: each unsanctioned deployment tends to generate its own credentials, stored in developer-controlled environments that sit outside corporate secrets management, never inventoried and never rotated. The window for an attacker to exploit any of this has also shrunk dramatically. The threat timeline has compressed: AI is accelerating attacker exploitation cycles from months to hours, so a credential exposed in a public repository at midnight may be tested against enterprise targets before morning.

The Audit and Observability Gap in Incident Response

If you know a shadow MCP server exists, that does not mean you can reconstruct what it did. MCP servers typically give off so little telemetry that security teams cannot say what an agent did, when it did it, or whether a prompt injection ever fired, so investigation and incident response turn into guesswork. Part of the problem is protocol-level: JSON-RPC 2.0, the traffic format underlying MCP, does not conform to the patterns traditional SIEMs are built to parse, so most teams cannot reconstruct an MCP attack timeline from existing log infrastructure. Without full logs of tool invocations, context changes, and agent-to-agent interactions, there is no way to tell whether a tool description was poisoned before or after it was approved, whether intent drifted partway through a session, or which downstream systems an agent actually touched. The observability gap and the governance gap reinforce each other, because the organizations that run ungoverned MCP servers tend to also have no AI governance policy at all. IBM found that 68% of breached organizations had no policy governing AI use or managing shadow AI, and that organizations without such policies faced substantially higher breach costs and took longer to detect incidents when shadow AI was involved.

The emerging standards and authorization

The NSA's Cybersecurity Information Sheet, issued in May 2026, named the specific risk categories that MCP's design introduces: dynamic tool invocation, where agents call new tools autonomously at runtime, implicit trust relationships between agents, and uncontrolled context sharing. The same agency warned that MCP currently lacks native support for exchanging role-based access control permissions when a tool instance is created, so it is structurally hard to enforce or even verify access boundaries between tasks or services. That gap appears in the vulnerability data as well. The Wallarm 2026 API ThreatStats report documented a large spike in MCP-related vulnerabilities published in 2025, tracing them consistently back to over-permissioned tools, direct API access without adequate authentication or authorization, and the absence of runtime enforcement.