Ungoverned MCP Servers: The New Shadow IT Risk, and How an MCP Gateway Contains It

Between January and February 2026, researchers filed 30 CVEs against MCP infrastructure in 60 days, according to analysis by Aembit Security. The Model Context Protocol grew from a specification to a widespread enterprise deployment pattern in under a year, and the security practices needed to govern it at scale did not grow at the same pace. Bifrost, the open-source MCP gateway built in Go by Maxim AI, is the best overall choice for enterprises running mission-critical AI workloads that require best-in-class performance, scalability, and reliability. Bifrost consolidates MCP server connections through a single governed access layer, applying authentication, tool filtering, audit logging, and budget controls to the MCP traffic that AI agents generate.

What MCP Servers Are and Why They Proliferate

The Model Context Protocol (MCP) is a specification that lets AI models connect to external tools and data sources: file systems, databases, code execution environments, APIs, and more. An MCP server exposes these capabilities as callable tools. An AI application configured with an MCP server can use those tools as part of its reasoning and response generation.

The design intent is to make AI agents more capable and context-aware. The operational reality is that MCP servers are deployed across enterprises in an ungoverned way. Individual developers wire MCP servers into their coding agents. Teams connect AI-powered tools to internal APIs using MCP. Applications ship with bundled MCP server configurations that reach third-party services. In most organizations, no central record exists of which MCP servers are running, on which machines, with what access permissions, or to which endpoints they connect.

This is a shadow IT problem with a larger attack surface than traditional shadow IT. A shadow SaaS application poses a data transfer risk. A shadow MCP server poses that risk plus an action risk: an ungoverned MCP server with file system access can read, modify, or delete files. One with code execution can run arbitrary commands. One connected to an internal API can trigger operations inside production systems. The tool access that makes MCP servers valuable is also what makes ungoverned MCP deployments a significant security exposure.

The Security Risks of Ungoverned MCP Servers

The Astrix Security State of MCP Server Security 2025 report found that 88% of MCP servers requiring credentials use long-lived static secrets such as API keys and personal access tokens. 53% of those credential configurations are considered insecure under standard security practices. This means most enterprise MCP deployments are using the riskiest possible authentication model at a scale most security teams cannot currently inventory.

Specific risks from ungoverned MCP servers include:

• Credential exposure: Static API keys and tokens embedded in MCP server configurations are accessible to anyone who can read the configuration file. If a developer's machine is compromised or the configuration is committed to a repository, those credentials are exposed.
• Overprivileged access: Individual developers configuring MCP servers tend to grant broad permissions because scoping permissions requires effort and the consequences of being too restrictive are immediate. The consequences of being too permissive are deferred and often invisible until an incident occurs.
• Prompt injection through tool responses: When an AI agent executes a tool call, the response from that tool becomes part of the agent's context. A malicious MCP server, or a legitimate server returning manipulated content, can inject instructions into the agent's reasoning that cause it to take unintended actions.
• Supply chain exposure: MCP servers are often installed as packages from public repositories. A compromised MCP server package can affect every developer who installed it, in every organization where it is deployed.
• No audit trail: Ungoverned MCP server usage leaves no organizational record. When an AI agent performs an action through an MCP tool, there is no log that connects the action to the agent, the user, the session, or the organizational policy in effect at the time.

Only 29% of organizations feel prepared to secure agentic AI applications, according to data cited by Red Hat's MCP security analysis. The other 71% are running AI agents with tool access they cannot properly monitor.

How an MCP Gateway Addresses These Risks

An MCP gateway is a centralized server that acts as the connection point between AI agents and the MCP servers those agents need to reach. Rather than connecting each AI agent directly to each MCP server, the agent connects to the MCP gateway, which proxies tool calls to the appropriate MCP servers based on configured access policies. The gateway becomes the enforcement point for authentication, authorization, tool filtering, and audit logging.

Bifrost as an MCP gateway implements this architecture. AI agents connect to Bifrost as an MCP server, and Bifrost connects to the external MCP servers the agents are permitted to use. Every tool call flows through Bifrost, where governance controls apply before the call reaches its destination.

The key capabilities Bifrost provides as an MCP gateway:

