Shadow MCP servers are MCP servers running inside an organization that the security team has never reviewed and nobody officially owns: a server a developer added to Claude Code or Cursor in thirty seconds, one committed to a repository in a .mcp.json file, or a demo server someone deployed and forgot. OWASP lists them as MCP09 in its MCP Top 10. They matter because each one runs with real access to files, secrets or internal systems, and you cannot review, limit or remove a server you do not know exists. Finding them means looking in three places: developer machines, repositories and deployed infrastructure.
What counts as shadow MCP servers
The term covers two different things that share one problem. The first is client-side: servers that coding agents and desktop AI apps start on a developer's laptop, defined in the agent's own config files. The second is server-side: MCP servers deployed as services, on a cloud account or an internal network, often for a quick test.
Microsoft's security guide for MCP on Azure, which is organized around the OWASP list, describes MCP09 as covering internet-exposed deployments, unapproved internal servers, and client-connected servers that bypass review and ownership. What they share is the absence of an owner and a review. A server is not shadow because it is risky. It is shadow because nobody responsible for risk has looked at it.
In practice the client-side kind is far more numerous, because every developer can create one, while the server-side kind tends to be more exposed, because it is reachable over a network. A full search covers both, and the methods below are different for each.
Why unreviewed MCP servers spread so fast
Adding an MCP server is easy by design. Most agents read servers from a plain config file, and many projects publish a one-line install command. Claude Code's documentation is direct about the default: anyone running it can connect any MCP server they choose, unless an administrator restricts it.
Three habits turn that ease into sprawl. Developers add servers to try them and never remove them. Project-level config files, such as .mcp.json or .vscode/mcp.json, are committed to git, so one developer's choice arrives on every machine that clones the repository. And servers deployed for a demo stay running after the demo, because nothing reminds anyone they exist. Microsoft's guide gives exactly that example: a temporary demo server with no authentication and public access, later found by an outside scan, exposing credentials for internal databases.
What a shadow MCP server can reach
A local MCP server runs with the developer's own permissions. The MCP documentation warns that a filesystem server can perform any file operation the user can, and the same is true of any other local server: it can read SSH keys, .env files and source code, and reach whatever the user's network can reach.
That is why the unreviewed ones are dangerous even when most are harmless. postmark-mcp, the first malicious MCP server found in the wild, was installed by people who had no review process to catch that its publisher had nothing to do with Postmark. A review would not have caught every problem, but it would have asked the question. Shadow MCP servers skip the question entirely.
How to find shadow MCP servers on developer machines and in repos
On laptops, every coding agent keeps its servers in known files: ~/.claude.json and .mcp.json for Claude Code, ~/.cursor/mcp.json for Cursor, .vscode/mcp.json for VS Code and Copilot, and similar files for Windsurf, Codex and Claude Desktop. Our guide on how to find MCP servers on developer machines lists every path and the commands to read them without changing anything. Through device management, a read-only script can collect those files from every machine, with secret values stripped before anything is sent back.
In repositories, search your source host for project-level MCP files. This finds the servers that spread through git, and it tells you which team introduced each one, which is the owner you need for the next step. Run both searches on a schedule; a list from last quarter shows what used to be there.
Record the same fields for every server you find: the command or URL, the version, the folders and tokens it gets, whose machine or which repository it came from, and the date you first saw it. That record is what turns a list of package names into decisions, and it is the evidence an auditor will ask for when they get to MCP09.
How to find unowned MCP servers in the cloud
Deployed servers need a different search. Microsoft's guide recommends continuous discovery of running containers and services, recurring inventory queries for MCP-related resources that lack approval or ownership metadata, and tags such as an owner and a security review date on every MCP deployment. It also recommends a policy that blocks deployments missing those tags, and denying public endpoints by default so a forgotten server is not reachable from the internet. The same approach works on any cloud: tag, query for what is untagged, and block what cannot be tagged.
How to talk to developers about it
Developers add these servers because they make agents more useful, not to get around security. A review that arrives as a block with no warning teaches people to hide the next server better. A review that arrives as a short conversation, with a clear reason and a quick path to approval, gets you an accurate list next time.
Three things help. Say what you are collecting and why before the first scan: the agent config files, with secret values removed, so security can see which servers are in use. Publish the approved list where developers already look, such as the engineering wiki or the repository template, with the exact install line for each server. And give a turnaround time for requests, so asking is faster than working around the process. The servers that are still unknown after that are the ones worth a closer look.
It also helps to say what happens to a server that fails review. In most cases the answer is a safer alternative or a narrower setup, such as one project folder instead of the whole home folder, rather than a flat no. Developers who see that a review usually ends in a working tool are far more likely to ask first.
What to do once you find them
Give every server an owner and a decision: approved, approved with limits, or removed. For approved servers, pin the version and narrow the folders and tokens they get; our MCP security checklist covers each check. Then make the decision stick. Several agents now support an MCP allowlist that limits developers to approved servers; Claude Code, for example, can lock its allowlist to managed settings so users cannot widen it.
Finally, keep watching. Claude Code can export which MCP servers and tools users invoke through its OpenTelemetry monitoring, and other agents offer similar logs. New unreviewed servers will keep appearing, because the reasons they appear do not go away. The goal is to see each one within days, not years.
Two practical next steps: put the rule in writing with our AI acceptable use policy template, and give developers a safer starting point with our mcp.json example for each coding agent.
Next step: find every shadow MCP server in one pass
Shadow MCP servers are a subset of the wider shadow AI problem, and the fastest way to see both is a scan that reads coding agents directly. NoFly's shadow AI agent discovery lists every AI agent and every MCP server it loads, across machines and repositories, with who runs each one. Run a Discovery Scan to get that list, scored for risk.