Bifrost tackles shadow MCP by taking inventory of each ungoverned MCP server set up anywhere in your fleet and then applying a per-device decision to permit it or block it.
When employees hook Model Context Protocol (MCP) servers up to their AI tools and skip any security or governance layer in the middle, the result is what we call shadow MCP. The servers in question are capable of opening files locally, hitting internal APIs, and carrying out actions for whoever is using them, and yet which of them are live, the machines they sit on, and the data passing through them are details that rarely show up in any security team's records. The way Bifrost handles this gap is by pairing a central control plane with enforcement out at the endpoint. Built in Go by Maxim AI as an open-source AI gateway, it lets the gateway define and apply policy for AI traffic while Bifrost Edge carries the very same governance onto every machine. What follows lays out the problem itself, the reasons ungoverned MCP servers leave your data exposed, and the steps for reining them in.
What Shadow MCP Means
Picture the set of Model Context Protocol servers that employees connect to AI applications with no security review and no central oversight in place. That is shadow MCP. Reading files, calling APIs, and acting on a user's behalf are all within reach of these servers, and still most organizations cannot produce an inventory of what runs on their machines, who configured it, or which data moves across it.
As an open standard, the Model Context Protocol hands AI applications a uniform interface for reaching external tools and data sources. Take a developer on Claude Code: they may bolt on one MCP server for the database, a second for the issue tracker, and a third lifted straight from a public registry. With each new connection the AI tool can do more, and every one of those connections sits on an employee laptop, well outside whatever path the security team is able to watch.
Why "shadow"? The word borrows from the earlier headache of shadow IT, where staff bring in software nobody approved. What sets shadow MCP apart is its broader surface and its more direct reach into data, since an MCP server is no passive application. It is an active tool the model is free to invoke, whether to pull up sensitive files or to touch privileged systems. Consider the scale already in play: a single research dataset, crawled from the public web, lists 13,875 MCP servers and 300 MCP clients, nearly none of which were ever checked by the teams whose machines are now running them. Leave this footprint unattended and it grows on its own, which is why the remainder of this post turns to placing it under endpoint AI governance.
Why Ungoverned MCP Servers Threaten Your Data
There are three kinds of risk that ungoverned MCP servers bring, and each one feeds the others: untrusted code that gets executed, data that gets siphoned out, and the wholesale absence of any audit or policy.
- Tool poisoning and prompt injection. The way an MCP server presents its tools is through metadata such as names, descriptions, and parameter schemas, all of which the model takes in as instructions. Should an attacker gain control of a server or compromise one, hidden directives can be slipped into that metadata, which is the precise attack class covered by Microsoft's security research on indirect prompt injection in MCP. On the OWASP Top 10 for LLM Applications 2025, prompt injection holds the top spot as the gravest vulnerability class, and the channel it rides through is exactly what MCP widens.
- Data exfiltration via privileged tools. Give a server filesystem or API access, then let injected instructions steer the model, and sensitive content can slip off the machine while the user remains unaware. There are documented cases where agents holding privileged database access went on to read and leak integration tokens after they processed input supplied by an attacker.
- No audit trail, no budget, no guardrails. Anything that bypasses a governed path leaves no logs behind, observes no budget, and passes no content checks. Strip away centralized governance and security teams are left unable to say what got sent, which provider received it, or whether secrets and personally identifiable information walked out the door.
It all comes down to visibility. A server you have no idea exists is a server you cannot apply policy to, and shadow MCP is, almost by definition, precisely the inventory that you lack.
Why Traditional Controls Overlook Shadow MCP
The only traffic a gateway can govern is the traffic someone configured to run through it, and that limitation is the very opening ungoverned MCP servers take advantage of. Pressed into service as an MCP gateway, Bifrost pulls tool connections, authentication, and access control into one place for every MCP server a company purposely routes its way. The catch is that personal tooling almost never gets routed through anything by employees. Down goes a desktop app, in goes an MCP server config, and off they go.
This was never the job firewalls and endpoint detection tools were designed for, either. To a provider, AI traffic reads as nothing more than ordinary HTTPS, and an MCP server config buried in an application's settings file is something a firewall simply cannot see. So a blind spot ends up living on every developer machine, where AI applications quietly link to tools nobody reviewed, wielding an insider's data access without an ounce of the oversight.
Sealing that gap takes governance that stretches all the way to the endpoint rather than stopping at the data center. The control plane has no basis for choosing which MCP servers to allow until it first learns which ones are present on each machine.
How the Bifrost AI Gateway and Bifrost Edge Govern MCP Servers
Two layers, working in concert, are how Bifrost governs shadow MCP. One layer is the AI gateway, the control plane where policy gets defined and enforced. The other is Bifrost Edge, the endpoint layer that delivers that policy onto every machine, which means the AI people genuinely use ends up covered too.
The gateway as the control plane
Governance lives inside Bifrost, the AI gateway. The primary policy entity is the virtual key, and each one carries per-consumer permissions, budgets, and rate limits. Which tools any given virtual key is allowed to call comes down to MCP tool filtering, so even a server that has been approved exposes nothing beyond the operations its team is cleared for. Before content ever crosses the boundary, guardrails scan prompts and responses for secrets and PII, while audit logs record each request to feed SOC 2, GDPR, HIPAA, and ISO 27001 reporting. With this governance model the platform gains one single place to spell out what AI is permitted to do.
Bifrost Edge as the endpoint extension
Servers the gateway cannot see are servers it cannot govern, and the ungoverned tooling is living on laptops. That is the gap Bifrost Edge is there to close. Running on each machine, it sends AI traffic from desktop apps, browser AI, and coding agents through Bifrost, so every policy above takes effect at the endpoint instead of only on traffic someone already configured. Where MCP is concerned, Bifrost Edge inventories the MCP servers sitting inside each AI app and builds out a live inventory spanning the whole fleet: what servers are configured, in which places, and on how many devices. The question "what MCP servers are running on our fleet?" finally has a real-data answer for a security team, rather than guesswork.
From there, Edge turns that visibility into actual control. The allow or deny call gets made per server by administrators, and that call is enforced on the device instead of being handed down as a suggestion. Once a server is denied it cannot run, even within an app that already had it configured ahead of the policy. Among the major AI apps supporting the protocol, MCP discovery today reaches Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex, and Cursor. Right now Bifrost Edge sits in alpha, and teams sign up to get onboarded.
What matters here is the relationship between the parts: policy is defined by the MCP gateway together with the wider Bifrost control plane, and Edge ferries that policy out to the endpoint. The policy side asks nothing new to be learned. Whatever virtual keys, guardrails, and audit logging are already configured in Bifrost are exactly the things Edge goes on to enforce on every laptop.
Bringing Shadow MCP Under Governance
Visibility first, control second; that is the sequence for governing these servers. Three states organize the Bifrost Edge approval workflow, and each discovered app and MCP server passes through them:
- Pending. While it waits on review, a freshly discovered server keeps functioning, and whether pending items default to allowed or blocked is something administrators get to set.
- Approved. Here the server is permitted outright and runs fully governed by way of Bifrost.
- Denied. Here the server is blocked, and at the next check-in it gets stopped on the device.
Deduplication across the fleet means that an MCP server turning up on a hundred machines registers just once in the catalog. Make the approve or deny call one time and it lands everywhere, and bulk actions are on hand for clearing out a backlog of pending servers. Per-machine detail (hostname, owner, platform, installed AI apps, and configured MCP servers) shows up on the devices dashboard, giving investigations a real fleet record to lean on.
Rolling it out across the fleet
Manual installs are not the model for Bifrost Edge; fleet-wide deployment is what it was built for. Through an existing device management platform, organizations push it onto every machine, relying on a managed configuration that aims each agent at the company's Bifrost. Across macOS, Windows, and Linux, deployment via MDM covers Jamf, Microsoft Intune, Kandji, Omnissa Workspace ONE, and JumpCloud. Only non-sensitive connection settings ride along in that managed configuration, so the device never holds any secrets; identity and keys arrive instead from the user's existing single sign-on. A silent install plus a one-time browser sign-in is all it takes before governance comes on for supported AI traffic and keeps itself in sync from then on. Sitting in the menu bar or system tray, the agent is something most people configure once and then let run.
Compliance Everywhere, Not Only in the Data Center
To a regulated team, ungoverned AI usage counts as a compliance headache every bit as much as a security one. A request that traveled through the gateway and one that slipped around it look identical to audit obligations, because both touch company data. Route endpoint AI traffic through Bifrost and every request picks up the organization's audit logging, budgets, and guardrails right on the laptop, which backs up the SOC 2, GDPR, HIPAA, and ISO 27001 stories the platform is already known for. The same allow or deny model reaches beyond MCP servers to whole AI applications through app governance, letting an organization settle which AI tools may run on company machines in the first place.
Here is the join between endpoint MCP governance and the larger enterprise picture. What Edge enforces at the endpoint rests on the Bifrost Enterprise feature set, namely clustering, role-based access control, in-VPC deployment, and immutable audit trails. Any team sizing up the complete model can dig into the MCP gateway resource to see centralized MCP policy operating in production.
Getting Started with Shadow MCP Governance
Expect shadow MCP to keep on growing as the protocol shows up in more AI applications and more employees wire up servers themselves. Managing it means surfacing the ungoverned and then enforcing policy at the spot where the servers actually run. Your control plane for MCP governance is the Bifrost AI gateway, and Bifrost Edge carries that control to every machine so that not a single MCP server runs beyond your policy. Want to watch the open-source Bifrost gateway and Bifrost Edge pull ungoverned MCP servers under governance right across your fleet? Book a demo with the Bifrost team.
Top comments (0)