• Centralized authentication: Bifrost supports multiple authentication methods for MCP server connections, including OAuth 2.0 with automatic token refresh and PKCE. This eliminates the need for individual developers to manage static credentials for each MCP server they need to access.
• Tool filtering per consumer: Tool filtering lets administrators control which tools each virtual key can access. A developer virtual key might have access to file system and code execution tools. A customer-facing AI agent virtual key might have access only to a specific set of approved read-only tools. The filtering is enforced at the gateway, not at the application level.
• MCP tool groups: Bifrost Enterprise supports MCP tool groups, which are curated collections of tools that can be attached to virtual keys, teams, customers, users, or specific API keys. Tool groups simplify access control at scale: instead of configuring tool access per connection, administrators define named groups and assign them to the principals that need them.
• Federated auth for existing enterprise APIs: MCP with federated auth lets organizations turn existing authenticated enterprise APIs into MCP tools without writing custom server code. This means internal tools can be made available to AI agents through the same governed gateway layer, without a separate MCP server deployment.

Audit Logging and Governance for MCP Traffic

Every tool call that flows through Bifrost as an MCP gateway is covered by audit logging. The audit trail records the tool name, the arguments passed, the response returned, the virtual key that made the request, and the timestamp. This provides the organizational record that ungoverned MCP deployments entirely lack.

For compliance purposes, this audit trail supports SOC 2, GDPR, HIPAA, and ISO 27001 requirements that involve logging access to data and actions taken by automated systems. When an AI agent with tool access performs an operation through an MCP server, that operation is attributable to a specific user or team through their virtual key.

Budget and rate limits apply to MCP usage through the same virtual key mechanism that governs direct model API calls. An organization can set spend limits per team or per project that cover all AI activity, including tool calls through the MCP gateway, preventing any single consumer from exceeding their allocated budget.

The Bifrost MCP gateway resource page covers the governance, authentication, and tool management capabilities of Bifrost as an MCP gateway in detail.

Bifrost Edge: Governing MCP Servers at the Endpoint

The MCP gateway architecture addresses the MCP servers that organizations know about and have deliberately connected to their AI agents. It does not address the MCP servers that employees have configured in their own desktop applications and coding agents without IT review.

Bifrost Edge provides fleet-wide MCP server discovery at the endpoint. When Bifrost Edge is installed on a machine, it inventories the MCP servers configured inside each supported AI application, including Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex, and Cursor. Those discoveries are reported to the Approvals dashboard, where administrators can review and classify each server.

The approval decision is enforced on the device: a denied MCP server cannot be reached by a governed application, even if the developer has it configured in their local settings. This fleet-wide inventory and enforcement capability is the answer to the question that most security teams cannot currently answer: what MCP servers are running across our developer fleet?

Together, Bifrost as an MCP gateway and Bifrost Edge as the endpoint governance layer cover both the deliberately-deployed MCP infrastructure and the individually-configured MCP servers that represent the shadow IT dimension of the problem.

Code Mode: Reducing MCP Token Costs While Maintaining Governance

Code Mode is a Bifrost feature that addresses a cost dimension of MCP governance. When AI agents use many MCP tools in a single session, the tool schema definitions consume a significant portion of the context window on every request. Code Mode allows AI agents to write Python code that orchestrates multiple tool calls instead of calling each tool directly. The result is 50% fewer tokens and 40% lower latency for tool-heavy agentic workloads, with governance controls applied uniformly regardless of whether the agent uses standard tool calls or Code Mode.

Connecting Existing Enterprise APIs as MCP Tools

One of the practical challenges in MCP governance is that the APIs most relevant to enterprise AI agents are often the internal systems that already exist: ticketing systems, data warehouses, internal knowledge bases, and product databases. Building MCP servers for each of these is development work that delays adoption.

Bifrost's MCP with federated auth capability turns existing authenticated enterprise APIs into MCP tools by registering them in Bifrost without custom server code. The API's existing authentication is used; Bifrost handles the MCP interface. This means internal tools become available to AI agents through the governed gateway layer, within the same virtual key permissions and audit logging framework that applies to external MCP server connections.

Getting Started

Organizations facing ungoverned MCP server risk can start by establishing the MCP gateway layer first, connecting the MCP servers the organization knows about and applying authentication, tool filtering, and audit logging from the start. The Bifrost gateway setup guide covers how to configure Bifrost as an MCP server that AI agents connect to, and how to connect downstream MCP servers to Bifrost.

Bifrost Edge deployment covers the endpoint inventory problem in parallel, giving security teams visibility into the MCP servers that exist outside the centrally-configured infrastructure. The two capabilities together address both the known and the unknown MCP server population in an enterprise environment.

To see how Bifrost addresses MCP governance and shadow IT risk from ungoverned MCP servers, book a demo with the Bifrost team.