Product
Shadow MCP detection and governance
Speakeasy Team
June 16, 2026 - 3 min read
Connecting AI to your data via MCP is a powerful productivity boost. It also introduces a new surface area, which can be used as an attack vector. Malicious servers can hide instructions in their tool definitions that the agent reads and acts on, a technique known as tool poisoning.
In response, companies are building internal registries of approved servers for their employees. But a registry only works if you have a reliable way to detect and block the servers that shouldn’t be used, and the servers you approved are never the only ones your team will reach for. Shadow AI usually isn’t malicious. It’s inevitable that someone will need a capability not in the registry, find a useful server elsewhere, and wire it up. But from a security standpoint, it’s access you can’t see, against systems you don’t control, which is a security risk.
Banning it doesn’t work; people route around the ban. The fix is a workflow that works with your team instead of against it: detect the shadow AI in use, evaluate the risk of each server, and quickly unblock the users who need access. That’s what Speakeasy shadow MCP detection does, AI governance that meets developers where they already work.
See it first
Speakeasy’s runtime hooks sit in the path between the agent and the MCP servers it reaches for. When an agent connects to a server that isn’t part of your sanctioned setup, the call is recognized as shadow MCP usage, surfaced by the server’s URL, its host, or its resolved identity. You get a record of what your agents are actually reaching for.
Govern it with rules, not bans
Once a shadow server shows up, you decide what happens next. Access rules let you allow or deny shadow MCP usage by URL, by host, or by server identity, scoped to an organization or a single project, complementing the network-level access controls already in place. When more than one rule matches, deny wins, so the safe default holds.
So the production database server someone discovered gets denied. The internal docs server that’s genuinely useful gets added to the allowlist. The decision is explicit, recorded, and applied at runtime for every call that follows. Enforcement fails closed: if a rule can’t be evaluated, the call is blocked rather than waved through.
Give blocked developers a way forward
A block with no recourse is just friction, and friction is what drove people to shadow servers in the first place. When a call is blocked, supported clients like Claude, Cursor, and Codex can surface a request-access link. The developer clicks it, signs in, and the request lands in the dashboard for an admin to review.
The link carries a signed token in the URL fragment, so it never shows up in ordinary request logs. Approval is org-admin gated. An admin reviews the request, approves or denies it, and an approval can create the access rule that lets future calls through. The developer gets unblocked through a path you control instead of a workaround you’ll never find out about.
Get started
Shadow MCP detection and governance live under the Access section of your Speakeasy dashboard. Turn on detection, watch the risk overview for the servers your agents are reaching for, and start building allow and deny rules from what you actually see. The request-access flow is on by default for supported clients, so blocked developers always have a door to knock on.
Worried about what your agents are connecting to? Book time with our team and we’ll help you map your shadow MCP usage.