Shadow MCP is the new shadow IT

If you’re in an office building right now, think about the entrance.

Are there badge readers? Cameras? A security desk? Probably.

But somewhere, maybe near the loading dock, or down the stairwell by the parking garage, there is a door that is propped open.

Who propped it open? People carrying supplies, or running late, or tired of badging in for the fourth time this morning. The door is inconvenient to secure properly, so it stays unsecured.

The phenomenon has a name in physical security:** the vulnerability of the convenient bypass**. The front entrance is hardened precisely because everyone knows it is the entrance. The side door is vulnerable precisely because nobody is watching it.

Enterprise IT spent the last decade hardening the front entrance. Single sign-on. Multi-factor authentication. Endpoint management. Data loss prevention. The stack works, at least for the systems IT knows about, accessed through the channels IT controls.

MCP servers are the side door.

They get built by individual teams moving fast, connected using whatever credentials the builder happens to have, and they show up nowhere on the asset inventory. When an agent connects through an ungoverned MCP server, it inherits the full permissions of the person who set it up. Not a scoped-down subset or a purpose-built service account with limited access. Whatever that person can do in Salesforce, in your ERP, in your customer database, the agent can do too.

The front entrance is locked. The side door is open. And the teams building MCP servers are not trying to create vulnerabilities. They are just trying to move fast.

That is exactly how shadow IT started, too.

Shadow IT and shadow MCP started the same way

The proximate cause of shadow IT was always the same: IT could not move as fast as the business needed. A tool existed that solved the problem. Users chose the path of least resistance.

MCP adoption is playing out identically. Marcus Dubreuil, Director of Systems Architecture at J.W. Pepper, described it like this: “People outside of the IT department, perhaps with a little bit less governance, were moving faster than we were within IT and actually creating these useful AI agents.” The business wasn’t waiting for a formal MCP program. They were already building because teams that can connect agents to their tools get more productive faster. The first person on a team to build a working MCP server generates immediate demand from every other person on the team. Appetite compounds with every connection made.

At the same time, what used to be “this service has an API, can we integrate it?” has turned into “this service has MCP.” That shift sounds small. It is not. MCP is not just another integration pattern. It is an access layer that can reach real production systems across the business, under whatever permissions the user happens to have.

Where shadow MCP diverges from shadow IT

Shadow IT created problems IT had to clean up later: unsupported tools, scattered data, contract duplication, inconsistent security posture. Expensive and annoying to remediate, but rarely catastrophic.

Shadow MCP creates something different. When a business user connects an MCP server using their own credentials, the agent they’re working with effectively inherits their access. As Marcus put it: “One of the challenges with how MCP works that I learned really quickly is that it effectively forwards any access control that the user has to the AI agent. You’re effectively saying, ‘you’re me now.’”

A Dropbox account with ungoverned data is a compliance headache. But an MCP server with full admin access to your CRM, your finance system, and your customer database is an active attack surface.

One in three MCP servers tested in independent research had critical vulnerabilities. When researchers ran ten unmanaged MCP servers together, the exploit success rate reached 92%. According to Gartner, by 2027, cybersecurity incidents tied to prompt injection, data access, or agent misconfiguration will affect more than 40% of enterprise MCP deployments.

MCP can be a ticking time bomb. The risk is concentrated exactly where shadow MCP proliferates: ungoverned servers, inherited permissions, no audit trail.

Shadow MCP disguises itself as productivity

There is a recognizable pattern to how shadow MCP develops inside an organization. It disguises itself as productivity.

A team tries an agent with a few MCP tools. It works. So they connect more tools. Then other teams hear about it and want the same. Now, the queue for IT to review and provision tools is growing faster than IT can work through it. Teams get impatient. They start building their own servers.

At each individual step, the decision looks reasonable. The collective outcome is MCP sprawl: multiple servers with overlapping scope, inconsistent security configurations, no shared ownership, and no visibility from IT into what any agent is actually doing.

The challenges J.W. Pepper encountered before centralizing its MCP program are a recognizable picture of where this leads: finance building their own MCP servers, shadow AI spreading faster than governance, users granting full admin access to agents, IT playing catch-up rather than leading, zero visibility into agent activities, and compliance exposure accumulating in the background.

