Key takeaways
- Shadow MCP refers to Model Context Protocol servers running without security approval, wired into internal systems nobody reviewed.
- Unlike shadow IT, these servers act: writing to production, triggering deployments, querying databases, and sending messages.
- 81% of technical teams already run AI agents, but only 14% have full security approval.
Shadow MCP is a category of AI security risk that most enterprise security teams don’t have in their inventory yet. It sits at the intersection of shadow IT, agentic AI security, and software supply chain security. Unlike the shadow IT problems of the last decade, it doesn’t just expose data. It gives AI agents the ability to act.
Here’s what that actually means, what real attacks look like, and what you can do about it.
What is shadow MCP?
Shadow MCP refers to Model Context Protocol (MCP) servers deployed in enterprise environments without IT or security team approval. These servers create unmonitored connections between AI assistants and internal systems (databases, APIs, file systems, communication tools) that the security team never reviewed and often doesn’t know exist.
MCP itself is a legitimate open standard, introduced by Anthropic in late 2024, that defines how AI clients connect to external tools and data sources. Think of it as a universal adapter for AI: instead of every vendor building their own bespoke integration, AI clients speak MCP and tool servers speak MCP, and they connect. But when employees deploy MCP servers without oversight, at a scale that’s already significant, you get shadow MCP: AI with hands, running unsupervised.
Why shadow MCP is different from shadow IT
Shadow IT has been a thorn in security teams’ sides since employees started using Dropbox to share files too large to email. The risk was straightforward: data sitting somewhere the security team doesn’t control. Shadow AI, the broader problem of unauthorized AI tool use, extends that same logic.
Shadow MCP is different in one critical way. MCP servers don’t just expose data: they execute actions. A developer’s Claude Desktop instance connected to an unreviewed MCP server can write to production systems, trigger deployments, query databases, send Slack messages, or open GitHub issues. All through a connection that appears as normal user activity from the authentication system’s perspective.
The Gravitee 2026 report on AI agent adoption found that 80.9% of technical teams have already moved past planning into active testing or production with AI agents. Only 14.4% report that all their AI agents going live have full security and IT approval. Those numbers define how large the shadow MCP problem already is.
How a shadow MCP gets into your codebase
Most shadow MCP isn’t the result of malicious intent. It’s developers moving fast. There are four main insertion points:
Direct SDK use. A developer integrates an MCP client in their code to prototype an AI feature. The prototype ships without a proper security review. Six months later, it’s a production dependency.
Transitive dependencies. A package you’re using pulls in an MCP SDK somewhere in its own dependency tree. You get MCP connectivity without ever intentionally adding it. This is especially common as the MCP ecosystem has grown. There are now over 10,000 active public MCP servers, and the SDKs are spreading through npm and PyPI.
Configuration files. YAML, TOML, and JSON config files frequently contain model endpoint URLs and API keys that connect to external AI services. These fly under the radar of most code reviews and static analysis tools.
Reused scripts and notebook snippets. Code copied from community notebooks or online tutorials often contains hardcoded LLM calls. Once pasted into internal tooling, it stays. Nobody tracks where all those snippets came from.
What shadow MCP actually does to your organization
Data exfiltration and zero-click attacks
The obvious risk is data leakage. An unsanctioned MCP server can act as a bridge that transmits sensitive data (customer PII, credentials, proprietary code, regulated information) outside your perimeter, often invisibly.
Researchers at Operant documented this concretely with an attack they call Shadow Escape: a zero-click exfiltration chain where a compromised MCP connection surfaces private data and transmits it without any user interaction or phishing. The entire attack unfolds within sanctioned identity boundaries. From your authentication system’s perspective, it looks like normal user activity.
Uncontrolled AI automation
AI agents connected through shadow MCP servers can trigger workflows, modify production systems, and chain actions across platforms without human approval at each step. The blast radius of a single misconfigured or compromised server can extend across every system the MCP server can reach.
Because these are AI-driven connections, the decision of what to call and when moves from fixed application logic to LLM reasoning. That’s not inherently bad: it’s the point of agentic AI. But when the MCP server doing that reasoning hasn’t been reviewed, the scope of what an agent can do is effectively unbounded.
Tool poisoning and tool shadowing
MCP servers describe their capabilities to AI clients through human-readable tool definitions. Two related attacks exploit this:
Tool poisoning embeds malicious instructions in tool descriptions or responses, hijacking the AI’s decision-making without the user noticing anything wrong. It’s a form of prompt injection that operates at the tool definition layer rather than through user inputs. Trail of Bits documented a tool poisoning attack that silently exfiltrates a user’s entire chat history, including credentials, tokens, and intellectual property.
Tool shadowing is when an attacker registers a fake tool that impersonates a legitimate one. The AI client selects the impersonator, and the attacker controls what happens next.
Testing on the MCPTox benchmark found that o1-mini had a 72.8% attack success rate against tool poisoning. More capable models were more susceptible, not less, because stronger reasoning gets manipulated more reliably by well-crafted poisoning.
Authentication failures
Astrix research found that 53% of MCP servers rely on long-lived static secrets rather than short-lived, rotated credentials. Static secrets are hard to rotate, easy to over-scope, and they spread across projects. A single leaked API key can hand an attacker access to everything the MCP server can reach. Static secrets don’t expire until someone manually revokes them, so that access can persist for months or years after a breach.
Compliance exposure
Unauthorized MCP deployments create gaps in audit trails and data flow mapping that conflict directly with SOC 2, GDPR, and EU AI Act requirements. GDPR requires organizations to account for how personal data moves and who can access it. A shadow MCP server creating an unlogged data bridge fails that requirement before it processes a single request. The EU AI Act addresses high-risk AI systems and supply chain security in ways that demand visibility into AI connectivity that most organizations currently lack.
What real incidents look like
CVE-2025-53967 was discovered in the Framelink Figma MCP Server, a widely used third-party MCP integration for Figma: a remote code execution vulnerability triggered through command injection in the tool handler. This wasn’t a theoretical demonstration. It showed that MCP server implementations carry the same vulnerability classes as any other server-side software, but with a larger blast radius because of what they connect to.
The OAuth bypass pattern shows up repeatedly in security audits. A transitive dependency pulls in an MCP-integrated package that includes a popular OAuth provider library. That library contains a token validation bypass. Attackers compromise token validation and gain unauthorized access through the MCP connection without ever needing to phish a credential. The entry point was a dependency of a dependency that nobody specifically approved. That’s exactly the kind of insertion point that standard security reviews miss.
What OWASP and the NSA say about shadow MCP
Shadow MCP has crossed from informal concept to formally catalogued threat.
OWASP’s MCP Top 10 framework classifies shadow MCP servers as MCP09:2025, a recognized vulnerability category with documented risk patterns: data exposure through rogue servers, attack surface expansion through unmonitored endpoints, policy noncompliance, and inconsistent security posture from missing patches and weak defaults.
The NSA issued a formal advisory specifically scoped to the MCP ecosystem. It’s the first intelligence-community security advisory to address MCP directly. The advisory flagged MCP’s serialization layer as an active vulnerability surface, not a theoretical one, and highlighted that trust boundary failures in multi-server MCP architectures allow a single compromised tool server to propagate access laterally.
When OWASP and the NSA both have your threat model in their published guidance, you’re past the “emerging risk” category. This is a current, documented threat with known attack patterns.
How to find shadow MCP in your environment
Inventory is where this has to start. You can’t govern what you can’t see, and shadow MCP is specifically hard to see because it hides in places traditional network monitoring doesn’t look.
Network scanning. Externally reachable MCP services expose protocol-specific behavior at MCP endpoints: characteristic headers, structured capability responses, JSON-RPC patterns. Network scanning can surface these, though not servers bound to localhost or hidden behind proxies.
Host-level inspection. Many MCP servers run locally, bound to localhost rather than a network interface. They may listen on random high ports, sit inside IDE plugins, or run as background daemons that nobody formally decommissioned. Host-level inspection (looking for MCP SDK process signatures and local port activity) finds what network scanning misses.
Dependency analysis. Because MCP SDK adoption often precedes deployment, supply chain scanning can catch shadow MCP before it becomes a live server. Scanning your dependency graph for MCP-related packages provides early warning. Adding MCP server inventories to your Software Bill of Materials (SBOM) gives security teams a formal artifact to track what AI connectivity exists in each service.
CI/CD policy enforcement. Shift-left means catching unauthorized MCP SDKs before they hit production. Software Composition Analysis (SCA) in the CI/CD pipeline can block unapproved AI endpoints or MCP SDK dependencies at merge time, before they become a live server that needs detection and remediation.
MCP gateways. Organizations that have moved past detection toward governance route all MCP traffic through a central gateway that enforces authentication, authorization, and inspection. A gateway makes every MCP connection visible and policy-controlled. It doesn’t eliminate shadow MCP, but it ensures that any sanctioned MCP usage is auditable and provides a comparison baseline for what shouldn’t be there.
No single detection layer is sufficient. The pattern of MCP servers that bind to localhost, run on high ports, hide behind proxies, or live inside developer tools means each technique covers blind spots the others miss.
How to govern shadow MCP going forward
Detection tells you what you have. Governance determines whether it comes back.
Create an approved registry. A central catalog of vetted MCP servers, accessible to developers, makes the secure path the easy path. When developers can search for an approved Salesforce MCP server or a vetted database connector instead of configuring their own, most will take the approved path. Not because they’re forced to, but because it’s faster than building from scratch and debugging authentication.
Apply least-privilege permissions. Every MCP server should expose only the tools actually needed for the intended workflow. Read-only access where write access isn’t required. Scoped credentials with short expiry. This limits the blast radius when a server is compromised or misconfigured. That’s the difference between an attacker reading a database versus writing to it.
Add observability. Log every tool invocation and capability discovery event. Alert on enumeration spikes, unusual connection patterns, and unauthorized tool discovery requests. MCP activity should appear in your security operations workflow, not buried in application logs nobody monitors.
Harden the surface. Strip verbose capability banners, rate-limit discovery endpoints, and enforce strict JSON-RPC schema validation. Every piece of metadata an MCP server exposes reduces the cost of an attacker’s reconnaissance.
Educate developers. Most shadow MCP exists because developers don’t understand that the risk model is different from a traditional API call. An AI agent calling a tool through MCP doesn’t look like an API call. It looks like a user action. That distinction needs to be part of your developer security training.
FAQ
What is shadow MCP?
Shadow MCP refers to Model Context Protocol servers deployed in enterprise environments without IT or security team approval. These servers create unmonitored connections between AI agents and internal systems, allowing AI to execute actions (modifying files, querying databases, triggering workflows) without security team visibility or control.
How is shadow MCP different from shadow IT?
Traditional shadow IT creates passive data exposure: information sitting outside your control. Shadow MCP creates active execution risk: AI agents that can take actions through unmonitored connections. Blocking an unauthorized SaaS account stops data from reaching a new location. Shutting down a shadow MCP server stops an AI agent from acting autonomously on your systems.
What are the biggest risks of shadow MCP?
The main risks are data exfiltration through unmonitored AI connections (including zero-click attacks like Shadow Escape), uncontrolled AI automation where agents execute workflows without human approval, tool poisoning and tool shadowing attacks that manipulate AI behavior, authentication failures from static credentials, and compliance gaps under SOC 2, GDPR, and the EU AI Act.
How do you detect shadow MCP servers?
Detection requires multiple approaches in parallel: network-level scanning for MCP endpoints, host-level inspection for locally running servers, and supply chain dependency analysis to catch MCP SDKs before they become live connections. Each layer covers blind spots the others miss.
What is tool poisoning in MCP?
Tool poisoning is an attack where malicious content is embedded in MCP tool definitions or responses to manipulate AI agent behavior. The agent reads the poisoned definition and executes unintended actions, often without triggering conventional security alerts. Trail of Bits demonstrated this by extracting a user’s full chat history, including credentials, through a poisoned tool response.
Vetting every MCP server before install is item 6 of the pre-deployment checklist for agentic AI.
The starting point for most organizations is inventory: map what MCP connections exist in your environment before you try to secure them. OWASP’s MCP Top 10 and the NIST AI Risk Management Framework both provide structured approaches for assessing AI-related risk that apply directly here. If you don’t know where to start, those two frameworks will give you a defensible baseline.