Shadow MCP Servers: Visibility and Control at the Gateway

TL;DR

• Shadow MCP servers are Model Context Protocol connections wired into AI apps on employee machines without organizational visibility, and they can read files, call internal APIs, and take actions on the user's behalf.
• The exposure is measured, not theoretical: a July 2025 internet-wide scan by Knostic found 1,862 MCP servers exposed on the public internet, and all 119 it sampled listed their tools to anyone who asked.
• The Bifrost AI gateway is the policy engine: every tool call routed through it is authenticated, filtered against per-key policy, and logged.
• Bifrost Edge, currently in alpha, extends that same policy to the endpoint, inventorying the MCP servers configured inside AI apps across the fleet and enforcing per-server allow and deny decisions on the device itself.
• Approvals are deduplicated across the fleet, so the same server seen on many machines is judged once and the decision applies everywhere at each device's next check-in.

Most organizations cannot answer a basic question: which Model Context Protocol (MCP) servers are running inside the AI tools their employees use every day. A developer wires a filesystem MCP server into Claude Desktop, a data analyst connects a database server to Cursor, and a support engineer adds a third-party API server to a coding agent, all without a policy layer in between. These are shadow MCP servers: tool connections that can read files, call APIs, and take actions, configured on endpoints that security teams cannot see. Bifrost, the open-source AI gateway built in Go by Maxim AI, is the control plane that closes this gap, and Bifrost Edge extends that control to every machine so tool calls are governed where they actually happen.

What are shadow MCP servers

Shadow MCP servers are Model Context Protocol servers configured inside AI applications without organizational visibility or governance. MCP is an open standard that lets AI models discover and call external tools, from file systems and databases to internal APIs. The same dynamic is covered from the registry side in discovering and governing MCP servers. When a user adds an MCP server to an app like Claude Code or Cursor, that server can execute actions on the user's behalf, and most organizations have no record that it exists.

The security exposure is concrete. A July 2025 internet-wide scan by Knostic identified 1,862 MCP servers exposed on the public internet, and every one of the 119 it manually sampled granted access to internal tool listings without authentication, meaning anyone could enumerate the tools they exposed. The National Security Agency's guidance on MCP and documented CVEs, including CVE-2025-49596 (a CVSS 9.4 arbitrary command execution flaw in MCP Inspector), show that ungoverned tool connections are an active attack surface, not a theoretical one.

Why shadow MCP servers are a governance blind spot

A gateway only governs the traffic configured to flow through it. MCP connections made directly inside desktop apps and coding agents bypass any central policy, which creates four specific problems:

• No inventory: Teams cannot list which MCP servers are configured, on which machines, or across how many devices.
• No access control: A server that can read the local file system or call an internal API runs with whatever permissions the user's tool grants it.
• No audit trail: Tool calls that move data to external services leave no centralized record for SOC 2, GDPR, or HIPAA reporting.
• No revocation: When a server is found to be malicious or misconfigured, there is no central switch to stop it on every device.

Each gap closes at a different layer, and the two work together:

Bifrost addresses these through a two-part model: the MCP gateway as the policy engine for tool connections, and Bifrost Edge as the layer that enforces those policies on the endpoint. Used as an MCP gateway, Bifrost centralizes tool connections, authentication, and governance across every connected server. The same argument from the shadow IT angle appears in ungoverned MCP servers and how a gateway contains them.

How Bifrost governs tool calls at the gateway

Bifrost acts as both an MCP client and an MCP server, sitting between AI applications and the tool servers they connect to. Every tool call routes through the gateway, where it is authenticated, filtered, and logged. This gives platform teams a single control point for MCP traffic instead of a policy scattered across hundreds of individual app configurations.

Core controls at the gateway include:

• Tool filtering per virtual key: Virtual keys are the primary governance entity in Bifrost, and administrators can control which MCP tools are available to each key, team, or customer through MCP tool filtering.
• Virtual MCPs: Curated bundles of tools drawn from one or more MCP servers, each served at its own endpoint and attached to the virtual keys that should reach it. The feature is part of open-source Bifrost and requires governance to be enabled; Bifrost Enterprise adds scoping through access profiles and project assignment. It was previously called MCP Tool Groups.
• Authentication: Bifrost supports OAuth 2.0 with automatic token refresh and PKCE, so tool connections use scoped, revocable credentials rather than long-lived secrets.
• Delegated identity: With token exchange, each caller's identity-provider token is swapped for a short-lived token scoped to the upstream MCP server, so a tool call reaches an internal system as the person who made it and Bifrost never stores a per-user credential.

Because Bifrost is the control plane for MCP servers rather than a wrapper around one, tool calls inherit the same routing, budgets, and audit logging as model traffic. Teams consolidating several servers behind one endpoint can follow connecting multiple MCP servers through one gateway.

How Bifrost Edge extends control to the endpoint

The gateway governs the tool calls that route through it. Bifrost Edge is the layer that makes sure the MCP servers configured on every laptop actually route through the gateway in the first place. Edge runs on each machine and inventories the MCP servers configured inside AI apps, then enforces the gateway's allow/deny decisions on the device.

Edge closes the shadow MCP gap through three capabilities:

