Shadow AI and Unapproved MCP Usage in Enterprises

Shadow AI used to mean an employee pasting a client contract into ChatGPT without asking IT first. That problem is old news at this point, well-documented and, in theory, manageable. What's happening now is employees and their AI tools connecting to unapproved MCP servers, giving language models direct, autonomous access to files, APIs, and internal systems that no security team signed off on. That shift changes what's at stake, and it changes what "governance" even has to mean.

Scope and cost of ungoverned AI use

98% of organizations report unsanctioned AI use happening somewhere inside their walls, and 49% expect a shadow AI incident in the next twelve months (Vectra, 2026); that's the number that should worry anyone who thinks their org has this handled. That's not a fringe problem. That's nearly every company, expecting trouble, and still not stopping it.

The policy gap explains why. Only 37% of organizations have an actual AI governance policy in place (IBM, 2025). A quarter have no active AI policy at all (ISACA, 2026). And when you look for companies that both have a policy and actually audit for unsanctioned use, that overlap is a small fraction of the total. Most companies are flying without instruments here, and they know it.

The incidents are already piling up, and they're getting worse fast. Shadow AI-linked breaches rose from 20% to 43% of all AI-related breaches year over year, based on 602 breached organizations across 17 industries (Ponemon Institute, March 2025 to February 2026). That's more than double in a single year. The average breach involving shadow AI now costs $5.39 million (IBM's Cost of a Data Breach Report). Among the organizations that got breached, 68% had no policy governing AI use at all, and 92% lacked adequate access controls. Insider risk costs, separately, run $19.5 million per organization annually, and 53% of that, about $10.3 million, comes from non-malicious actors: employees not trying to cause harm, just using tools nobody told them not to (DTEX/Ponemon).

Gartner projects shadow AI will be a contributing factor in 40% of enterprise AI failures by 2027. Gartner is not a security vendor making a scare claim, but an analyst firm describing where the industry is headed by default.

None of this comes from malicious insiders plotting data theft. It comes from people under deadline pressure, with no training and no visibility into what's allowed, reaching for whatever tool gets the job done fastest. And all of those numbers above describe shadow AI as it existed before agents could take actions on their own. MCP changes that equation entirely.

MCP and its distinct exposure surface

The Model Context Protocol lets an AI application discover and call outside tools while it's running: file systems, APIs, databases, cloud services. Every MCP server an AI tool connects to becomes a live trust boundary, a door the model can open on its own.

That's a different animal from a rogue SaaS subscription. A rogue SaaS app stores your data somewhere you didn't approve. An unapproved MCP server can read files, call APIs, execute commands, and move data out of the building, and it does this autonomously, at the model's direction, not because an employee clicked "upload." The employee isn't even in the loop for the specific action. That removes the human decision point that data loss prevention tools were built around. And these actions chain: an over-privileged MCP server can go from reading a file, to hitting an external API, to running a shell command, with no explicit approval at any step along the way.

Adoption has run far ahead of anyone's ability to watch it. The public MCP server registry grew from around 1,200 entries in the first quarter of 2025 to over 9,400 by mid-April 2026, more than seven times in fourteen months. Adoption overall grew more than 400% in 2025 (industry estimates).

The protocol itself doesn't help. The MCP spec doesn't require authentication or authorization by default. Only 8.5% of MCP servers currently implement OAuth 2.1, despite it being the protocol's own recommended standard for remote deployments. Plenty of servers instead run on shared bearer tokens or API keys handed out across an entire team, which makes user-level tracking or key rotation basically impossible once you're operating at any scale.

Most organizations don't know where MCP is being used. No inventory of connected servers, no list of authorized tools, no visibility into active clients. And that blindness is already slowing things down: 38% of organizations say security concerns are actively blocking their MCP adoption, and half of MCP builders name access control as their single biggest challenge.

Unapproved MCP servers as shadow infrastructure inside enterprise environments

The behavior pattern is familiar. Employees connect MCP servers to their AI tools whether or not IT approved it, the same instinct that drove personal ChatGPT use a few years back. Except now that connection comes with direct tool-call access into company systems, not just a text box.

One IT lead said: "I don't have visibility on what's being used and I don't have guardrails" (mcpmanager.ai, 2026). Unapproved MCP connections, as one analysis described them, "effectively become shadow infrastructure invisible to security teams but fully capable of accessing enterprise systems" (F5).

Personal accounts make this worse. When someone uses a personal ChatGPT or Claude account, on their own subscription, to pull enterprise data through an MCP connection, that data is in an environment the company has zero compliance control over. Research out of MIT found employees at more than 90% of companies surveyed use personal AI accounts for daily work, while only 40% of organizations provide an official, sanctioned tool. MCP takes that same risky habit and multiplies the blast radius: it's no longer a prompt going to a consumer chatbot. It's an agent with file and API access, operating inside a personal, unmonitored account.

Traditional shadow IT tools weren't built to catch any of this. Cloud access security brokers look for known SaaS destinations, and MCP traffic runs at the API level, often indistinguishable from approved tool traffic once it hits the network. DLP tools watch data at the moment it transfers, but MCP tool calls happen inside the model's context window before anything gets logged as a transfer. There's no equivalent of an approved software list for MCP servers, so security teams have no baseline to check activity against in the first place.

Shared credentials compound all of it. When one API key gets handed to an entire team, every action taken through that key shows up in logs under a single identity. Incident response becomes close to impossible: you can't tell which employee, which session, which agent did what. And a single compromised laptop exposes that same credential for the whole organization.

The attack vectors that operate specifically inside ungoverned MCP deployments

These aren't hypothetical risks dreamed up by security vendors trying to sell something. More than 40 CVEs were catalogued against MCP SDKs and servers between January and April 2026 alone. That's roughly one new vulnerability every four days.

A few of the named ones are worth knowing by name. CVE-2025-49596, with a CVSS score of 9.4, enabled arbitrary command execution through an unauthenticated MCP Inspector, opening the door to unauthorized access (SentinelOne). CVE-2026-33032, nicknamed "MCPwn" and scoring a 9.8, was a missing authentication check in nginx-ui's MCP integration that gave unauthenticated attackers full administrative control of Nginx servers, and it was under active exploitation even after a patch shipped in March 2026. CVE-2026-26118, scoring 8.8, was an SSRF flaw in Microsoft's Azure MCP Server Tools, patched March 10, 2026. CVE-2025-6514, at 9.6, was an OS command injection bug in the widely used mcp-remote package, hitting versions 0.0.5 through 0.1.15.

Beyond the named CVEs, there's tool poisoning: in an ungoverned setup, every tool from every connected server gets exposed to the model with no filtering, so a single poisoned tool description can quietly redirect the agent toward exfiltrating data or taking unauthorized action.

Then there's prompt injection, which is structural, not incidental. Malicious instructions arrive buried inside ordinary content the agent processes, including a support ticket, a web page, or the body of a tool's response. The model can't reliably tell the difference between a legitimate instruction and an injected one, because every piece of text in its context window carries the same weight. Prompt injection attacks aimed at AI agents tripled in 2024 (IBM X-Force, 2025).

Rug pull attacks are their own category: a connected MCP server behaves one way when it's approved, then changes its behavior later, and without central logging, there's no way to piece together what happened after the fact. Cross-system privilege escalation occurs when tool calls chain together without scoping checks in between, and in multi-agent setups, a single compromised agent can escalate its reach across other agents entirely (witness.ai, 2026). Most MCP builds skip least-privilege design altogether, so permissions that should be narrow end up cascading into network access, shell commands, full data exfiltration.

Add to that unverified task propagation, where tasks pass between MCP servers or agent components with no check on where they came from, what scope they should have, or what they're actually meant to do, which the NSA's own guidance flags as a concern for overreach and unintended downstream effects. And supply chain risk closes the loop: connecting to a third-party MCP server means extending trust to code the enterprise never reviewed, and even established, reputable vendors aren't immune to that exposure.

The NSA's May 2026 MCP guidance for enterprises

On May 20, 2026, the NSA's Artificial Intelligence Security Center put out "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation," the first major government-level document to take on MCP security specifically. Its central conclusion is blunt: MCP's adoption has outrun the safeguards needed to run it safely.

The guidance names eight security concerns and offers nine recommendations. A handful matter most for shadow MCP specifically. Uncontrolled automated actions top the list: AI systems using MCP can decide on their own to invoke new tools, and there's no default boundary on that scope. MCP lets data pass between systems without adequate checks, so the prompt injection surface isn't a bug, it's baked into how the protocol works. Session identity is another: session identity gaps mean activity cannot reliably be mapped back to an individual user, which is exactly the shared-credential gap described earlier, now addressed at the federal level by a government security agency. And the guidance flags susceptibility to overload and denial-of-service attacks as a real, not theoretical, concern.

The NSA's key recommendation on logging is direct: every action an MCP tool takes should be logged in detail, including what tool was called, by whom, and what happened as a result, and those logs need to feed into existing security monitoring systems.

What matters most here is not the specific recommendations. A government security agency is now confirming what practitioners have been saying: ungoverned MCP is a systemic identity and auditability failure, not a minor configuration risk to clean up later. It's a systemic identity and auditability failure, one that existing SIEM and DLP tooling was never designed to catch. And that creates a real practical bind: an organization that can't even list its own MCP servers today has no way to meet the NSA's logging requirement. The governance gap and the compliance gap are the same gap.

The standard shadow IT playbook's failure to transfer to MCP governance

The instinct is to treat this like every other shadow IT problem before it: build an approved list, block unapproved domains, tell employees to file a ticket before connecting anything new. That approach worked reasonably well for SaaS apps, because SaaS apps sit still. A domain is a domain. You can block it at the firewall and move on.

MCP doesn't sit still. A server that looked safe at approval time can change its own behavior afterward, the rug pull described earlier, and a domain block does nothing against traffic that looks, at the network layer, identical to a tool call your security team already approved. The unit you'd need to control isn't a destination, it's an action: a specific tool, invoked with specific permissions, by a specific identity, at a specific moment. Traditional shadow IT tooling was never built to see at that resolution, because it never needed to. It was built to watch where data goes, not to watch what an autonomous system decides to do with the access it's been given.

That cause produces the real shift, and the questions that follow show it. Shadow SaaS asked one question: is this data going somewhere it shouldn't? Shadow MCP asks a harder one: what is this system doing, on its own, right now, and can anyone tell after the fact who let it? Until enterprises build the identity, logging, and inventory layer the NSA is now describing, that second question stays unanswerable, no matter how many domains get added to the block list.