Shadow MCP: the AI governance problem hiding in plain sight

Most enterprises believe they have a handle on their MCP deployments. They’re usually wrong, and often by an order of magnitude.

Here’s what you’ll learn in this post:

• Why shadow MCP is already a bigger problem than most engineering leaders realize
• How the growth of AI agent tooling is creating governance debt faster than security teams can address it
• Why an MCP registry is the foundational fix — and what good governance looks like in practice
• How Stacklok gives enterprises the visibility and control to get ahead of this problem

The number you think you know is wrong

We recently spoke with an engineering leader at a large software company and asked them how many MCP servers they were running. They were confident: four or five. A simple discovery script told a different story. The actual number was closer to 30.

Those undiscovered servers weren’t a result of negligence or malicious intent. They were connected to production databases, customer data systems, and third-party SaaS APIs with no catalog, no governance policy, and no organizational visibility. Nobody was being reckless. There just weren’t any systems in place to track this.

That gap between perceived and actual MCP deployment is shadow MCP. And it’s fast becoming one of the most consequential governance problems in enterprise AI.

Why shadow MCP is spreading so quickly

Model Context Protocol (MCP) gives AI agents a standardized way to connect to tools, data sources, and services. The productivity gains are real, and adoption is accelerating. Thousands of community and vendor-built MCP servers exist today, and internal teams are building their own on top of that. Developers have good reason to move fast.

But enterprise governance frameworks aren’t keeping up. And the result looks a lot like what happened when public cloud emerged: sprawl arrived before the controls did. Organizations that moved fast without infrastructure still have teams quietly cleaning up shadow IT deployments years later.

Shadow MCP is the same pattern, compressed into a much shorter timeline.

The consequences show up in three distinct ways.

Discoverability gaps. Without a catalog, multiple teams independently build the same integrations. You end up with the same tool running in different ways across different teams, producing inconsistent behavior and duplicating effort. Platform teams become a human lookup table, fielding constant questions about what exists and how to connect to it instead of shipping.

Shadow MCP deployments. Security teams are discovering MCP servers after the fact and scrambling to remediate retroactively. This is a genuinely difficult problem to solve late. It creates friction between teams, slows down response windows, and forces the kind of reactive security work nobody wants.

Compliance exposure. For regulated industries (e.g. financial services, healthcare, defense) the ability to answer “what data can your AI agents access?” is not optional. Without a system of record, the honest answer is: we don’t know. That answer doesn’t hold up with auditors.

The fix is the same one that worked for containers

This inflection point has a historical parallel. Early container adoption looked exactly like this: sprawl, shadow deployments, duplication, security teams playing catch-up. The organizations that built the right infrastructure early, including registries, operators, and policy engines, came out ahead. The ones that didn’t are still cleaning up.

The solution for MCP is the same. It starts with a registry.

An MCP registry is a catalog of MCP servers: a single system of record for what exists, what’s approved, and what’s authorized for use in your organization. It delivers value across four areas:

Discovery. Developers and agents can find the right tools without opening a ticket or asking in Slack. Platform teams stop being a bottleneck and start doing more valuable work.

Governance. Admins and security teams can define which servers are approved, who can use them, and how. They are moving policy out of spreadsheets and word of mouth and into something auditable and enforceable.

Trust and provenance. Every registry entry carries metadata: publisher, version, approval status, security signatures. You can answer the questions “where does this come from and who approved it?” in seconds, not days.

Lifecycle management. When a server is updated, patched, or retired, the people using it need to know immediately. Without this, deprecated servers keep running and security patches don’t propagate.

What this looks like with Stacklok

Stacklok was founded by one of the co-creators of Kubernetes, and the team has lived through this exact pattern before with containers, and that platform-centric thinking shapes how we approach MCP governance.

The Stacklok MCP Platform includes a Registry Server that serves as your organization’s single source of truth for approved MCP servers. It’s designed around a few key principles.

Multi-source aggregation. In practice, enterprises pull servers from multiple places: trusted public registries, curated internal lists tracked in a Git repository, and shared deployments running in Kubernetes. The Stacklok registry pulls all of this into a single searchable catalog.

Authentication and authorization. The registry plugs into your existing identity providers, so access control is integrated.

Virtual registries. You can create role-based views from multiple upstream sources, tailored to different teams or workflows, without duplicating data across registries.

Automatic discovery. Stacklok’s Kubernetes operator discovers MCP servers running in your cluster and surfaces them in the catalog automatically, including metadata like available tools, connection URLs, and approval status.

The practical effect: a developer looking for a database connector or an internal API server can find it in seconds with all the context they need. No Slack thread required. No Jira ticket. And in an enterprise deployment, that discovery flow is wrapped with an authentication step through your identity provider, so governance and velocity aren’t in tension.

Make the safe path the easy path

Here’s the principle that drives how we think about this: the harder you make something to do, the more likely someone is to work around the controls. If finding an approved MCP server takes three days and a support ticket, developers will use the one they found on GitHub. If it takes ten seconds, they won’t have a reason to.

That’s the goal of an MCP registry: make the governed path the path of least resistance. The organizations that build this infrastructure now are the ones that will be able to scale AI agents safely and quickly. The ones that don’t will spend the next few years discovering what’s already running in their environment and trying to unwind it.

---

Want to see what Stacklok can do for your organization? Book a demo or get started right away with ToolHive, our open source project. Join the conversation and engage directly with our team on Discord.