Shadow MCP: the ungoverned MCP servers your employees already connected

In 2025, one in five organizations studied by IBM reported a breach due to shadow AI, and those with high levels of shadow AI saw an average of USD 670,000 in higher breach costs. That figure measures the first wave: employees pasting company data into consumer chatbots. The second wave is already here, and it is harder to see. Employees are no longer only chatting with AI. They are connecting it to their mailbox, their CRM, their code and their files, one MCP server at a time.

Call it shadow MCP.

What is shadow MCP?

Shadow MCP is the set of MCP servers that employees connect to their AI clients on their own, outside any IT or security review, running with their personal credentials. Nobody approved them, nobody holds an inventory of them, and nobody can say what they did yesterday.

MCP, the Model Context Protocol that Anthropic open-sourced in November 2024, is the standard way to plug tools into an AI agent. An MCP server exposes actions (send an email, query a database, open a pull request) that Claude, ChatGPT, Copilot or an IDE agent can call. It is a good standard. The problem is who connects the servers, and how.

If shadow AI is new to you, start with what shadow AI is and why banning it fails. Shadow MCP is its next step.

How shadow MCP gets in

There is no procurement step to catch, because there are three side doors:

1. Local servers on developer machines. IDE agents and desktop clients start MCP servers from a line of configuration, usually a package pulled from a public registry. It runs on the laptop, with the laptop’s access.
2. Personal custom connectors. On Claude’s individual plans, users add custom connectors themselves; on Team and Enterprise plans, only owners can. ChatGPT’s developer mode gives full MCP support, read and write, on individual plans too. A personal account plus a personal connector puts company systems one prompt away from a tool nobody reviewed.
3. Home-grown servers. A team wraps an internal API in a quick MCP server to save time, shares the configuration in a chat thread, and it quietly becomes infrastructure.

None of this is malicious. It is people doing their jobs faster, exactly like the first wave of shadow AI. The Microsoft and LinkedIn 2024 Work Trend Index found that 78% of AI users were bringing their own AI tools to work. Tools that act are simply the next thing they bring.

Why shadow MCP is riskier than shadow AI

Shadow AI leaks what someone pastes. Shadow MCP acts with what someone can reach. An agent holding a mail connector and a file connector can read, send, move and delete, with the employee’s full rights, following instructions that may not come from the employee at all. The risks are not hypothetical; each one below has a public record.

A trusted server can turn

In September 2025, Postmark warned that a package called postmark-mcp, which it had never published, had been copying the emails it sent to an outside server. The impersonator shipped fifteen clean versions to build trust, then added the blind copy in version 1.0.16. Anyone who picked it by name from a public registry and moved to that version was exposed.

Tool descriptions can carry orders

In April 2025, Invariant Labs described tool poisoning attacks: hidden instructions in a tool’s description, invisible to the user but read by the model, which can make the agent exfiltrate data through a different, legitimate server. The same research describes the “rug pull”: a server changes its tool descriptions after the user approved it. Anthropic’s own help center says it plainly: malicious MCP servers may include hidden instructions, so only connect servers from organizations you trust.

The plumbing has holes

In July 2025, JFrog disclosed CVE-2025-6514, a critical flaw (CVSS 9.6) in mcp-remote, a widely used proxy that connects clients to remote MCP servers: connecting to an untrusted server could lead to command execution on the user’s machine. A month earlier, Backslash Security reported hundreds of MCP servers bound to all network interfaces, reachable by anyone on the same network, and dozens that allowed arbitrary command execution on the host.

Nothing is on the record

When a connector nobody registered processes customer data, it is a processing activity nobody recorded. The GDPR expects controllers to keep records of processing activities (Article 30) and to use only processors offering sufficient guarantees (Article 28); the Swiss FADP sets a comparable record-keeping duty (Article 12). The MCP specification itself lists the audit problem among its security best practices: when tokens are passed through carelessly, logs show requests coming from the wrong identity and incident investigation becomes harder. IBM’s figure makes the same point from the other side: 63% of breached organizations either had no AI governance policy or were still developing one.

Why banning MCP will not work

The reflex is to block it. It fails for the same reason banning ChatGPT failed: MCP is built into the clients your teams already use, and the productivity gain is real. Block it on managed laptops and it moves to personal accounts, where you see even less. The vendors say as much: OpenAI calls developer mode “powerful but dangerous” and still ships it, because connected agents are where the value is.

