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
- 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.
- 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.
- 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.
