Bifrost Edge

Shadow MCP: The Ungoverned AI Tools Risking Your Data

Bifrost governs shadow MCP by inventorying every ungoverned MCP server configured across your fleet and enforcing allow or deny policy on each device.

Shadow MCP is the set of Model Context Protocol (MCP) servers that employees connect to their AI tools without any security or governance layer in between. These servers can read local files, call internal APIs, and take actions on a user's behalf, and most security teams have no record of which ones are running, on which machines, or what data flows through them. Bifrost, the open-source AI gateway built in Go by Maxim AI, addresses this gap by pairing a central control plane with endpoint enforcement: the gateway defines and enforces policy for AI traffic, and Bifrost Edge extends that same governance to every machine. This post explains what this problem is, why ungoverned MCP servers put your data at risk, and how to bring them under control.

What Is Shadow MCP

Shadow MCP refers to the Model Context Protocol servers that employees connect to AI applications without security review or central governance. These servers can read files, call APIs, and act on a user's behalf, yet most organizations have no inventory of which servers run on their machines, who configured them, or what data passes through them.

The Model Context Protocol is an open standard that lets AI applications connect to external tools and data sources through a consistent interface. A developer running Claude Code might wire in an MCP server for their database, another for their issue tracker, and a third pulled from a public registry. Each connection expands what the AI tool can do, and each one runs on an employee laptop, outside any path the security team controls.

The "shadow" part mirrors the older problem of shadow IT, where staff adopt unsanctioned software. With shadow MCP the surface is larger and the data access is more direct, because an MCP server is not a passive app: it is an active tool the model can invoke to read sensitive files or call privileged systems. The MCP ecosystem is already large, with one research dataset cataloging 13,875 MCP servers and 300 MCP clients crawled from the open web, and very few of those servers were ever vetted by the teams whose machines now run them. Left unmanaged, it grows on its own, and bringing it under endpoint AI governance is the subject of the rest of this post.

Why Ungoverned MCP Servers Put Your Data at Risk

Ungoverned MCP servers introduce three categories of risk that compound each other: untrusted code execution, data exfiltration, and a complete absence of audit and policy.

Tool poisoning and prompt injection. An MCP server describes its tools through metadata (names, descriptions, and parameter schemas) that the model reads as instructions. An attacker who controls or compromises a server can embed hidden directives in that metadata, a class of attack documented by Microsoft's security research on indirect prompt injection in MCP. Prompt injection sits at the top of the OWASP Top 10 for LLM Applications 2025 as the most critical vulnerability class, and MCP widens the channel it travels through.
Data exfiltration through privileged tools. When a server has filesystem or API access and the model can be steered by injected instructions, sensitive content can leave the machine without the user noticing. Real incidents have shown agents with privileged database access reading and leaking integration tokens after processing attacker-supplied input.
No audit trail, no budget, no guardrails. Traffic that never touches a governed path produces no logs, respects no budget, and passes through no content checks. Without centralized governance, security teams cannot answer basic questions about what was sent, to which provider, or whether secrets and personally identifiable information left the building.

The core issue is visibility. You cannot apply a policy to a server you do not know exists, and shadow MCP is, by definition, the inventory you do not have.

Why Traditional Controls Miss Shadow MCP

A gateway only governs the traffic that is configured to flow through it. That is the gap ungoverned MCP servers exploit. Bifrost as an MCP gateway centralizes tool connections, authentication, and access control for every MCP server an organization deliberately routes through it. The problem is that employees rarely route their personal tooling through anything. They install a desktop app, paste an MCP server config into it, and start working.

Network controls and endpoint detection tools were not built for this either. AI traffic looks like ordinary HTTPS to a provider, and an MCP server config buried inside an application's settings file is invisible to a firewall. The result is a blind spot that sits on every developer machine: AI applications quietly connected to tools that no one has reviewed, with the data access of an insider and none of the oversight.

Closing that gap requires governance that reaches the endpoint, not just the data center. The control plane has to know which MCP servers exist on each machine before it can decide which ones to permit.

How the Bifrost AI Gateway and Bifrost Edge Govern MCP Servers

Bifrost governs shadow MCP in two coordinated layers. The AI gateway is the control plane where policy is defined and enforced, and Bifrost Edge is the endpoint layer that extends that policy to every machine so the AI people actually use is covered too.

The gateway as the control plane

