Shadow AI and Ungoverned MCP Server Proliferation

Shadow AI used to mean an employee pasting company data into a personal account on a public AI chatbot. The newer, harder problem is shadow MCP: developers connecting AI agents directly to GitHub repos, Slack workspaces, and production databases through servers nobody on the security team has seen. Stopping this without killing developer productivity means giving teams a sanctioned, governed path that's just as fast as the ungoverned one, not a policy that tells them to stop.

MCP became the fastest-growing ungoverned integration layer in the enterprise

The Model Context Protocol launched in late 2024, and within about a year, most major AI coding environments had built it in. That's an entire integration layer expanding across developer tooling at the same time, not one product category adding a feature on its own schedule.

The adoption numbers back this up. Thousands of active public MCP servers existed within that first year, and organizations as large as OpenAI, Google DeepMind, and Microsoft had all incorporated the standard into their own tools. Part of what made this possible is how little it takes to stand one up. Connecting an AI agent to a company's GitHub, Slack, or production database through MCP takes about three minutes: pull a server from a public registry, write a few lines of config, done. No procurement process. No security review. No IT ticket.

Compare that to how long it used to take to onboard a new SaaS tool, with its vendor assessment, its data processing agreement, its access review. MCP collapsed that timeline from weeks to minutes, and none of the governance processes built for the old timeline were built to catch something moving this fast. The integration layer grew faster than any control built to watch it, and that gap is the subject of everything that follows.

Shadow MCP servers versus shadow SaaS

Shadow SaaS is a known problem: an employee signs up for a tool the company never approved, and company data ends up somewhere IT can't see [1][2]. A shadow MCP server does something different. It doesn't just move data outside the perimeter. It gives an AI agent the ability to act inside production systems, through connections the perimeter already trusts.

That distinction matters more than it might first appear. Shadow SaaS carries a data transfer risk, bounded by whatever that one product can do with the data it receives. A shadow MCP server carries that same data risk, plus something SaaS never introduced: action risk. An agent with ungoverned file system access can read, modify, or delete files. Ungoverned code execution means it can run arbitrary commands. Ungoverned access to an internal API means it can trigger real operations against a live production system. An unapproved SaaS signup is a leak. An unapproved MCP server is a live hand on the controls.

OWASP's MCP Top 10 project gave this pattern a name and a number: MCP09:2025, Shadow MCP Servers. OWASP describes these as unapproved or unsupervised deployments operating outside an organization's formal security governance, often spun up with default credentials, permissive configurations, or unsecured APIs. Earning a numbered slot on a top-ten list is OWASP's way of saying this is common enough to track as a category of its own.

The deeper problem is where these connections run. MCP tools talk to corporate resources through API gateways and service endpoints that network firewalls already trust. Perimeter defenses exist to block bad traffic coming in or sensitive data going out, but they aren't built to question traffic moving through a channel they already approved. A misconfigured or compromised AI agent operating inside that channel doesn't look like an intrusion to the firewall. It looks like business as usual.

Agent autonomy makes this worse. An agent that discovers and connects to an unreviewed MCP endpoint on its own doesn't make one risky call, it makes many, automatically, with no human checking any single one of them. The volume of unvetted activity scales with how much the agent decides to do on its own, not with how much a person decided to allow.

How a shadow MCP server gets created: the path of least resistance

Shadow MCP servers are the predictable result of a deployment path with no governance step built into it.

A developer wants an AI agent to reach some internal system, maybe a database, maybe an internal API, and it plays out the same way each time. Standing up an MCP server for that is simple: point an existing open-source server at the right endpoint, or write a thin wrapper around the internal API. That server needs a credential to connect, and the fastest one available is whatever the developer already has on hand: a personal API key, a static token, sometimes a database password typed straight into a config file. The server runs locally over stdio, or on a personal cloud instance somewhere. A client gets pointed at it. The agent works.

That sequence never asks for registration. Nothing asks for a review. Nothing routes through a conversation with the security team. The tooling around MCP simply doesn't ask for a step by default, not because the developer skipped one on purpose.

Obot's MCP Maturity Model gives this a name: Stage 1, Shadow Adoption. It describes hundreds of developers running MCP servers locally, through tools like Cursor, VS Code, and Claude Desktop, before IT even knows the pattern exists, and it treats that as the expected starting condition for any organization adopting MCP, not a rare failure. Security assessments of organizations with 100 or more engineers typically turn up a large number of MCP server configurations on developer machines that IT has no record of, most of them pulling credentials straight from developer environment files.

The same thing that makes legitimate MCP adoption fast, no procurement, no review, a few lines of config, makes shadow adoption exactly as fast. The developer in this story isn't circumventing a control. There was no control in that path to get around.

The absence of a required registration or review step is a design choice, one that teams using governance platforms address directly, by building governance into the deployment path so a sanctioned, registered server is exactly as quick to stand up as an ungoverned one. Taking away the speed advantage of going around security keeps the path of least resistance from leading somewhere bad.

The credential and authentication problem built into most MCP deployments

Shadow adoption produces a specific technical pattern: credentials that are static, long-lived, and broadly scoped. That pattern is, at the same time, the most common authentication setup across enterprise MCP deployments and the hardest one to defend.

