Shadow MCP is the agent-era version of shadow IT. MCP servers are npm packages and GitHub repos — anyone can publish one, and any engineer can add one to their Claude Desktop, Cursor, or Claude Code configuration in seconds. The moment they do, that server holds a live credential to whatever it connects: corporate Slack, Google Drive, a production database, an internal API. No one approved it, security doesn’t know it exists, and it now sits inside your trust boundary. That is shadow MCP — unapproved, unmanaged MCP servers running against corporate systems.
With unsanctioned SaaS, there is usually something to catch: an OAuth grant in your identity provider, an admin console, a login your CASB can see. Shadow MCP has none of that.
| Shadow SaaS | Shadow MCP |
|---|---|
| OAuth consent screen you can review | No consent screen — a token pasted into a config file |
| Admin console / directory | No console — nothing central to look at |
| Login events, audit trail | No audit trail on the machine |
| Discoverable via IdP / CASB | A local JSON file on a laptop |
Because the whole thing lives in a config file on an endpoint, the only reliable place to see it is on the endpoint.
| Threat | What happens |
|---|---|
| Credential harvesting | A malicious server exfiltrates the tokens it’s handed |
| Typosquatting | A server named to impersonate a legitimate one (slack-mcp vs slack_mcp) |
| Rug pulls | An approved server later mutates its tool descriptions to do something else |
| Tool poisoning | Malicious instructions hidden in the tool description the model reads |
These aren’t hypothetical — they follow directly from the fact that MCP servers are unvetted third-party code with standing access. See rug pull attacks and prompt injection for how two of them work in detail.
This is the crux. An MCP gateway is a real control — it inspects the traffic that passes through it and can block, redact, or mask data on MCP tool calls. But its registry only governs traffic through the gateway. If an employee configures their client to talk to a server directly, that traffic never reaches the gateway, and the gateway never knows the server exists. A cloud gateway governs the agent path it sits on; it cannot see a server it isn’t in front of. Closing that gap requires seeing the configuration on the machine, not the traffic on the wire.
MCP clients register their servers in local config files. To inventory shadow MCP by hand, you’d look at:
| Client | Where the config lives |
|---|---|
| Claude Desktop (macOS) | ~/Library/Application Support/Claude/claude_desktop_config.json |
| Claude Desktop (Windows) | %APPDATA%\Claude\claude_desktop_config.json |
| Cursor | project and user mcp.json / settings |
| Other clients | a per-client JSON block listing each server’s command, args, and env (tokens) |
Each entry names a server, its launch command, and the environment variables — often including the credential. Doing this manually across a fleet doesn’t scale, which is the whole point of automating it on the endpoint.
Strac closes the gap the gateway can’t. The endpoint agent reads the MCP client config files on each machine and builds a live inventory of every registered server — sanctioned or not — regardless of whether its traffic ever passes through a gateway. From there you allow or deny servers by policy, flag typosquatted and impersonating names, and get an audit trail of what’s connected where. Follow Strac’s governance model for MCP — See, Control, Protect, Prove: see every server, control which are allowed, protect the data flowing through them, and prove it for an audit.
And for the servers you do sanction, Strac protects the data moving through them: it redacts PII, PHI, PCI, and secrets on MCP tool calls, and — because it also runs on the browser and endpoint — it protects the human path (what employees paste and upload) that no gateway can see. See MCP DLP, endpoint DLP, and the MCP integrations for the full picture.
Shadow MCP is unapproved Model Context Protocol servers that employees add to AI clients (Claude Desktop, Cursor, Claude Code) without review. Each one holds a live token to a corporate system, with no OAuth consent screen, admin console, or audit trail - the config is just a local JSON file.
No. A gateway only governs traffic that flows through it. If an employee points their client directly at a server, that traffic bypasses the gateway entirely and the gateway never sees the server. Detecting it requires reading the client config on the endpoint - which Strac's endpoint agent does.
Shadow SaaS usually leaves a trail - an OAuth grant, an admin console, a login. Shadow MCP leaves none of that. A token pasted into a local config file gives a third-party server standing access with nothing central to review.
They're listed in client config files (for example claude_desktop_config.json). Manually that means auditing each machine's JSON; at scale, Strac's endpoint agent reads those configs automatically and inventories every registered server.
It reads MCP client configs on the endpoint to inventory every server, lets you allow or deny each by policy, flags typosquatted and impersonating servers, and protects the data on sanctioned servers with DLP - See, Control, Protect, Prove.
Shadow MCP is app-allowlisting for the agent era, and it’s the one control a gateway-only vendor structurally cannot ship — because the servers live in config files, not in gateway traffic. Strac sees them on the endpoint, lets you allow or deny each, and protects the data on the ones you keep. Book a demo to inventory the MCP servers running in your environment.
.avif){kind=icon}
.gif)
.webp)
