Try Bifrost Enterprise free for 14 days. Request access

Why Ungoverned MCP Connections Are a Risk and How a Gateway Fixes It

Why Ungoverned MCP Connections Are a Risk and How a Gateway Fixes It

TL;DR

  • Ungoverned MCP connections are direct links between AI apps and Model Context Protocol servers with no central authentication, access control, or logging in between.
  • The risks are concrete: CVE-2025-49596 in MCP Inspector allowed unauthenticated remote code execution and is rated CVSS 9.4.
  • Bifrost, as an MCP gateway, authenticates upstream servers, filters tools deny-by-default per virtual key, runs guardrails on tool traffic, and logs every tool call.
  • A gateway governs only the connections routed through it, so Bifrost Edge, currently in alpha, discovers and allows or denies MCP servers configured on employee machines.

Ungoverned MCP connections are Model Context Protocol server connections that AI applications make without passing through a central policy layer. When a coding agent or desktop app connects directly to an MCP server, that server can read files, query databases, and call APIs with no authentication controls, no access limits, and no audit trail in between. Bifrost, the open-source AI gateway built in Go by Maxim AI, is the control plane that fixes this by making every MCP tool call flow through a single governed entry point, and Bifrost Edge extends that governance to connections made on employee machines. For the full threat catalog, see MCP security risks and how to mitigate them.

What makes an MCP connection ungoverned

An MCP connection is ungoverned when the AI application talks to a tool server directly, without a gateway enforcing policy on the request. The Model Context Protocol is an open standard for letting models discover and execute external tools, and its value comes from the actions those tools can take. That same capability is the risk: a tool that can write to the file system or call an internal API is only as safe as the controls around it, and a direct connection has none.

Three properties of MCP make ungoverned connections particularly risky:

  • Tools take actions, not just return text. An MCP tool can execute commands, move data, and modify state, so a compromised or misconfigured server has real-world impact.
  • Tool definitions can change after approval. Researchers have documented "rug pull" attacks where an MCP server modifies its tool definitions between sessions, presenting different capabilities than what was first approved.
  • Connections are made at the edge. Users wire servers into apps like Claude Code and Cursor on their own machines, far from any central review, which is how shadow MCP servers accumulate.

The risks of ungoverned MCP connections

Ungoverned MCP connections introduce security, compliance, and cost exposure that scales with every new tool a team adds. The documented vulnerability record is already substantial: CVE-2025-49596 allowed remote code execution through MCP Inspector versions below 0.14.1, which lacked authentication between the Inspector client and proxy, and is rated CVSS 9.4. The NSA's MCP security guidance treats tool connections as a first-class attack surface.

The specific risks break down as follows:

  • Data exfiltration: A malicious or over-permissioned tool can move sensitive data to an external service with no policy to stop it.
  • Prompt injection to tool execution: Prompt injection is the top risk in the OWASP Top 10 for LLM Applications, and when a model with tool access is injected, the attacker can trigger real actions.
  • No revocation path: When a server is found to be unsafe, there is no central switch to disable it everywhere it was configured.
  • Compliance gaps: Tool calls that touch regulated data leave no audit trail, which creates gaps in SOC 2, GDPR, and HIPAA evidence.
  • Uncontrolled cost: Agentic tool loops can consume large volumes of tokens with no budget enforcement.

The same risks are framed as an IT governance problem in ungoverned MCP servers as the new shadow IT.

Risk of ungoverned MCP connections Gateway control in Bifrost
Unauthenticated or long-lived credentials Per-server auth types, including OAuth 2.0 with PKCE and per-user credentials
Over-permissioned tools Deny-by-default tool filtering per virtual key, plus Virtual MCPs
Data exfiltration and secret leakage Guardrail rules that target MCP tool calls
Prompt injection triggering actions No auto-execution unless an admin marks a tool as auto-executable
No revocation path Toggle off a server's tools, remove the client, or drop tools from virtual keys in one place
No record of tool activity MCP logs, Prometheus tool metrics, and admin audit logs
Uncontrolled token cost Budgets and rate limits on virtual keys, plus Code Mode

How a gateway fixes ungoverned MCP connections

An AI gateway fixes ungoverned MCP connections by inserting a single governed control point between AI applications and the tool servers they call. Bifrost acts as both an MCP client and an MCP server, so every tool call is authenticated, filtered, logged, and routed through one policy layer instead of hundreds of direct connections. This is the core of using Bifrost as an MCP gateway: centralized tool connections, authentication, and governance across every connected server, described in more depth in the MCP gateway as the control plane for MCP servers.

The gateway applies control at four points:

Access control with virtual keys and Virtual MCPs

Bifrost governs tool access through virtual keys as the primary entity. Administrators assign each key a scoped set of permissions, budgets, and rate limits, and a key with no MCP configuration receives no tools except from clients marked Allow by Default. Curated Virtual MCPs, previously called MCP tool groups, bundle tools from one or more servers behind their own /mcp/<slug> endpoint and attach to virtual keys, and Bifrost Enterprise can grant them through access profiles.

