Shadow MCP Servers: The AI Tools Nobody Vetted

Shadow MCP servers are the version of this problem nobody budgeted for: your developers connected AI tools to real systems, it took them under a minute each, and there is no list anywhere of what they connected. Not because anyone was careless. Because nothing in the process was designed to produce a list.

If you have read what MCP is and why its security matters, you know the risk of a single server. This is the organizational version, and it is harder, because you cannot evaluate what you cannot see.

I knew the term MCP. What I did not know was that I had been using it for months. Writing this post, I opened the connector settings in my own AI client and found three active connections: Google Drive, Notion, and a browser extension that can drive my browser directly. Those connectors are MCP servers underneath, and I had approved every one of them myself, one at a time, without ever thinking of them as a set. Asked beforehand to list what my assistant could reach, I would have guessed wrong.

Three connections, approved one at a time, reaching my documents, my notes, and my browser. Nothing here is unauthorized. I just could not have named it from memory.

That is the mild version of the problem, and it is worth being precise about why. These are curated, first-party connectors in a consumer app, not unvetted third-party code on an engineer’s laptop. If visibility fails at this end of the spectrum, where somebody else has already done the vetting and there are only three of them, it is worth asking what the count looks like across a team where nobody vetted anything.

Shadow MCP servers spread faster than shadow SaaS

Shadow IT is not new. Someone signs up for a SaaS tool with a company card, and eventually finance or SSO logs catch it. The feedback loop is slow, but it exists.

MCP breaks that loop in three ways at once.

There is nothing to buy. Most MCP servers are free packages. No card, no invoice, no vendor form, no SSO integration. Every mechanism that eventually surfaces a rogue SaaS subscription is absent.

The install is a single line. Adding a server means pasting a command from a README. There is no deployment, no ticket, and no moment where anyone else is involved. On developer forums, the recurring complaint is not that people ignore approval processes, it is that the approval process takes longer than the task the tool was meant to help with, so the tool gets used first and disclosed later, or never.

It does not look like anything on your network. A local MCP server is a process on a laptop, usually talking over stdio or a local port inside a developer tool. It does not appear as a new SaaS domain, a new OAuth grant, or an unusual outbound connection to a service you can name. The tools you already run to spot unsanctioned software are looking in the wrong place.

Each of the usual discovery methods has a blind spot in exactly the place MCP servers live.

Config files skip every review your SaaS goes through

The sharpest version of this is not a developer choosing badly. It is a server nobody chose at all.

In February 2026, Check Point Research disclosed a set of vulnerabilities in Claude Code that make the point precisely. Claude Code reads project-level configuration from files that live in the repository: .claude/settings.json and .mcp.json. Anyone with commit access can change them. Researchers found that a repository could set enableAllProjectMcpServers, which auto-approves every MCP server defined in the project, and the attacker’s server would then execute before the user could even read the trust dialog. In their demonstration the payload launched on top of the still-pending prompt, and they escalated the same technique to a reverse shell.

Anthropic has patched this, and Check Point credits their handling of the disclosure. The reason it still matters is the delivery mechanism, which no patch removes. Check Point lists three realistic paths: a malicious pull request that carries the config alongside genuine code changes, a useful-looking honeypot repository, and an internal repo poisoned by one compromised account.

Developers inherently trust project configuration files. They are viewed as metadata rather than executable code, so they rarely undergo the same security scrutiny as application code during code reviews.

That is the shadow MCP problem in one sentence. Your team reviews code. Nobody assigned anyone to review the config that decides which servers connect and what they are allowed to do.

There is a related failure practitioners keep raising: even a server you did review can change. A tool’s name, description, and parameter schema can be updated at any time, and the version you approved is not necessarily the version running next week. Approval is being treated as a one-time gate for something that is continuously mutable.

Invisible connections, measurable costs

The counterargument is that this is a hypothetical, and hypotheticals do not get budget. The measured cost of the general pattern is not hypothetical.

IBM’s Cost of a Data Breach Report 2024 found that 35 percent of breaches involved data stored in unmanaged sources, what the report calls shadow data. Those breaches cost an average of 5.27 million dollars against that year’s global average of 4.88 million, and took 26.2 percent longer to identify and 20.2 percent longer to contain, averaging 291 days.

The newer 2025 edition of the same report turned to a more specific version of the same problem: 20 percent of organizations studied had a breach linked to shadow AI, meaning unsanctioned AI tools adopted without IT or security oversight, adding roughly 670,000 dollars on top of that year’s global average of 4.44 million. Governance was just as thin. 63 percent of the breached organizations had no AI governance policy in place at all, and those incidents disproportionately exposed customer personal information and intellectual property.

Shadow MCP sits at the intersection of both categories. It is unapproved AI tooling reaching unmanaged data, on machines that hold credentials. The cost premium in those numbers is not paid for the breach itself. It is paid for the months spent working out what was connected to what.

Finding what is already connected

Before any policy is worth writing, someone has to answer a factual question: what is running right now. That is a smaller job than it sounds.

MCP configuration lives in predictable places. Client config files on developer machines (Claude Desktop, Claude Code, Cursor, VS Code and similar all keep their own), and repository-level files like .mcp.json and .claude/settings.json that ship with projects. Grepping your own repositories for those filenames is a genuinely useful afternoon, and it finds the category the Check Point research describes: servers that arrive with a codebase rather than a decision.

The second question is not “how many” but what each one can reach. A server holding a read-only token against one dataset and a server holding an admin key are different entries on the same list. Record the credential, not just the name.

The third is who to ask when the answer is unclear. In practice the person who installed it usually remembers, and asking is faster than any scanning tool. This step fails only when people expect to be punished for answering honestly, which is a management decision rather than a technical one.

Practices teams are settling on

Practitioners running MCP at organizational scale keep converging on a similar shape, and it is worth knowing the direction of travel before you invent your own.

The most common pattern is a single org-controlled gateway sitting between users and the tools the company actually uses, so that access, logging, and policy have one place to live. Alongside it, an internal registry of approved servers with pinned versions, which addresses the mutability problem directly: you approve a version, not a name. Several teams describe a pre-approval step that runs each candidate through dependency auditing and then observes it in a test environment, logging every tool call it makes for an hour to see whether its behavior matches its description.

The more interesting refinement is access control at the level of individual tools rather than whole servers. Approving a server grants everything it exposes, which can be dozens of tools. What most teams actually want to approve is three of them.

You do not need a budget or a product to start. You need one person whose job it is to keep the list, because the usual failure here is not picking the wrong controls. It is that the question never had an owner.

FAQ

Sources

• Check Point Research: RCE and API token exfiltration through Claude Code project files (CVE-2025-59536, CVE-2026-21852)
• IBM: Cost of a Data Breach Report 2025
• IBM: Hidden risk of shadow data and shadow AI leads to higher breach costs
• GitHub Security Advisory GHSA-4fgq-fpq9-mr3g (CVE-2025-59536)

Vulnerability details reflect Check Point Research’s February 2026 disclosure, after which the issues were patched. Shadow-data figures (35 percent, 5.27 million dollars) are from IBM’s 2024 report; shadow-AI figures (20 percent, 670,000 dollars) are from the 2025 edition. Descriptions of team practice reflect ongoing practitioner discussion rather than measured survey data.