By Nolan Sullivan, Founding Growth Engineershadow MCP
Shadow MCP is Model Context Protocol (MCP) servers your organization is using that no one with a security mandate has sanctioned. It is the MCP-specific form of shadow AI: a laptop-local GitHub server, a personal SaaS connector, or an unsanctioned catalog entry that never passed review, operating outside formal security governance.
The OWASP MCP Top 10 catalogs the risk as MCP09:2025 Shadow MCP Servers, defining shadow MCP servers as “unapproved or unsupervised deployments of Model Context Protocol instances that operate outside the organization’s formal security governance.” OWASP notes they are often spun up by developers, research teams, or data scientists for experimentation or convenience, frequently with default credentials, permissive configurations, or unsecured APIs.
Shadow MCP is a population rather than a register. The term names every server currently operating in that condition, and finding those servers, recording them, and closing them are separate operations against that population. Cloudflare, which detects MCP traffic at the network boundary, states the same definition from the connection side: shadow MCP is “a connection to a server the organization has not approved.” The endpoint view and the network view describe one population, because the config file on the laptop is what creates the connection on the wire.
How is shadow MCP different from shadow AI?
Shadow AI is the broader category. It covers every form of AI in use outside the security perimeter: models reached through personal accounts, internal agents nobody registered, skills loaded out of band, and MCP servers installed without review. What is shadow AI covers that category end to end, including the detection architecture.
Shadow MCP is the tool-server slice of that population. It asks one narrower question: which MCP servers are your agents calling that nobody sanctioned? The narrowing matters because it changes what you can do with the findings. Shadow AI findings span object types that get governed differently, since a personal ChatGPT account, an unreviewed skill, and an unsanctioned server each need a different control. Shadow MCP findings are all the same object type: a server, the tools it exposes, and the credential behind it. A population made of one object type can be inventoried, so every finding can become a record with an owner and a disposition rather than an alert with no place to land.
Why do a CMDB and a laptop survey miss shadow MCP?
MCP servers mostly are not installed, so the systems that track installed things have nothing to record. A local stdio server is a few lines of JSON in a dotfile such as ~/.cursor/mcp.json that tell an agent which package to execute. A remote server is a URL, and the only artifact on the endpoint is a runtime connection. An endpoint scan records Cursor, an approved application on the software register, and misses the GitHub server wired into it and the personal access token that server authenticates with.
A survey fails on a different clock. Wiring up a new server is a config-file edit, so a spreadsheet compiled by asking teams what they run describes last quarter by the time anyone reads it. This is the same decay mode that kills the registers themselves, covered in what is an MCP inventory for the tools side and what is an agent inventory for the principals side. The registers are where shadow MCP findings eventually land, not the mechanism that finds them.
What risk does shadow MCP create?
An unsanctioned server bypasses the controls the sanctioned path exists to apply. The OWASP impact list for MCP09 is specific: shadow servers bypass centralized authentication, monitoring, and data governance, they expand the attack surface with unmonitored endpoints, and they complicate incident response because untracked servers delay containment and forensics.
The concrete failure sits in the credential and the tools. The credential behind a shadow server was never reviewed, and it is often a personal access token with the full reach of the person who created it, so the server can read and write everything that person can. The tools were never assessed either. Nobody checked whether the server exposes a destructive tool next to a read-only one, and no allowlist constrains what an agent may call. When something does go wrong, there is no audit trail, because the calls never passed a point that records them. OWASP classes the result as both a prime target for attackers and a compliance liability.
How do you find shadow MCP?
Discovery sits at the endpoint, where the configuration lives. Agent hooks fire inside coding agents on every prompt and tool call, and they can report the MCP servers a session actually connects to, including servers that never passed review. The difference between that feed and the sanctioned register is the shadow set. The shadow AI reference covers the discovery architecture end to end, from hooks through MDM provisioning, and the MCP inventory is where each finding lands, as a record with an owner and a disposition instead of an alert that scrolls past.
How do you close shadow MCP?
Closing a finding is three operations, in order. Disconnect the server, so the agent’s next session no longer reaches it. Revoke the credential it authenticated with, because a disconnected server with a live personal access token is one config edit from coming back. Then provision the sanctioned alternative, a reviewed catalog delivered through MDM or enforced as a gateway allowlist, so the approved server is already on the laptop and the shadow one has nothing left to offer. Enforcement on that path is the subject of what is an MCP gateway.
The rollout order matters as much as the controls. A common pattern is observability-first: flag unsanctioned connections, assign each finding an owner, and give teams a window to move onto the sanctioned path before blocking turns on. A hard block on day one punishes the engineers who adopted MCP earliest, and it teaches the rest of the organization to hide the next server better.
How does the Speakeasy AI Control Plane handle shadow MCP?
Everything above is architecture an organization could assemble itself. The Speakeasy AI Control Plane ships it as one system. Shadow MCP detection recognizes, from instrumented agent traffic, when a session connects to a server outside the sanctioned setup, and surfaces it by URL, host, or resolved identity. Each finding lands in the MCP inventory the platform maintains, as a record with an owner and a disposition next to every sanctioned server. The sanctioned path runs through the platform’s gateway, so approved servers come provisioned with identity, allowlists, and audit logging attached, and traffic can be required to flow through it once the observability-first window closes. To see which servers your agents are already calling that nobody sanctioned, talk to us.