What is shadow MCP?
By Identra · Updated
Shadow MCP is the use of Model Context Protocol servers that nobody in the organization has reviewed or approved. These servers can give AI assistants and agents access to files, tools and business systems through permissions security has never assessed.
How does shadow MCP start?
A developer copies a server entry from a GitHub README into ~/.cursor/mcp.json. Someone adds a Postgres server to Claude Desktop so they can query staging in plain English. A repo ships with a .vscode/mcp.json, and everyone who clones it inherits the connection. The Model Context Protocol is built to make this easy. Speaking the protocol says nothing about approval.
It usually lives inside tools that did pass review. Cursor might be approved. The Jira server someone bolted onto it with their own API token was not. That makes shadow MCP a narrow kind of shadow AI, where the unreviewed piece is the connection itself.
Shadow doesn't mean malicious. Most of it is people trying to work faster. The gap is that nobody accountable has checked whether the access fits the job.
What can an unreviewed MCP server reach?
A local server is a program. Launched with npx, it runs as the user and can read what the user can read, unless something isolates it. The MCP project's security guidance treats running a local server like trusting any other installed package.
A remote server fronts SaaS or cloud APIs. What matters is the token it holds and what that token authorizes downstream. The tools the agent sees can be narrower than what the server itself can do.
Tool descriptions and tool results also feed the model. A malicious description is MCP tool poisoning. A ticket body telling the agent to ignore its instructions is another way in. Write access makes both worse.
Where does it run?
- Local server
- On the user's laptop or a build host
- Remote server
- On a provider's or internal team's infrastructure
What do you inspect?
- Local server
- Package source, launch command, file access, credentials
- Remote server
- Operator, URL, authentication, grants, data handling
What limits it?
- Local server
- Isolation, scoped credentials, downstream permissions
- Remote server
- Server-side authorization, scoped credentials, downstream permissions
What does shadow MCP look like in practice?
Say a developer using an approved coding assistant adds a community MCP server to search support tickets while debugging. They paste in a personal API token that can read every ticket and edit them too. The task needed search on one project.
Now there are three questions. Which tickets can the server read? Does it expose write tools? Where does ticket content go once it comes back? Customer names and emails can land in the model's context even though the developer only asked about a stack trace.
The fix is a reviewed server, a read-only token scoped to that one support project and a written data flow. Approving the coding assistant covered none of it.
How do you find shadow MCP?
Look at the clients people actually use. Check ~/.cursor/mcp.json, Claude Desktop's claude_desktop_config.json and project files like .mcp.json and .vscode/mcp.json. Compare those with running processes and any tool call logs. A config entry, a running process and a logged call are three different facts.
Network monitoring won't give you the full list. Local servers often talk to the client over stdio, so nothing crosses the wire. OAuth app risk reviews help with remote servers, though a grant alone doesn't prove MCP is in use.
- Record client, device, server source, launch command or URL and owner.
- List enabled tools. Mark anything that can write, delete or send externally.
- Map tokens and grants to accounts without copying secrets into the inventory.
- Flag unknown owners, changed sources and access beyond the stated purpose.
How do you stop it coming back?
Approve a specific use of a server. That means owner, source, environment, tools and resources. A server cleared for a dev sandbox shouldn't quietly pick up production credentials. Enforce least privilege in the downstream account as well as in the client.
Publish a short list of vetted configs and a fast way to request new ones. If approval takes three weeks, people will go around it.
- Check package provenance for local servers and the operator for remote ones.
- Use dedicated, scoped tokens. Keep secrets out of shared project configs.
- Require a human to approve deletes, external sends and permission changes, with the target shown.
- Re-review when the code, owner, tools or credentials change.
What do you do when you find one?
Work out what was configured, what ran and what it could reach. Keep the config file and any activity logs. Unknown operators, sensitive data and write access go first. Having access and using it are separate findings.
Deleting the line from mcp.json doesn't stop a process that's already running. It doesn't revoke the OAuth grant or rotate the API key either. Do each one and confirm access is gone. Anything suspicious goes through AI incident response. Then give the developer an approved way to do the work.
How Identra thinks about it
Identra finds MCP servers, coding agents like Claude Code and Codex, and desktop AI apps on macOS and Windows endpoints. It also shows connected apps and OAuth grants across Microsoft 365, Google Workspace, Okta and other providers, sorted by what they can reach. Analysts can revoke risky grants, and every AI agent run is recorded with the user and device.
Go deeper: AI security, built on identity
Frequently asked questions
Is every locally installed MCP server shadow MCP?
No. It's shadow MCP when nobody has reviewed it. A local server with an owner and defined access is governed.
Does a marketplace listing mean a server is approved?
No. A listing can help with provenance. Your organization still has to review the package, its permissions and how it will be used.
Does an MCP server give an agent full device access?
Not automatically. It depends on the tools exposed, the server's permissions, credentials and isolation. The server process may reach more than its tools expose.
Does MCP authentication prevent shadow MCP?
No. Authentication says who is connecting. It doesn't say whether the server or its access was approved.
Should you block every unapproved server right away?
Contain first if the access is dangerous or there are signs of abuse. Otherwise keep the evidence, assess scope, then remove it or approve a restricted version.