• Fleet-wide MCP inventory: Edge discovers the MCP servers configured inside AI apps and builds a live inventory of which servers are configured, where, and across how many devices. That gives a platform team a documented answer to which MCP servers are configured across the fleet, rather than an estimate.
• Per-server allow/deny, enforced on the device: Administrators make per-server decisions in the admin console, and a denied server cannot be used even by an app that had it configured before the policy existed. The decision is enforced, not advisory.
• Deduplicated approvals across the fleet: The same MCP server on many machines appears once in the approvals dashboard; approve or deny it once and the decision applies everywhere at the next device check-in.

MCP discovery covers the major AI apps that support the protocol today, including Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex, and Cursor, with the current list published under supported applications. Edge also governs which AI apps are allowed at all, so a blocked app is stopped before any data leaves the machine rather than merely having its tools restricted. Bifrost Edge is currently in alpha. Teams register to be onboarded rather than installing it themselves, so the capabilities described here are what Edge does for onboarded fleets, not a generally available release.

How does Edge decide which MCP servers to block?

Administrators define the policy centrally, and Edge enforces it on each device. Newly discovered servers enter a pending state, where admins can configure whether pending apps and MCP servers are allowed or blocked while awaiting review. Approved servers run normally under governance; denied servers are stopped on the device.

Does blocking a server require touching each machine?

No. Policy is managed centrally in the devices dashboard, and Edge picks up changes automatically. Denying an MCP server once applies the decision across the fleet at each agent's next check-in, with no per-device work.

What happens to data before a tool call executes?

Because Edge routes endpoint AI traffic through Bifrost, guardrails configured at the gateway apply before a prompt reaches a model and before a response returns. Sensitive content such as secrets or PII is caught before it leaves the machine, because Edge applies the gateway's guardrails to traffic from every governed app rather than to one integration at a time. Governing MCP servers inside a single agent follows the same pattern, as in adding and governing MCP servers in Claude Code.

Building an audit trail for MCP tool calls

Every tool call routed through Bifrost is logged, which turns MCP activity from an invisible risk into a reviewable record. This matters for regulated teams that must demonstrate control over where data goes. Bifrost Enterprise records audit logs of administrative activity as HMAC-signed, verifiable events with configurable retention and archiving to object storage, and Bifrost Edge extends request logging to endpoint tool calls that would otherwise never appear in a central system.

Centralizing tool connections also creates room to cut what they cost. Code Mode replaces the practice of loading every tool definition into the model's context with four meta-tools and a sandbox that orchestrates the rest, which reduced input tokens by 92.8% at 508 tools across 16 MCP servers. The MCP gateway analysis covers that result alongside access control and cost governance. Governance and cost control run on the same control point.

Enterprise deployment and rollout

Shadow MCP governance only works if it reaches every machine, which makes distribution the deciding factor in whether a policy is real. Bifrost Edge is therefore deployed the way other managed software is, rather than by asking each user to install and configure it. Once a fleet is onboarded to the alpha, Edge rolls out through existing device management platforms, including Jamf, Microsoft Intune, Kandji, Omnissa Workspace ONE, and JumpCloud, using a managed configuration that points each machine at the organization's Bifrost. The managed configuration delivers only non-sensitive connection settings; identity and keys come from the user's single sign-on.

For regulated industries and strict enterprise requirements, Bifrost Enterprise supports air-gapped and self-hosted deployments alongside in-VPC isolation, so MCP governance and audit logging stay inside controlled environments.

Teams evaluating the broader control surface can review the governance capabilities that Edge enforces at the endpoint.

Frequently Asked Questions

How do I find out which MCP servers my team is running?

Not from the gateway alone, because a server wired directly into a desktop app never reaches it. Bifrost Edge reads the MCP configuration of supported AI apps on each machine and reports back a fleet-wide inventory: which servers are configured, on which devices, and how many. For most organizations that inventory is the first record of its kind.

Can a shadow MCP server be blocked without uninstalling the AI app?

Yes. App governance and MCP governance are separate decisions. An app can stay allowed and fully governed while one of its MCP servers is denied, and the denial is enforced on the device rather than requested from the app. A server that was configured before the policy existed is covered by the same enforcement.

Does governing MCP servers slow down tool calls?

Bifrost adds 11 microseconds of overhead per request at 5,000 requests per second in published benchmarks, against a tool call that already involves a network round-trip to the server doing the work. The governance checks are policy lookups rather than model calls, so they are not where the time goes.

What is the difference between shadow AI and shadow MCP servers?

Shadow AI is the broader category: any AI tool used without a policy layer, including chat apps and browser assistants. Shadow MCP servers are the subset that can act rather than only answer, because an MCP server does not just receive a prompt; it executes actions such as reading files or calling internal APIs. The CISO view of end-to-end AI governance covers the wider surface.

Getting started with Bifrost

Shadow MCP servers are ungoverned tool connections that expand the enterprise attack surface, and they cannot be controlled from inside individual apps. Bifrost solves this at two levels: the AI gateway as the policy engine for MCP tool calls, and Bifrost Edge as the endpoint layer that discovers shadow MCP servers, enforces per-server decisions on the device, and brings every tool call under the same audit logging and guardrails. To see how Bifrost gives your team visibility and control over MCP tool calls across the fleet, book a demo with the Bifrost team.