# Shadow MCP: the ungoverned MCP servers your employees already connected

> Shadow MCP is shadow AI with hands: MCP servers employees connect to their AI clients outside any review. What it is, why it is riskier, and how to govern it without blocking.

Language: en · Category: governance · Author: Nicolas Corod (Founder & CEO) · Published: 2026-09-25

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](https://newsroom.ibm.com/2025-07-30-ibm-report-13-of-organizations-reported-breaches-of-ai-models-or-applications,-97-of-which-reported-lacking-proper-ai-access-controls). 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](https://modelcontextprotocol.io/), the Model Context Protocol that Anthropic [open-sourced in November 2024](https://www.anthropic.com/news/model-context-protocol), 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](/en/blog/what-is-shadow-ai/). 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](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp); on Team and Enterprise plans, only owners can. ChatGPT's [developer mode](https://developers.openai.com/api/docs/guides/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](https://blogs.microsoft.com/blog/2024/05/08/microsoft-and-linkedin-release-the-2024-work-trend-index-on-the-state-of-ai-at-work/) 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](https://postmarkapp.com/blog/information-regarding-malicious-postmark-mcp-package), 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](https://invariantlabs.ai/blog/mcp-security-notification-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](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp), so only connect servers from organizations you trust.

### The plumbing has holes

In July 2025, JFrog disclosed [CVE-2025-6514](https://research.jfrog.com/vulnerabilities/mcp-remote-command-injection-rce-jfsa-2025-001290844/), 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](https://www.backslash.security/blog/hundreds-of-mcp-servers-vulnerable-to-abuse), 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](https://eur-lex.europa.eu/eli/reg/2016/679/oj) expects controllers to keep records of processing activities (Article 30) and to use only processors offering sufficient guarantees (Article 28); the [Swiss FADP](https://www.fedlex.admin.ch/eli/cc/2022/491/en) sets a comparable record-keeping duty (Article 12). The MCP specification itself lists the audit problem among its [security best practices](https://modelcontextprotocol.io/specification/2025-11-25/basic/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](https://newsroom.ibm.com/2025-07-30-ibm-report-13-of-organizations-reported-breaches-of-ai-models-or-applications,-97-of-which-reported-lacking-proper-ai-access-controls) 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"](https://developers.openai.com/api/docs/guides/developer-mode) 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](https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/) 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](https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices), 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](/en/blog/mcp-vs-skills-composing/) 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](/en/blog/skill-md-the-king-of-shadow-ai/) 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](/en/blog/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](/en/blog/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](/en/ai-skills-check/) takes two minutes and asks for nothing.