The goal is not zero MCP. It is zero MCP you cannot see.

How to govern MCP without blocking it

Five moves, in order:

1. Take an inventory. List the MCP servers already configured in your AI clients and IDEs, and the OAuth grants given to connectors. You cannot govern what you have not counted.
2. Stand up an internal, curated registry. A short list of servers that have been reviewed, credentialed and scoped for your organization. Public registries help people discover servers; they do not authorise them. The MCP project’s own registry announcement expects enterprises with strict security requirements to run private sub-registries.
3. Close the side doors with the controls you already own. On Claude Team and Enterprise plans, only owners can add custom connectors; use that, and the equivalent settings in your other clients, so the registry is the only way in.
4. Grant the least, pin the version. Give each server the narrowest credentials that do the job, as the MCP specification recommends with scope minimization, and pin versions so an update is a decision, not a surprise.
5. Log every call, and make the sanctioned path the easy one. Every tool call attributable to the person who ran it. Then package the approved servers with the instructions that use them well, so the governed option is faster than the shadow one. Bundling skills over MCP tools is how that stays usable.

The last point is the one that decides the outcome. As with shadow AI, shadow MCP is a product problem before it is a discipline problem: people go around a process when the process is slower than the workaround. The same goes for skills: a SKILL.md passed around outside any catalogue is the know-how version of the same leak.

Where skilder fits

skilder’s answer to shadow MCP is structural. Each workspace has an internal, curated MCP server registry: servers that have been vetted and pre-configured (reviewed, credentialed and scoped), not an index of every server that exists. Adding a server to it is the central authorisation step. Servers then reach people through roles: a role is the work one seat on the org chart does, bundling skills, scoped MCP tools and permissions, and it can only reach servers already in the registry. Connectors are authorised centrally and revocable, and every task is logged and attributable to the person who ran it. The same registry serves Claude, ChatGPT and Copilot.

It is not a public MCP directory and it does not try to be one. Its job is the opposite: to keep the list short, known and owned. How reaching servers only through learned roles holds up under adversarial prompts is what the progressive skill discovery paper measures. Where that registry sits next to a model gateway or an agent gateway is covered in LiteLLM vs agentgateway vs skilder.

The bottom line

Shadow AI taught organizations that you cannot ban your way out of a tool people find useful. Shadow MCP raises the stakes, because the tool now acts. The answer is the same, one level up: see what is connected, offer a governed path that is at least as good, and keep a record of what the agents did.

To see where your organization stands on control and traceability, the 10-question AI check-up takes two minutes and asks for nothing.

Frequently asked questions

What is shadow MCP? +

Shadow MCP is the use of MCP (Model Context Protocol) servers that employees connect to their AI clients on their own, outside any IT or security review: packages installed from public repositories, servers started on a laptop, or remote endpoints added as personal custom connectors. They run with the employee's own credentials, and nobody holds an inventory of them.

How is shadow MCP different from shadow AI? +

Shadow AI is about data going out: an employee pastes a contract or a customer list into a consumer chatbot. Shadow MCP is about actions going in: an MCP server lets the agent read and write in company systems (mail, CRM, code, files) through a tool nobody vetted. The exposure is no longer limited to what someone typed; it extends to everything the connected credentials can reach.

Are MCP servers safe to use in a company? +

The protocol is not the problem; unvetted servers are. Public incidents show the risk: a counterfeit postmark-mcp package on npm silently copied every email it sent to an outside address, and a critical vulnerability (CVE-2025-6514, CVSS 9.6) in the mcp-remote proxy allowed code execution when connecting to an untrusted server. A server that has been reviewed, pinned to a version, given scoped credentials and logged is a very different object from one installed from a search result.

How do you govern MCP servers without blocking them? +

Five steps: take an inventory of what is already connected; set up an internal, curated registry of servers that have been reviewed, credentialed and scoped; use the admin controls of your AI clients so only that registry is reachable; pin versions and review updates; and log every tool call, attributable to the person who ran it. Then make the sanctioned path easier than the shadow one, so people have no reason to go around it.

Should an enterprise use a public MCP registry? +

A public registry is useful for discovery: the official MCP Registry lists publicly available servers. It is not an authorisation. The MCP project itself expects enterprises with strict security requirements to run private sub-registries. What employees can reach should come from an internal, curated list, not from a public directory.