Each of those conditions exists independently in many enterprises right now. The question is how long before they compound.

Why shadow MCP makes the governance conversation harder

Shadow IT was eventually brought under control in most enterprises, but it took years. The mechanism that made it so persistent was organizational, not technical: by the time IT got involved, the business had built workflows around the unsanctioned tools. The cost of switching was high enough for people to push back.

MCP will follow the same pattern, and likely faster. The tools are more capable. The integration surface is wider. An engineering team that has built four or five MCP servers in a week has made significant investment in that architecture. Asking them to tear it down and rebuild under a governed framework is a harder conversation than it needed to be, had governance been there from the start.

The right parallel is the one that applied to shadow IT: the governance conversation does not get easier over time. It gets harder. Every week without a policy approval path is a week of additional entrenchment.

How organizations stay ahead of shadow MCP

Organizations that successfully navigated shadow IT did it by making the governed path faster and easier than the ungoverned one.

The same logic applies to MCP. J.W. Pepper centralized its MCP servers and tools using a managed gateway, gave IT visibility and control over what was available, and launched governed MCP in weeks. Rather than becoming a bottleneck, IT became a service provider. Tools were opt-in. Access was scoped by design. Zero raw database access was established as a baseline from the start.

Marcus Dubreuil described the shift in terms that apply beyond his organization: “You wouldn’t want other people in the company to integrate their own APIs. You don’t really want them to integrate their own MCPs either. You want some governance around that.”

The team could now move faster at scale because the foundation was in place, and the business could rely on what IT built rather than routing around it.

Three things to do before shadow MCP creeps in

1. Inventory what already exists. Before you can govern MCP, you need to know what is running. That means identifying every MCP server your organization has deployed or connected, including the ones built by teams outside IT. Assume there are more than you know about.
2. Establish a policy approval path now. The request pattern is already forming. Teams are asking for new MCP connections every week. Without a defined approval path, those requests go somewhere else. Define the process, communicate it, and make it usable. A slow process will be bypassed the same way a missing one will.
3. Make the governed path the easier path. A governed MCP registry, a managed tool catalog, and a clear framework for what IT will support gives teams a reason to work within the system rather than around it. The goal is for IT to out-execute the shadow alternative, not to compete with it on responsiveness.

Shadow IT was hard and expensive to remediate because enterprises waited until the pattern was entrenched. MCP moves faster, reaches further, and carries more risk. The organizations that got shadow IT under control did not do it by padlocking the side door after the fact. They built a front entrance worth using. That is the same work, and the same opportunity, that exists with MCP right now.

---

FAQ

What is shadow MCP? Shadow MCP is any MCP server built or connected outside IT’s oversight. Teams create them to move faster, using whatever credentials the builder has, and they appear nowhere on the asset inventory. It follows the same arc as shadow IT, but with direct access to production systems.

What are the security risks of shadow MCP servers? An agent connected through an ungoverned MCP server inherits the full permissions of whoever set it up. That turns a convenience into an attack surface across CRM, finance, and customer data. A Queen’s University study of 1,000 MCP servers found that a third had critical vulnerabilities.

Why is shadow MCP hard to track? Shadow MCP servers run on individual machines and connect with personal credentials, so they never pass through a system IT monitors. Each one looks like a productivity win, and one working server creates demand across the whole team. By the time IT finds them, workflows depend on them.

How do you prevent shadow MCP? Make the governed path easier than the ungoverned one. Inventory every MCP server already running, including those built outside IT. Publish a lightweight approval path for new connections. Then offer a governed registry and a managed tool catalog, so teams have a reason to work inside the system.

---

More in this series:

• MCP explained: Everything you need to know about MCP
• Security risks: Defusing the MCP ticking time bomb
• User identity: Your MCP service works. But can you answer this question?
• Predictable execution: Drops of determinism: the fix for MCP agents that keep getting it wrong
• Token costs: MCP is making your AI bill unpredictable. Here’s why.
• Observability and audit: Flying blind: Why MCP needs its API management moment
• Governance: MCP governance in the enterprise
• The 2026-07-28 spec: The biggest MCP upgrade yet makes MCP harder to depend on
• IT checklist: Back from Gartner App Summit. Here’s your MCP checklist.