Shadow MCP Servers: Visibility and Control at the Gateway

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. 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 2025 assessment found that hundreds of publicly reachable MCP servers were misconfigured, and researchers have documented "rug pull" attacks where a server changes its tool definitions after approval. 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.

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.

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.
• MCP tool groups: Enterprise teams can assemble curated tool collections, or virtual MCP servers, and attach them to virtual keys, teams, or users, with the policy enforced at request time.
• Authentication: Bifrost supports OAuth 2.0 with automatic token refresh and PKCE, so tool connections use scoped, revocable credentials rather than long-lived secrets.
• Federated auth: Existing enterprise APIs can be turned into governed MCP tools without glue code, keeping internal systems behind the same policy layer.

Because Bifrost is the MCP gateway rather than a wrapper around one, tool calls inherit the same routing, budgets, and audit logging as model traffic.

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. Teams can finally answer "what MCP servers are running on our fleet?" with real data.
• 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. Bifrost Edge is currently in alpha, and teams register to be onboarded.

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.

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 maintains immutable audit logs suitable for SOC 2, GDPR, HIPAA, and ISO 27001 reporting, and Bifrost Edge extends that same logging to endpoint tool calls that would otherwise never appear in a central system.

For teams standardizing on the MCP gateway, Bifrost also documented how centralizing tool connections cut token costs; the MCP gateway analysis covers access control, cost governance, and a 92% reduction in token costs at scale. 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 is why Bifrost is built for enterprises and large fleets. Bifrost Edge deploys fleet-wide 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 deployments, VPC isolation, and on-prem infrastructure, 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.

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.