How to Avoid Shadow MCP Servers in the Enterprise

By some estimates, as many as 80% of company employees use shadow IT. Shadow IT is the unsanctioned use of internal technologies, often picked up by employees out of haste and to avoid red tape. As such, these tools never went through traditional tool acquisition or security checks, and their ongoing use is unmonitored.

Shadow IT can pose risks related to authentication issues, supply chain risks, undetected bugs, and third-party vulnerabilities. And lately, shadow Model Context Protocol (MCP) servers are emerging as a new type of shadow IT.

Below, we’ll explore how the proliferation of MCP is causing a new shadow IT dilemma, and consider ways to prevent this from turning into a nightmare at an enterprise scale.

Unknown MCP usage carries classic shadow IT risks: unknown tool provenance, untracked costs, and increased threat vectors. Solving it will require a multi-step process involving maintaining a proper inventory, introducing monitoring, reviewing permissions, and adding new governance layers when necessary.

What are shadow MCP servers?

Shadow MCP servers can arise when the use of MCP servers becomes completely ungoverned within an organization. These servers are often quickly configured by engineers within agentic coding platforms and immediately integrated without the typical enterprise approvals or security reviews.

It’s easy for shadow IT to emerge when there is much excitement and hockey-stick adoption curves. And MCP is no exception.

Developer interest in coding agents is increasing dramatically, leading to the quick adoption of new tools like MCP, a standard protocol to empower agents with connectivity to external APIs, databases, and SaaS tools. MCP especially shines as a way to bring more context to engineering efforts.

The top 20 most popular MCP servers alone generate over 180,000 monthly searches, according to MCP Manager. That figure measures search interest rather than actual usage, but it points to strong and growing developer attention.

Most of these are remote servers that connect with popular SaaS, developer tools, or databases. Some examples include Figma MCP, GitHub MCP, Context7 MCP, Cursor MCP, Supabase MCP, and Notion MCP.

Why shadow MCP servers pose a risk

Shadow MCP servers pose a possible risk to enterprises for a few reasons. First, the lack of ongoing monitoring or awareness amplifies cybersecurity threats, since you can’t secure or audit what you don’t know.

Shadow MCP servers that aren’t registered and sitting beyond corporate control are beyond security monitoring and coverage for things like known vulnerabilities, misconfigurations, and emerging exploits.

Each MCP server is unique, and their permissions are sometimes wide and varied. This sets organizations up for not only privilege drift, but possibly unauthorized actions being autonomously orchestrated by large language model (LLM) based agents, which are known to act unpredictably. Shadow servers with unknown access amplify this problem.

Lastly, the servers themselves often have unknown provenance, posing supply chain security risks. Data already shows that many MCP servers are unvetted: in late 2025, research from Clutch found that within a typical 10,000 member organization, 15% of employees are running an average of two MCP servers each. And of these MCP servers, 38% are unofficial implementations from “unknown authors.”

5 techniques to avoid shadow MCP servers

Thankfully, there are some emerging techniques that IT and security leaders can implement in order to safeguard their MCP adoption at scale. Together, they should help decrease the number of shadow MCP servers, and prevent future ones from emerging as well.

1. Catalog your inventory

The first strategy is similar to avoiding shadow tools and APIs in general: create an internal IT asset inventory. For example, MCP registries often hold information about approved-for-use MCP servers, including metadata, tool descriptions, and an approval process for adding new servers.

Having an inventory of your technical assets benefits discoverability for agents. It also improves organizational awareness, promotes tool reusability and compliance, and provides more visibility to security teams.

Getting this together might take some effort to ask developers about their tools and requirements, but it is a necessary first step to limiting shadow MCP servers.

2. Set up agentic traffic monitoring

Similar to how a lack of API monitoring leads to shadow APIs, a lack of ongoing MCP visibility leads to MCP security gaps. At scale, discovering your current MCP inventory may require automated discovery mechanisms. Some runtime network tools can monitor corporate firewalls for MCP signatures in order to enhance discovery.

A 2025 study of more than 2,000 cybersecurity leaders found that 73% had experienced a security incident because assets in their IT infrastructure were not managed or simply unknown.

