TABLE OF CONTENTS
FEATURED
Shadow MCP: The Unauthorized AI Agent Risk Your Security Team Missed
Mubbashir Mustafa
8 min read
In mid-2025, a vulnerability in MCP server implementations, CVE-2025-6514, scored at CVSS 9.6, compromised over 437,000 developer environments. Separately, an incident at Asana in June 2025 caused customer data to bleed across MCP instances due to insufficient tenant isolation. These weren't hypothetical attack scenarios. They were production incidents in real enterprise environments.
Both incidents shared a common thread: the MCP servers involved had been deployed without the security review, governance controls, or monitoring infrastructure that enterprise systems normally require. They were shadow MCP servers. Deployed by developers who needed agent-to-tool connectivity and built the fastest path to get it.
Shadow MCP is the next wave of shadow IT, and it's already here.
What Shadow MCP Is and How It Happens
Shadow MCP refers to unauthorized MCP server deployments operating outside IT governance. A developer needs an AI agent to access an internal tool. The official process for setting up a governed integration takes weeks (security review, compliance approval, architecture review, production readiness checklist). Building an MCP server takes hours. The developer builds the server, deploys it on a dev instance or a personal cloud account, and connects the agent. The agent works. The security team has no idea the server exists. Learn more
This happens at every enterprise where MCP adoption is growing. The 17,000 unofficial MCP servers in the wild (compared to 5,800 official ones) suggest that ungoverned deployment is not the exception. It's the norm. And within enterprises, the ratio is likely similar: for every MCP server that went through proper review, there are two or three that didn't.
The conditions that create shadow MCP are identical to the conditions that created shadow IT and shadow SaaS.
First, the governance process is too slow for the development pace. When a developer can build an MCP server in four hours but the approval process takes four weeks, the math is obvious. The developer ships the server, gets the agent working, and plans to "do the paperwork later." Later rarely arrives.
Second, the perceived risk is low. MCP servers are simple programs. They feel like utility scripts, not enterprise infrastructure. A developer who would never deploy an unauthorized database sees nothing risky about deploying an MCP server that connects an agent to a Slack workspace or a Jira instance. The fact that this server creates an unaudited data access path through the enterprise's security perimeter isn't immediately obvious.
Third, there's no discovery mechanism. If security teams can't find shadow MCP servers, the servers persist indefinitely. Unlike shadow cloud instances (which show up on cloud bills) or shadow SaaS (which shows up in browser traffic), shadow MCP servers can run on developer laptops, personal cloud accounts, or within existing container infrastructure without creating obvious signals.
Fourth, the ecosystem encourages rapid deployment. Open-source MCP server templates, community libraries, and quickstart guides are optimized for developer speed, not enterprise governance. A developer following a tutorial to build an MCP server for Slack gets a working server in 30 minutes. The tutorial doesn't mention security review, credential management, or audit logging because those aren't concerns for individual developers building personal tools. But when that tutorial-based server lands in a corporate environment connected to production Slack channels, it becomes enterprise infrastructure operating without enterprise controls.
Why Shadow MCP Is Dangerous
The risks of shadow MCP fall into four categories.
Data exposure is the most direct risk. An MCP server connects an AI agent to an enterprise system. The server defines what data the agent can access through that connection. When the server is built without security review, the data access scope is typically too broad. A server built to give an agent read access to Jira tickets might also expose comments, attachments, custom fields with sensitive data, and linked Confluence pages. The developer intended narrow access. The implementation provides wide access. And because the server is unregistered, no one audits the effective permissions.
Credential leakage compounds the data exposure risk. Fifty-three percent of MCP servers use hard-coded credentials. In shadow deployments, this number is likely higher because developers building quickly are less likely to integrate with secret management systems. A hard-coded API token in an MCP server that's been committed to a Git repository (even a private one) is a credential that can be stolen through a compromised developer machine, a misconfigured repository permission, or a CI/CD pipeline leak.
Compliance violations accumulate invisibly. Every shadow MCP server that accesses regulated data (customer PII, financial records, health information) without proper access controls, audit logging, and data handling procedures is a compliance finding waiting to be discovered. The enterprises most at risk are those in regulated industries (financial services, healthcare, government) where the regulatory penalties for unauthorized data access are severe.
Operational blind spots are perhaps the most insidious risk. Shadow MCP servers create agent behaviors that the security and operations teams don't know about. When an incident occurs, the investigation starts with the visible infrastructure. Shadow servers are, by definition, invisible. A data exfiltration investigation might focus on known access paths while the actual exfiltration happened through a shadow MCP server that connected a compromised agent to a production database. Learn more
The risks compound over time. A shadow MCP server deployed six months ago with a specific set of tools might have been updated multiple times since, each update potentially expanding its capabilities and data access without any review. The server's original scope was "let an agent read Jira tickets." Six months later, after incremental changes, it provides read-write access to Jira, Confluence, and Bitbucket with hard-coded admin credentials that have never been rotated. This capability drift is invisible to the security team because the server was never in their inventory to begin with.
Detection Strategies
Detecting shadow MCP is harder than detecting shadow SaaS or shadow cloud, but not impossible. Four approaches provide coverage when used together.
Network discovery identifies MCP protocol traffic on the enterprise network. MCP uses standard HTTP/WebSocket transports, so network-level detection looks for the protocol's characteristic request patterns: capability negotiation, tool schema exchange, and the structured request/response format of MCP tool calls. This catches shadow servers running within the corporate network but misses servers on personal cloud accounts.
Registry audits compare known, approved MCP servers against the servers that agents are actually connecting to. If your agent observability infrastructure captures the MCP server endpoints that agents call, you can identify connections to servers that aren't in your approved registry. Any connection to an unregistered server is a shadow MCP indicator.
Agent permission audits work backward from agent behavior. Review the data access patterns of production agents and identify access paths that don't map to approved integrations. If an agent is returning data from a system that it has no approved MCP server connection to, it's likely using a shadow server. This approach requires agent observability infrastructure that logs tool calls and data sources, but for organizations that have invested in observability, it provides the most accurate detection signal.
Code repository scanning searches for MCP server implementations in your codebase. MCP servers follow recognizable patterns (server initialization, tool registration, handler implementations) that can be detected through static analysis. This catches shadow servers that are version-controlled, even if they haven't been registered or reviewed. Repository scanning should run as a CI/CD pipeline check, flagging any new MCP server code that hasn't been registered in the central registry. This catches shadow servers before they reach deployment rather than after. Learn more
Prevention Through Infrastructure
Detection is necessary but insufficient. The goal is governance infrastructure that makes shadow MCP unnecessary. The approach mirrors the solution to shadow AI broadly: make the governed path faster than the shadow path. Learn more
A central MCP registry should be the single source of truth for all MCP servers in the environment. The registry tracks server metadata, data classification, approval status, credential management details, and dependency mappings. Registering a new server should take minutes, not weeks.
Approval workflows should match risk to review depth. A read-only MCP server accessing non-sensitive data doesn't need the same review as a server that writes to production databases with PII access. Risk-based fast-track approval lets low-risk servers deploy quickly while high-risk servers receive thorough review. This eliminates the uniform bottleneck that drives developers to bypass the process entirely.
Pre-approved templates and patterns reduce the effort of building governed MCP servers. If your platform provides a library of approved MCP server templates for common enterprise tools (Jira, Slack, Salesforce, GitHub, ServiceNow), developers can deploy governed servers in minutes instead of building from scratch. The template includes security defaults, credential management integration, and audit logging. The developer customizes the specific tool configurations. The infrastructure handles everything else. Templates are the most effective anti-shadow-MCP measure because they directly address the root cause: developers build shadow servers because building governed servers is too hard. Templates make the governed path easier than building from scratch, which inverts the incentive structure.
Monitoring should run continuously, comparing the inventory of active MCP servers against the registry and flagging discrepancies. Any unregistered server that appears should trigger an investigation, not an incident. The tone matters: the goal is governance, not punishment. Developers who deployed shadow servers because the governed path was too slow should be guided to the governed path, and that governed path should be made faster based on their feedback. Learn more
The Shadow IT Precedent
The trajectory of shadow MCP is predictable because we've seen it before.
Shadow IT started with developers running servers under their desks. Enterprises responded with policies. Shadow IT grew. Enterprises responded with cloud governance platforms. Shadow IT decreased, because the governed path (cloud infrastructure with self-service provisioning) was faster than the shadow path (personal servers with no support).
Shadow SaaS followed the same arc. Employees adopted unauthorized SaaS tools. Enterprises responded with policies. Shadow SaaS grew. Enterprises responded with SaaS management platforms that offered self-service procurement with built-in compliance. Shadow SaaS decreased.
Shadow MCP is in the early stage of this arc. Developers are deploying unauthorized servers. Enterprises are beginning to respond with policies. The policies won't work, because they never do when the governed alternative is slower than the ungoverned one.
The enterprises that skip the policy phase and go directly to infrastructure, central registries, fast approval workflows, pre-approved templates, and continuous monitoring, will manage MCP adoption successfully. The ones that spend 18 months on policy before investing in infrastructure will manage a growing inventory of shadow servers, credential leaks, and compliance findings until they eventually build the infrastructure anyway.
The timing matters. MCP adoption within enterprises is accelerating. Gartner's prediction that 75% of API gateway vendors will support MCP by the end of 2026 means the number of MCP servers in enterprise environments will grow significantly over the next 12 months. Every month without governance infrastructure is a month where shadow MCP servers accumulate, credentials proliferate, and security debt compounds. The organizations that build governance infrastructure now will manage a controlled expansion. The organizations that wait will face a remediation project that grows with every passing quarter. Learn more
Rebase provides the MCP governance infrastructure that makes shadow deployments unnecessary: central registry, fast approval, pre-approved templates, and continuous monitoring. See how it works: rebase.run/demo.
Related reading:
Model Context Protocol for Enterprise
MCP Security Architecture: Moving Beyond HTTPS
Why Shadow AI Is Really an Infrastructure Problem
Enterprise AI Governance: The Complete Guide
BYOC: Why Your AI Should Run in Your Cloud
AI Agent Governance Framework
Ready to see how Rebase works? Book a demo or explore the platform.
![](data:image/svg+xml,<svg display="block" role="presentation" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg"><g d="M 0 24 L 0 0 L 24 0 L 24 24 Z M 22.223 0 L 1.772 0 C 0.792 0 0 0.773 0 1.73 L 0 22.266 C 0 23.222 0.792 24 1.772 24 L 22.223 24 C 23.203 24 24 23.222 24 22.27 L 24 1.73 C 24 0.773 23.203 0 22.223 0 Z M 7.12 20.452 L 3.558 20.452 L 3.558 8.995 L 7.12 8.995 Z M 5.339 7.434 C 4.195 7.434 3.272 6.511 3.272 5.372 C 3.272 4.233 4.195 3.309 5.339 3.309 C 6.478 3.309 7.402 4.233 7.402 5.372 C 7.402 6.506 6.478 7.434 5.339 7.434 Z M 20.452 20.452 L 16.894 20.452 L 16.894 14.883 C 16.894 13.556 16.87 11.845 15.042 11.845 C 13.191 11.845 12.909 13.294 12.909 14.789 L 12.909 20.452 L 9.356 20.452 L 9.356 8.995 L 12.769 8.995 L 12.769 10.561 L 12.816 10.561 C 13.289 9.661 14.452 8.709 16.181 8.709 C 19.786 8.709 20.452 11.081 20.452 14.166 Z" fill="transparent" height="24px" id="ubvjAgDes" width="24px"><path d="M 0 24 L 0 0 L 24 0 L 24 24 Z" fill="transparent" height="24px" id="qp5kjBCzR" width="24px"/><path d="M 22.223 0 L 1.772 0 C 0.792 0 0 0.773 0 1.73 L 0 22.266 C 0 23.222 0.792 24 1.772 24 L 22.223 24 C 23.203 24 24 23.222 24 22.27 L 24 1.73 C 24 0.773 23.203 0 22.223 0 Z M 7.12 20.452 L 3.558 20.452 L 3.558 8.995 L 7.12 8.995 Z M 5.339 7.434 C 4.195 7.434 3.272 6.511 3.272 5.372 C 3.272 4.233 4.195 3.309 5.339 3.309 C 6.478 3.309 7.402 4.233 7.402 5.372 C 7.402 6.506 6.478 7.434 5.339 7.434 Z M 20.452 20.452 L 16.894 20.452 L 16.894 14.883 C 16.894 13.556 16.87 11.845 15.042 11.845 C 13.191 11.845 12.909 13.294 12.909 14.789 L 12.909 20.452 L 9.356 20.452 L 9.356 8.995 L 12.769 8.995 L 12.769 10.561 L 12.816 10.561 C 13.289 9.661 14.452 8.709 16.181 8.709 C 19.786 8.709 20.452 11.081 20.452 14.166 Z" fill="rgb(234, 241, 255)" height="24px" id="W5lcXBfNC" width="24px"/></g></svg>)