The Astrix Security State of MCP Server Security 2025 report found that a large majority of MCP servers requiring credentials rely on long-lived static secrets, things like API keys and personal access tokens, and that more than half of those credential setups fail standard security practices. Static secrets like this sit in plain text in a config file, readable by anyone who can open that file. If a developer's laptop gets compromised, or that config gets committed to a shared repository by accident, the credential is exposed the moment that happens, not after some drawn-out breach process.

Scope is the other problem. A developer setting up an MCP server tends to grant broad permissions, because narrowing permissions takes real effort, and being too restrictive breaks something immediately and obviously. Being too permissive doesn't announce itself. The cost of over-granting stays invisible until something goes wrong.

BlueRock Security's 2026 analysis of a large sample of MCP servers found more than a third were vulnerable to server-side request forgery, a flaw where a server can be tricked into making requests it shouldn't. In one disclosed case, that flaw let an attacker query a cloud provider's metadata service through an MCP tool and pull live IAM credentials straight out of a production system. A broad, static credential sitting in an unreviewed config file is a working entry point, demonstrated in production.

Catching a broad-scoped static secret before it turns into an incident takes real-time visibility: knowing which credentials are in use, by which agents, against which endpoints, as it happens. That's the kind of continuous operational control that centralized MCP governance platforms are built to provide, instead of a security review that only runs after something's already gone wrong.

CVE record and named incidents on exploitability

The pace of vulnerabilities appearing in MCP implementations is visible in active exploitation, not just research papers. It's an active pattern of real exploitation, and the incident record shows the most dangerous flaws are structural.

Start with the STDIO SDK flaw, disclosed by OX Security in April 2026. OX's research, titled "The Mother of All AI Supply Chains," identified a command execution vulnerability in Anthropic's official MCP SDKs for Python, TypeScript, Java, and Rust. The STDIO transport in those SDKs passed incoming configuration parameters directly to the host operating system's shell without sanitizing them first, so any process command would execute on the host regardless of whether it ever initialized a valid MCP server. That flaw left a large population of servers across the ecosystem potentially compromisable, simply by virtue of using the official SDK as intended.

Then there's CVE-2026-33032, a critical vulnerability in nginx-ui's MCP implementation disclosed in March 2026, carrying a CVSS score of 9.8. The message endpoint failed to authenticate command execution requests, letting attackers restart the server, rewrite its configuration, or take over the nginx service completely. A significant number of publicly exposed nginx-ui instances were potentially vulnerable.

Amazon Q had its own issue, patched in June 2026: the tool was found auto-loading MCP configuration files from workspace directories without ever asking for consent, a flaw rated CVSS 8.5.

Cursor's case, tracked as CVE-2025-54136 and nicknamed MCPoison, exposed a different kind of mistake. Cursor's trust model tied approval to an MCP server's name, leaving the server's actual contents unchecked after that initial approval. Once a team member approved a project-level .cursor/mcp.json file, any later edit to that same file was automatically trusted, with no new approval prompt. That let an attacker with write access commit a harmless-looking configuration first, wait for a teammate to approve it, then swap in an arbitrary payload under the same trusted name.

That same gap is visible across the MCP specification more broadly, in what's come to be called the rug pull problem. Nothing in the spec tracks changes to a tool's definition or requires re-approval when one changes. A malicious server can present harmless tools to earn initial approval, then quietly alter those tool definitions in later sessions. The agent keeps transacting with the server as if nothing changed, because nothing in the protocol gives it a way to notice.

Why the governance gap is wider than security teams realize

Every incident above is only visible to an organization that can actually see its own MCP surface, and most organizations can't. That means the real gap between what's exposed and what security teams know about is larger than the CVE record alone would suggest.

Only a minority of organizations feel prepared to secure agentic AI applications, according to data cited in Red Hat's MCP security analysis, so most are running AI agents with tool access nobody is properly monitoring. Fewer than half have any approval process for AI deployments. Only a minority run regular audits looking for unsanctioned AI.

IBM's 2025 Cost of a Data Breach Report placed shadow AI among the top three costliest factors behind a breach, and found that organizations with high levels of shadow AI paid materially more to recover from a breach than organizations with little or none. A significant share of breached organizations had incidents that directly involved shadow AI.

The NSA's guidance from May 2026 names the root of the problem in the protocol itself. "Associating a session to an identity is not defined by the protocol," the guidance states, and MCP "currently lacks support for exchanging Role Based Access Control (RBAC) permissions at instantiation." Even a server built with every good intention, one that wants to authenticate its callers properly, has no protocol-native way to enforce what an authenticated caller is actually allowed to do once it's in.

Regulators and standards bodies respond to ungoverned MCP deployment

The response from regulators and standards bodies has moved past advisory language. It now includes named controls and real compliance deadlines, and that shift changes the calculation for any organization still treating MCP governance as something to get to later.

OWASP's decision to give shadow MCP servers their own numbered entry, MCP09:2025, turns a pattern that used to live in incident postmortems into a defined category that security teams are expected to test for and defend against. The NSA's guidance does something similar from the standards side: by stating directly that the protocol has no built-in way to tie a session to an identity or exchange RBAC permissions at setup, it hands enterprise security teams a specific, named gap to close. Between a named OWASP category and a documented protocol-level gap from the NSA, the question for any enterprise running MCP at scale is which governed deployment path gets adopted before the next ungoverned one does.