Shadow MCP: The Ungoverned AI Tools Risking Your Data
TL;DR
- Shadow MCP is the set of MCP servers employees connect to AI tools without security review, and OWASP lists it as MCP09, "Shadow MCP Servers," in its beta MCP Top 10.
- Shadow MCP servers can read local files and call internal APIs with no audit trail, no guardrails, and exposure to tool poisoning through their tool metadata.
- A gateway only governs traffic routed through it, so MCP servers configured inside desktop apps and coding agents on laptops stay invisible to it.
- Bifrost, the AI gateway, defines the policy, and Bifrost Edge (currently in alpha) inventories MCP servers on every machine and enforces allow or deny decisions on the 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, and shadow MCP is the tool-access layer of the broader shadow AI problem inside every company. 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: the MCPCorpus dataset, cited in a 2026 MCP threat-modeling study, catalogs 13,875 MCP servers and 300 MCP clients crawled from the open web.
The OWASP MCP Top 10 names the category directly: MCP09, "Shadow MCP Servers," describes unapproved MCP deployments operating outside an organization's formal security governance. Left unmanaged, shadow MCP 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. The 2026 threat-modeling study above ranks tool poisoning as the most prevalent client-side MCP vulnerability and reported significant security issues in most of the seven major MCP clients it tested. 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. When that AI data leakage runs through a local server process, network controls rarely flag it.
- 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 AI 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. The wider set of shadow AI risks, governance, and security controls follows the same pattern.
Why Traditional Controls Miss Shadow MCP
A gateway only governs the traffic that is configured to flow through it, and ungoverned MCP servers exploit exactly that gap. 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 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.
| Control | What it sees | Where shadow MCP slips past |
|---|---|---|
| Firewall and network monitoring | Connections and destinations | MCP config files and local STDIO servers never cross the network edge |
| Endpoint detection and response | Processes and malware behavior | A sanctioned AI app launching an MCP server looks like normal activity |
| AI gateway alone | Every request routed through it | Servers configured directly inside desktop apps and coding agents never reach it |
| AI gateway + Bifrost Edge | Routed traffic plus the MCP servers configured on each device | Coverage depends on the supported app list, which is growing |
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. The article on shadow MCP servers and visibility at the gateway covers what the gateway alone can see.
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, using built-in secrets detection and a PII detection regex template alongside external providers. Bifrost request logs record LLM and MCP traffic, and enterprise audit logs record administrative changes such as policy and key updates, which together support SOC 2, GDPR, HIPAA, and ISO 27001 reporting. The Bifrost 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. Bifrost Edge 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.
With that inventory, 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; the supported applications list tracks current coverage. Bifrost Edge is currently in alpha, and teams register to be onboarded.
The two layers depend on each other: 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
Detecting and governing shadow MCP follows a visibility-then-control sequence: discover every MCP server configured on every machine, review each one once, and enforce the decision on the device. Bifrost Edge automates the discovery step, and the Bifrost admin console holds the review and the policy.
Governing these servers starts with the Bifrost Edge approval workflow, which assigns one of three states to every discovered app and MCP server:
| State | What it means | Effect on the device |
|---|---|---|
| Pending | Discovered and awaiting review | Keeps working; administrators can configure whether pending items default to allowed or blocked |
| Approved | Explicitly permitted | Runs fully governed through Bifrost |
| Denied | Explicitly blocked | 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. Approved servers can then be curated into Virtual MCPs, reusable tool bundles attached to virtual keys, so teams reach sanctioned tools through the gateway rather than through local configs.
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. For how endpoint and gateway enforcement split the work, see MCP server governance across the gateway and endpoint.
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 request 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 HMAC-signed audit logs) is the control plane that Edge extends to the endpoint. Teams evaluating the full model can review how AI governance with virtual keys for LLM and MCP traffic 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.
When evaluating the gateway side, the five MCP governance features enterprises should demand make a practical checklist, and the roundup of shadow AI detection tools for enterprise security teams covers the detection landscape.
Frequently Asked Questions
What is shadow AI?
Shadow AI is the use of AI applications, models, and tools inside an organization without approval from IT or security. It includes chat apps, browser AI, coding agents, and the MCP servers those tools connect to. Shadow AI creates risk because company data reaches tools that produce no audit trail, respect no budget, and pass through no guardrails.
What is an MCP server?
An MCP server is a program that exposes tools, data, or prompts to AI applications through the Model Context Protocol. An AI app connects to the server and lets the model call its tools, for example to query a database, read files, or open a ticket. MCP servers can run locally on a laptop or remotely over HTTP.
How do you detect shadow MCP servers?
Shadow MCP servers are detected by reading the MCP configuration inside each AI application on each machine, because network scans and firewalls rarely see local configs or STDIO servers. Bifrost Edge performs that discovery automatically across supported apps and reports a deduplicated, fleet-wide inventory to the Bifrost admin console for review.
Is shadow MCP the same as shadow IT?
Shadow MCP is a specific form of shadow IT. Shadow IT covers any unsanctioned software, while shadow MCP covers unapproved MCP servers connected to AI tools. The difference is agency: an MCP server gives a model the ability to take actions and read data on a user's behalf, so an unreviewed server carries more direct data access than a typical unsanctioned app.
Can Bifrost Edge block an MCP server that was configured before the policy existed?
Yes. When an administrator denies an MCP server, Bifrost Edge enforces the decision on each device at its next check-in, including in apps that had the server configured before the policy was created. The server appears once in the deduplicated catalog, so a single deny decision applies everywhere it is installed.
Is Bifrost Edge generally available?
No. Bifrost Edge is currently in alpha, and teams register to be onboarded. The Bifrost AI gateway, which acts as the control plane Edge enforces, is available now as open source, with enterprise governance features such as guardrails and audit logs available in Bifrost Enterprise.
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.