By actively monitoring agent traffic and logs, you can reduce this risk with the visibility required to find (or prevent) unknown MCP servers within an organization. The challenge here will be producing observability metrics that are granular enough to distinguish MCP-generated traffic versus API calls that are human or machine generated.

3. Avoid privilege drift

It’s not just shadow servers, it’s shadow privileges that are the real risk of shadow MCP servers. Ideally, agents should follow the principle of least privilege, meaning that tool access and permissions should be curated to reflect the day-to-day role and privileges of the operator, and nothing else. But this is rarely the case in practice.

In 2026, joint research from Oso and Cyera found agentic security flying in the face of least privilege: across 2.4 million workers and 3.6 billion application permissions, 96% of granted permissions went completely unused over a 90-day window. Nearly one in three workers can modify or delete sensitive data, too.

Where MCP is concerned, unnecessarily overpermissioned tool access could lead to sensitive data leakage or deletion, accidental credential sharing, and more. One answer, at the very least, is to default to read access only for MCP tools, then incrementally add more sensitive privileges when needed.

But at enterprise scale, this will require scoped MCP access that is curated to reflect different operator departments or roles. By minimizing privileges, you reduce the chances of side-channel attacks, tool poisoning, sensitive data leakage, and other MCP security vulnerabilities.

4. Set internal governance standards

Internal practices are nothing if they’re not codified and enforced going forward. Therefore, it’ll probably be necessary to introduce some form of internal standards to track MCP use within an enterprise to avoid unapproved use. This could take the form of a formal mandate or group that governs what capabilities AI agents can access, including skills, APIs, or MCP tools.

Such an internal compliance procedure is typically top-down, led by the CISO, CTO, or CIO, depending on company size and organizational makeup, with support from enterprise architecture, platform engineering, AppSec, or AI governance teams. It might be wrapped into an existing API governance function, platform engineering program, or AI center of excellence.

By folding MCP into the grasp of enterprise security governance, you signal that it’s another tool and needs to be treated as such. This helps set clear expectations for adding, vetting, and approving new MCP tools.

Not only does this provide standard operating procedures to an evolving area, it could help avoid similar problems down the road as agentic AI progresses in software engineering and beyond.

5. Use an MCP gateway

Lastly, there is a strong case for incorporating new MCP infrastructure layers to help organizations mature their internal use of MCP. Of these, MCP gateways have emerged as a central access point to control MCP use. They can either directly or indirectly enable the action items above to help avoid shadow MCP server use:

• Inventory and discovery: Add approved MCP servers to your gateway so that agents only access vetted tools.
• Observability and vetting: Enable always-on monitoring for visibility into MCP tool calls and compliance concerns.
• Traffic routing: Generate highly scoped MCP servers that represent least-privilege access for various consumer types or agents.
• Governance and control: All in all, an MCP gateway is a way to organize how an organization uses AI and a focal point to consolidate governance initiatives.

A number of MCP gateways have emerged across the market, ranging from open-source options to vendor-backed solutions. These include Composio MCP Gateway, Lunar.dev MCPX, Portkey MCP Gateway, TrueFoundry MCP Gateway, and Zuplo MCP Gateway, which is built for governing agentic tool access, MCP tool routing, authentication, virtualized servers, and policy enforcement.

Preventing shadow MCP servers

Developers are already using MCP in their workflows. Zuplo’s own 2026 State of MCP report found that 70% of developers using MCP have 2 to 7 MCP servers configured.

With MCP support growing across agent platforms, frameworks, and cloud tools, this trend shows no signs of slowing down. What’s alarming for security engineers and enterprise architects is the speed at which this has occurred.

This sudden rise requires some sort of deliberate response before it gets out of hand, especially as privilege drift can balloon exponentially in multi-agent systems. Fortunately, avoiding shadow IT has a number of historical precedents and strategic tactics that can be transferred to MCP.

By cataloging existing inventory, monitoring for new shadow use, and aligning the organization around standard controls and tools, enterprises can better reap the rewards of MCP while maintaining a structured approach to integrating it into the corporate IT fabric.