Bifrost, the AI gateway, is where governance lives. Virtual keys act as the primary policy entity, carrying per-consumer permissions, budgets, and rate limits. MCP tool filtering controls which tools a given virtual key can call, so even an approved server only exposes the operations a team is allowed to use. Guardrails inspect prompts and responses for secrets and PII before content leaves the boundary, and audit logs record every request for SOC 2, GDPR, HIPAA, and ISO 27001 reporting. This governance model gives the platform a single place to define what AI is permitted to do.

Bifrost Edge as the endpoint extension

The gateway can only govern MCP servers it can see, and the ungoverned tooling lives on laptops. Bifrost Edge closes that gap. It runs on each machine and routes AI traffic from desktop apps, browser AI, and coding agents through Bifrost, so the policies above apply on the endpoint rather than only on configured traffic. For MCP specifically, Bifrost Edge inventories the MCP servers configured inside each AI app and builds a live, fleet-wide inventory: which servers are configured, where, and across how many devices. For the first time, a security team can answer "what MCP servers are running on our fleet?" with real data instead of guesswork.

Edge then turns that visibility into control. Administrators make per-server allow or deny decisions, and the decision is enforced on the device, not treated as advice. A denied server cannot be used, even by an app that had it configured before the policy existed. MCP discovery today covers the major AI apps that support the protocol, including Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex, and Cursor. Bifrost Edge is currently in alpha, and teams register to be onboarded.

The relationship is the point: the MCP gateway and the broader Bifrost control plane define policy, and Edge carries that policy to the endpoint. Nothing new has to be learned on the policy side. The virtual keys, guardrails, and audit logging already configured in Bifrost are exactly what Edge enforces on each laptop.

Bringing Shadow MCP Under Governance

Governing these servers follows a visibility-then-control sequence. The Bifrost Edge approval workflow is built around three states for every discovered app and MCP server:

Pending. A newly discovered server keeps working while it awaits review, and administrators can configure whether pending items default to allowed or blocked.
Approved. The server is explicitly permitted and runs fully governed through Bifrost.
Denied. The server is blocked and stopped on the device at the next check-in.

Because the catalog is deduplicated across the fleet, the same MCP server appearing on a hundred machines shows up once. Approve or deny it a single time and the decision applies everywhere, with bulk actions available for clearing a backlog of pending servers. The devices dashboard gives per-machine detail (hostname, owner, platform, installed AI apps, and configured MCP servers) so investigations have a real fleet record to work from.

Rolling it out across the fleet

Bifrost Edge is built for fleet-wide deployment rather than manual installs. Organizations push it to every machine through an existing device management platform, with a managed configuration that points each agent at the company's Bifrost. Deployment via MDM supports Jamf, Microsoft Intune, Kandji, Omnissa Workspace ONE, and JumpCloud across macOS, Windows, and Linux. The managed configuration carries only non-sensitive connection settings, so no secrets live on the device; identity and keys come from the user's existing single sign-on. After a silent install and a one-time browser sign-in, governance turns on for supported AI traffic and stays in sync on its own. The agent lives in the menu bar or system tray, and most people set it once and leave it running.

Compliance Everywhere, Not Just in the Data Center

For regulated teams, ungoverned AI usage is a compliance problem as much as a security one. Audit obligations do not distinguish between a request that went through the gateway and one that went around it; both involve company data. By routing endpoint AI traffic through Bifrost, every request inherits the organization's audit logging, budgets, and guardrails on the laptop, which supports the SOC 2, GDPR, HIPAA, and ISO 27001 stories already associated with the platform. App governance extends the same allow or deny model from MCP servers to whole AI applications, so an organization can decide which AI tools are permitted on company machines at all.

This is where endpoint MCP governance connects to the broader enterprise picture. The Bifrost Enterprise feature set (clustering, role-based access control, in-VPC deployment, and immutable audit trails) is the foundation Edge enforces at the endpoint. Teams evaluating the full model can review the MCP gateway resource for how centralized MCP policy operates in production.

Getting Started with Shadow MCP Governance

Shadow MCP will keep growing as more AI applications adopt the protocol and more employees connect servers on their own. The way to manage it is to make the ungoverned visible, then enforce policy where the servers actually run. The Bifrost AI gateway gives you the control plane for MCP governance, and Bifrost Edge extends that control to every machine so no MCP server operates outside your policy. To see how the open-source Bifrost gateway and Bifrost Edge bring ungoverned MCP servers under governance across your fleet, book a demo with the Bifrost team.