How to Detect Shadow AI and Unsanctioned MCP Servers
Employees are already connecting AI agents to your business systems through MCP servers you don’t know about. This guide gives security and governance teams a practical path to detect shadow AI, inventory unsanctioned MCP servers, and replace the honor system with actual controls.
Key Takeaways
- Shadow AI in the MCP era means employees wiring agents to CRMs, ticketing systems, and internal APIs without IT knowing. OWASP tracks it as MCP09, Shadow MCP Servers.
- Detection starts with endpoint telemetry (EDR/MDM), identity provider audit logs, and network monitoring. Since MCP 2026-07-28, Streamable HTTP requests carry routable headers, which makes network detection far more tractable.
- An MCP gateway with a governed server catalog replaces the “find and block” cycle with an allowlist you administer.
- Blocking MCP entirely doesn’t work. Demand routes around it. Governed access is the only approach that scales.
- MCP Manager by Usercentrics provides the gateway, identity brokering, runtime rules, and audit logging for remote, managed, and workstation (local) MCP servers.
Why Shadow AI Detection Can’t Wait
Numbers tell the story better than any warning could. Cisco’s 2025 AI Readiness Index found that 83% of organizations are already planning to deploy AI agents, yet barely a quarter of them, 24%, can actually control what those agents do with real guardrails and live monitoring. That’s not a small gap. It’s most of the enterprise world moving forward without a seatbelt.
And IBM’s 2025 Cost of a Data Breach Report shows what happens when that gap gets exploited: shadow AI was a factor in 20% of breaches, tacking on roughly USD 670,000 to the average cost, and 97% of organizations hit by an AI-related breach admitted they had no proper access controls in place. This is exactly the blind spot shadow AI thrives in.
What Shadow AI Actually Looks Like in 2026
Shadow AI is no longer someone signing up for ChatGPT with a personal email. The problem has moved down the stack, into the tool-invocation layer between an agent and your production systems.
Agents Connecting to Production Systems Without Approval
Today’s shadow AI problem is MCP servers. Engineers and business users connect AI agents to Salesforce, Jira, GitHub, Google Drive, HubSpot, and internal APIs through MCP. Each connection lets an agent read, and often write, real business data under whatever credential the user pasted into a config file.
OWASP formalized this as MCP09:2025, Shadow MCP Servers: unapproved deployments outside formal security governance, typically spun up for experimentation with default credentials and permissive configurations. OWASP’s test is blunt. If your security team cannot list every active MCP server in the environment, shadow deployments already exist.
The companion risk, MCP08 (Lack of Audit and Telemetry), is a property of the protocol rather than a gap in your tooling. MCP standardizes how a client and server talk and specifies no organization-wide observability. The 2026-07-28 revision removed logging/setLevel and deprecated the Logging feature entirely, naming OpenTelemetry as the migration path. Raw MCP gives you nothing to audit with.
The Scale Compounds Fast
Two structural facts make the exposure compound.
First, a single MCP connection is not a single permission: a server advertises its full tool surface through tools/list, and the agent discovers those tools at runtime, so connecting one CRM server hands over every tool that server exposes.
Second, trust binds to the server name in a config file, not to the code behind it, so a server approved once stays approved after its maintainer ships an update. That is the rug pull, and it is why an inventory taken in March tells you little in September.
How to Discover Which AI Tools Employees Are Using
Discovery requires pulling signals from three layers, because no single layer sees everything.
Step 1: Check Endpoint Telemetry
EDR tools such as CrowdStrike, or MDM platforms like Intune and Jamf, already collect data on what runs on company machines. Local MCP servers use the stdio transport: the AI client spawns the server as a child process and talks to it over standard input and output. There is no network socket to find, so the process tree is the evidence.
Look for:
- AI clients spawning long-running npx, uvx, node, or python processes, which is what a locally installed MCP server looks like from the endpoint. This is worth setting up as a standing EDR alert, because it catches what application control misses.
- AI client installations, including desktop extensions, which bundle local MCP servers.
- Loopback listeners, where locally bound MCP tooling has produced real exposure (see CVE-2025-49596 below).
Browser-based AI usage sits outside the MCP layer entirely. That is EDR and CASB territory, not something an MCP gateway governs.
Step 2: Audit Identity Provider Logs
Your IdP (Okta, Entra ID, Google Workspace) records OAuth consent grants. Search for consent events tied to AI applications and MCP server registrations.
Two caveats matter. MCP’s authorization model historically leaned on OAuth 2.0 Dynamic Client Registration, which created IdP entries automatically, but as of 2026-07-28 DCR is deprecated in favor of Client ID Metadata Documents, so new registrations may not leave the same trail. And servers authenticated with a personal access token, which is how GitHub’s remote MCP server is commonly connected, produce no OAuth consent event at all. Treat IdP logs as a partial signal, never an inventory.
Step 3: Monitor Network Traffic
This is the layer the 2026-07-28 spec materially improved. The legacy HTTP+SSE transport is deprecated, and the current Streamable HTTP transport requires every POST to the MCP endpoint to carry MCP-Protocol-Version and Mcp-Method, plus Mcp-Name on tools/call, resources/read, and prompts/get. Those headers exist so gateways, proxies, and rate limiters can classify MCP traffic without parsing request bodies.
For a SASE or secure web gateway, that makes MCP identifiable by header inspection rather than heuristics. The enforcement pattern is unchanged: deny MCP traffic by default, then allowlist your governed gateway’s URL.
How to Inventory MCP Servers Across the Org
Discovery tells you something exists. Inventory tells you what it is, who owns it, and what data it touches.
Step 4: Catalog What You Find
For each MCP server you discover, document:
- Which system or data source it connects to (Jira, Salesforce, an internal API)
- Whether it runs locally over stdio or remotely over Streamable HTTP
- Its authentication method (OAuth, personal access token, service account)
- Who installed it and which AI client it connects through
- Its full advertised tool surface, not just the tools in use, and which of them write
Do this before you block anything. The inventory is your migration list for the MCP gateway.
Step 5: Classify by Risk
Not all shadow MCP servers carry the same risk. Prioritize by data sensitivity (PII, financial data, health records, intellectual property), write capability judged from the tool surface rather than the integration’s name, credential type, since a shared service account destroys attribution, and whether the server runs on a managed device.
How to Block Unsanctioned MCP Servers
Blocking is where most organizations get stuck, because the obvious approach doesn’t work.
Why “Just Block MCP” Fails
An agent with general-purpose capability reaches the same data by another route. Deny it a Jira MCP server and it can still drive a browser, call a REST API, or run a shell command, because those capabilities come from other tools in its context. Blocking one transport removes the audit trail, not the access. It also pushes demand onto paths with less visibility, since a blocked server simply vanishes from the user’s client with no explanation.
Step 6: Set Up a Governed Alternative
The approach that works is to make the sanctioned path easier than the unsanctioned one: an MCP gateway with a catalog of approved servers, provisioned allowlist-by-default. Teams connect to one URL. The gateway authenticates the caller, decides which servers and tools they may reach, applies rules, forwards the request under the correct brokered identity, inspects the response, and logs every hop.
Client-side controls make that path the only one. In Claude, an org owner removes direct connectors under Organization settings and adds the gateway URL as a custom connector. For Claude Code, push allowedMcpServers with allowManagedMcpServersOnly: true, matching by URL rather than server name, since names are user-chosen labels. Cursor Enterprise admins create an MCP allowlist containing only the gateway.
Step 7: Enforce with Layered Controls
A gateway governs what passes through it, so the surrounding layers exist to ensure traffic goes through it: EDR and MDM to catch unauthorized server processes, network controls to deny non-gateway MCP traffic, client admin settings to disable desktop extensions, and SCIM so access is revoked at offboarding.
No gateway can govern an MCP client on an unmanaged personal device. Static egress IPs close part of that gap: lock sensitive upstreams to the gateway’s egress addresses, and bypassing it stops working rather than merely violating policy.
Real-World Examples: Why a Gateway Would Have Changed the Outcome
The steps above show how to detect and govern shadow MCP servers before they become a problem. The examples below show what happens when that governance isn’t in place and what an MCP gateway would have changed.
In each case, the incident wasn’t caused by a single failure, but by the same blind spot shadow AI always exploits: no one had visibility into what was running, which server was calling what, or under whose identity. A gateway closes exactly that gap, putting every server, every call, and every identity under one governed point of control instead of leaving them scattered across laptops, config files, and package registries nobody is watching.
- A malicious server in the package registry: In September 2025, the npm package postmark-mcp shipped a version that silently BCC’d every email it processed to an external domain (Snyk), the first tracked in-the-wild malicious MCP server. Nothing about its install path distinguished it from a legitimate package.
- A developer tool as the entry point: CVE-2025-49596 in Anthropic’s MCP Inspector scored CVSS 9.4 because the proxy accepted unauthenticated requests from any origin and would spawn arbitrary commands over stdio, so a visited web page was enough to reach it (Oligo Security; fixed in 0.14.1). That is the shape of local MCP risk: the exposure sits on the workstation, where neither a network gateway nor an IdP sees it.
- Trust bound to a name, not to code: CVE-2025-54136 in Cursor formalized the rug pull, where a server approved once stays approved after its behavior changes. An allowlist pinning only a server name inherits that problem.
In each case the failure precedes the attack: the deployment was never inventoried, so nothing was positioned to notice the change.
Governed AI Beats Blocked AI
The organizations pulling ahead are not the ones that locked MCP down. They are the ones that found a way to say yes to it with controls in the path. That means treating shadow AI and unsanctioned MCP servers as a visibility problem first: discover what’s already running, and bring it into a governed catalog.
MCP Manager by Usercentrics is built for exactly that: a gateway that brokers identity to attribute every call, applies rules to keep sensitive data out of models, and provides the audit trail the protocol doesn’t offer on its own.
The alternative isn’t safer, just less visible. The demand for AI-connected workflows doesn’t go away when you block it, it just goes underground.
FAQ
What is shadow AI in the context of MCP?
Shadow AI refers to employees connecting AI agents to business systems through unsanctioned MCP servers without IT approval. OWASP catalogs it as MCP09, Shadow MCP Servers. The result is unmonitored data flow between agents and systems like CRMs, code repositories, and internal APIs.
How do I detect shadow AI and unsanctioned MCP servers?
Combine endpoint telemetry, identity provider OAuth logs, and network monitoring. On endpoints, alert on AI clients spawning long-running npx, uvx, node, or python processes, which is what a local stdio server looks like. On the network, MCP traffic is identifiable by the MCP-Protocol-Version and Mcp-Method headers the current spec requires.
Can I just block MCP to prevent shadow AI?
Blocking removes the audit trail rather than the access, because a capable agent reaches the same systems through a browser, an API, or a shell. A governed path that is easier to use works better than a ban.
What’s the difference between local and remote MCP servers?
Remote servers run over the network using Streamable HTTP. Local servers run on the user’s machine over stdio, spawned as a child process by the AI client. Most gateways govern only remote servers, leaving local ones invisible. MCP Manager is built to close that gap, bringing workstation servers under the same governance as remote ones.
How does an MCP gateway help with shadow AI detection?
A gateway centralizes agent-to-tool connections behind one URL, turning an unobservable mesh into a single control point. It provides a governed catalog of approved servers, brokers a real identity per call, applies rules inline, and logs every hop for export to your SIEM.
Does MCP Manager work with Claude Enterprise?
Yes. A Claude org owner removes direct connectors in Organization settings and adds the MCP Manager gateway as a custom connector, making it the only permitted connection. For Claude Code, administrators push allowedMcpServers with allowManagedMcpServersOnly: true, matched by URL.
How quickly can I inventory existing MCP servers?
With EDR and MDM already deployed, initial discovery is a matter of days. Cataloging and risk-classifying each server takes longer and depends on org size. Once connections route through a gateway, usage data is immediate, though a gateway reports only what passes through it, not what has yet to be migrated.