Policy is enforced at request time and again at tool execution, so a consumer only ever sees and runs the tools it is authorized to call. Allow-list patterns are covered in MCP tool governance: filtering, allowlisting, and access control.

Governing internal and remote MCP servers

Many teams want to expose existing internal systems to AI agents without handing out shared service credentials. Bifrost Enterprise supports token exchange for internal MCP servers that trust the organization's identity provider: each caller's identity token is exchanged for a short-lived token scoped to that server, so no per-user credential is stored at the gateway. Third-party SaaS servers follow the same model, covered in connecting and securing remote MCP servers through one gateway.

Extending governance to the endpoint with Bifrost Edge

A gateway governs the connections that route through it, but users can still wire MCP servers directly into apps on their laptops. Bifrost Edge is the layer that closes that last gap. Edge runs on each machine, discovers the MCP servers configured inside AI apps, and enforces the gateway's policies on the device, so MCP servers configured in supported AI apps are held to the same policies.

Edge adds three controls at the endpoint:

  • Discovery: Edge inventories MCP servers configured inside AI apps and reports which servers exist, on which machines, and across how many devices.
  • Enforcement: Per-server allow/deny decisions are enforced on the device, so a denied server cannot be used even if it was configured before the policy existed.
  • Fleet rollout: Edge deploys through existing device management platforms such as Jamf, Intune, Kandji, Workspace ONE, and JumpCloud with a managed configuration pointing each machine at the organization's Bifrost.

The same governance controls configured in the gateway, including virtual keys, budgets, and guardrails, apply to AI traffic Edge routes through Bifrost, and the Edge security layer applies existing guardrail profiles with nothing extra to set up on the endpoint. Bifrost Edge is currently in alpha, and teams register to be onboarded.

Why enterprises standardize MCP governance on Bifrost

Bifrost is built for enterprises and large teams that need MCP governance to hold up under scale, compliance, and security requirements. Consolidating tool connections on the gateway also reduces cost: with Code Mode, Bifrost benchmarks showed up to 92.8% fewer input tokens and 92.2% lower estimated cost at 508 tools across 16 servers. For regulated deployments, Bifrost Enterprise supports air-gapped environments, VPC isolation, and on-prem infrastructure, so tool traffic and audit trails stay inside controlled boundaries.

Bifrost adds only 11 microseconds of overhead per request at 5,000 requests per second in sustained benchmarks, so routing MCP traffic through the gateway does not become a latency bottleneck. Because Bifrost runs as both an MCP client and an MCP server, existing apps continue to call their tools normally while the gateway applies policy transparently.

That keeps adoption low-friction as teams add more agents and tools. Governance, cost control, and performance run on the same control point.

Frequently asked questions

What is an ungoverned MCP connection?

An ungoverned MCP connection is a direct connection between an AI application and a Model Context Protocol server that bypasses any central policy layer. No gateway authenticates the server, restricts which tools the caller can use, runs guardrails on the traffic, or logs the tool calls, so the organization cannot see or revoke what the connection does.

What are the main security risks of MCP servers?

The main MCP server risks are data exfiltration through over-permissioned tools, prompt injection that triggers real tool actions, tool definitions that change after approval, unauthenticated local tooling such as the MCP Inspector flaw CVE-2025-49596, and missing audit trails. The MCP security best practices checklist maps each risk to a control.

How does an MCP gateway secure tool calls?

An MCP gateway secures tool calls by acting as the only path between AI clients and upstream MCP servers. Bifrost authenticates each server connection, applies deny-by-default tool filtering per virtual key, runs guardrail rules on tool traffic, requires explicit execution unless a tool is marked auto-executable, and records every call in MCP logs.

Can a gateway revoke access to an unsafe MCP server?

Yes. Because every governed tool call passes through Bifrost, an administrator can toggle off the server's tools, remove the MCP client, or drop its tools from virtual keys once, and the change applies to every consumer routed through the gateway. For servers configured directly on laptops, Bifrost Edge enforces a deny decision on the device.

Does routing MCP traffic through a gateway add latency?

The gateway itself adds little overhead: Bifrost measures 11 microseconds per request at 5,000 requests per second in sustained benchmarks. The dominant latency remains the upstream tool server and the model call, and Code Mode can reduce round trips in large MCP deployments by orchestrating multiple tool calls in a sandbox.

Start governing MCP connections with Bifrost

Ungoverned MCP connections put action-capable tools on the network with no authentication, access control, or audit trail, and the risk grows with every server a team adds. Bifrost fixes this at the gateway by routing every tool call through a single governed entry point, and Bifrost Edge extends that governance to the machines where connections are actually made. To see how Bifrost governs MCP connections across your organization, book a demo with the Bifrost team.