Somebody at your company probably installed one this week. It takes about a minute: add a block to a JSON config file, name a package, restart the client, and an AI agent can now read your ticketing system or query your database. No procurement, no ticket, no review, and no record anywhere that it happened.
OWASP calls these unapproved or unsupervised deployments of Model Context Protocol instances that operate outside the organization's formal security governance. That definition comes from the MCP Top 10, OWASP's ranked list of the ten most significant security risks in MCP deployments. Shadow MCP servers sit at number nine. In plain terms, a shadow MCP server is one that somebody on your team installed or stood up, wired into real systems, and never told anyone about. There were 15,926 repositories on GitHub tagged as MCP servers as of late May, and not one of them asks whether you are allowed to run it.
Where they actually live
Most advice on finding shadow MCP servers assumes you are looking for a service listening on a port. Some of them are. Many are a line in a JSON file on somebody's laptop.
MCP supports a stdio transport, where the client launches the server as a child process on the same machine and talks to it over standard input and output. Nothing listens on a port. Nothing appears in a network scan or an asset inventory. The entire deployment is a config entry in a file like claude_desktop_config.json plus a package that gets executed when the client starts.
That is the shape worth looking for first, and there is evidence of how common it is. GitGuardian found 24,008 secrets sitting in MCP config files on GitHub, and 2,117 of them still worked. Those are the configs that leaked publicly. The ones that did not leak have the same contents.
What goes wrong
The credentials are the first problem. Astrix found that 8.5% of MCP servers use OAuth. 53% authenticate with static API keys or personal access tokens, and 79% receive those credentials through environment variables. A personal access token in an environment variable does not expire when the contractor's laptop goes home, and it carries the permissions of whoever generated it rather than whoever is asking.
Exposure is the second. Trend Micro found 492 MCP servers reachable from the public internet with no authentication at all. Every tool those servers offered was available to anyone who found the endpoint.
The third is that none of it is written down. The question during an incident is which systems the agent could reach, and an untracked server means nobody can answer that in the time available. The compliance version of the same problem is worse, because "we do not know" is a finding on its own.
What actually finds them
Network scanning finds the remote ones. It will not find a stdio server running on an engineer's laptop, so treat a scan as partial coverage rather than an inventory, and be suspicious of any tool that reports a clean result.
Three things work better in combination. The first is a registry of approved servers, so there is a defined answer to what is allowed and everything else is by definition an exception. The second is egress control, because a remote MCP server has to be reachable, and a server nobody approved is usually pointed at a hostname nobody approved either. The third is a log of tool calls, because a server that is doing anything at all is producing calls, and a call attributed to a server that is not on the list is the cleanest signal available.
We build the first and the third, and they do most of their work together. The library is where a server gets reviewed once and then reused: credentials issued centrally, versions pinned, one vetted copy of a server instead of nine engineers each picking a package off GitHub. The log records every tool call that goes through the gateway, with the server it went to and the identity it went as. Put those side by side and detection stops being a scan you have to schedule. A call to something that is not in the library is visible the moment it happens, and the calls that do match tell you which systems your agents actually touch, which is the question nobody can answer today.
That covers everything reachable over the network, which is where the credentials and the exposed endpoints are. A stdio server running locally against a local file system is a different job, and endpoint tooling already does it well: the client spawns the server as a child process, and device management can read the config file directly, since the whole deployment is a JSON entry at a known path.
The 2026-07-28 spec closes the gap further. Dynamic Client Registration is on the way out, and Enterprise Managed Authorization lets central IT provision client access through the identity provider. When credentials come from a place a developer cannot mint them, an unapproved server has nothing to authenticate with, and a good share of shadow MCP stops being possible rather than being caught after the fact.
Shadow MCP reads like a discovery problem, and it is one only while there is no list. Build the library, keep the log, and the servers nobody approved stop being something you go hunting for. They arrive on their own, as the calls that match nothing you said yes to.