MCP Server Governance Across the Gateway and Endpoint

TL;DR

• MCP server governance controls which MCP servers, tools, and users are allowed across your AI traffic, and Bifrost enforces it at both the gateway and the endpoint.
• At the gateway, a virtual key with no MCP configuration gets no MCP tools by default, and Virtual MCPs expose only a curated set of tools at a single /mcp/<slug> endpoint.
• At the endpoint, Bifrost Edge (in alpha) inventories the MCP servers configured in apps like Claude Code, Claude Desktop, and Cursor, and blocks denied servers on the device.
• Edge applies the gateway's virtual keys, budgets, guardrails, and audit logs on every machine, and adds MCP server approvals for the endpoint.

Most organizations cannot produce a list of the MCP servers running inside the AI tools their employees use every day. Model Context Protocol (MCP) servers let AI agents read files, call internal APIs, and take actions on enterprise systems, which turns an ungoverned MCP connection into a direct path for sensitive data to leave the company with no audit trail.

MCP server governance is the practice of controlling which MCP servers are allowed, what tools they expose, and who can use them, enforced consistently across both the gateway and the endpoint. Bifrost, the open-source MCP gateway built in Go by Maxim AI, governs MCP traffic at the control plane, and Bifrost Edge extends that same governance to every machine in the fleet. This post explains how MCP server governance works at both layers and how to implement it with minimal changes to the tools developers already use.

What Is MCP Server Governance?

MCP server governance is the set of controls that determine which MCP servers an organization permits, which tools those servers can expose to AI models, and which users or workloads are allowed to call them. It operates at two distinct layers: the gateway, where MCP traffic that already routes through a centralized MCP gateway is filtered and logged, and the endpoint, where MCP servers configured inside AI apps on individual machines are discovered and approved or denied.

Both layers enforce the same intent: MCP tools run only within a policy an administrator controls. The difference is reach. The gateway governs the traffic configured to flow through it; the endpoint governs the AI that people install and wire up on their own. For the broader definition, including policy, ownership, and review processes, see what MCP governance is and how it works.

MCP Security Risks of Ungoverned MCP Servers

Ungoverned MCP servers create MCP security risks that most enterprises cannot yet see, because MCP adoption has outpaced the controls meant to contain it. Security researchers at Trend Micro found that the number of publicly exposed MCP servers nearly tripled to 1,467 in a matter of months, many running with no client authentication or traffic encryption. A separate October 2025 analysis of more than 5,200 open-source MCP servers by Astrix Security reported that 53% rely on static, long-lived API keys or personal access tokens that are rarely rotated. The OWASP Top 10 for Large Language Model Applications ranks prompt injection as the leading risk, and an MCP server connected to a model turns a successful injection into real actions against internal systems rather than just a bad text response.

The governance gap shows up in a few recurring forms:

• Invisible connections: Security teams have no inventory of which MCP servers users have wired into Claude Desktop, Cursor, or a coding agent.
• Overprivileged tools: A server exposes every tool it has, so an agent can reach far more than its task requires.
• No audit trail: Tool calls execute with no record of what ran, when, or against which system.
• Credential sprawl: Long-lived secrets sit in plaintext configuration files on developer machines.

Each of these maps to a concrete failure mode, covered in more detail in the security risks of ungoverned MCP server access.

Closing the MCP governance gap reliably means covering both the traffic that flows through a central gateway and the traffic that originates on the endpoint.

Governing MCP Servers at the Gateway

Bifrost acts as both an MCP client and an MCP server, which lets it sit between AI models and the external tools they call. Used as an MCP gateway, it centralizes every MCP connection behind one control plane, so tool access, authentication, and logging are applied in one place instead of being scattered across individual app configurations. Bifrost connects to servers over STDIO, HTTP, or SSE and exposes their tools to clients such as Claude Desktop through a single governed endpoint.

Control at the gateway is enforced through several mechanisms:

• Deny-by-default tool filtering. With MCP tool filtering, a virtual key that has no MCP configuration gets no MCP tools at all, except from clients an administrator has explicitly marked Allow by Default. Administrators explicitly allow specific clients and tools, creating a strict allow-list per key rather than relying on a block-list that has to anticipate every risky tool.
• Curated Virtual MCPs. Virtual MCPs (previously called MCP tool groups, and now part of open-source Bifrost) bundle a named subset of tools from one or more MCP servers, serve it at its own /mcp/<slug> endpoint, and attach it to virtual keys. On a chat request, Bifrost folds every attached Virtual MCP into the key's tool union and exposes only that union to the model, with resolution done against an in-process index so there is no added request latency. Bifrost Enterprise adds access-profile grants on top.
• Authentication per server. The MCP authentication options cover six types: None, Headers, Per-User Headers, OAuth 2.0 with automatic token refresh, Per-User OAuth, and Token Exchange (enterprise), so each server connects with the right identity instead of a shared static secret.
• Explicit execution by default. Bifrost does not auto-execute tool calls. A model's tool call is treated as a suggestion that requires a separate execution step, and autonomous behavior is opt-in through Agent Mode with a configurable list of auto-executable tools.

Because all of this runs through one gateway, every MCP call inherits the same budgets, rate limits, and request logging configured for the rest of an organization's AI traffic. The governance layer treats MCP tools as first-class governed resources under the same policy as model access.

For per-server credential patterns, see how to secure agent tool access with MCP server authentication. Teams running MCP at scale can read how access control and cost governance combine in the Bifrost MCP gateway breakdown.

Extending MCP Governance to the Endpoint with Bifrost Edge

A gateway only governs the MCP traffic that is configured to flow through it. In practice, employees install AI apps and connect MCP servers on their own machines, and that activity never reaches the control plane. This is the shadow AI problem applied to MCP: tools wired into local apps that security teams cannot see.

Shadow MCP servers and how to get visibility and control over them covers the gateway-side view of the same problem. Bifrost Edge closes this gap by extending the AI gateway to the endpoint. Edge is currently in alpha.

Bifrost Edge runs on every computer in an organization and routes AI traffic through the company's Bifrost, so the same virtual keys, budgets, guardrails, and audit logs apply on the laptop and not just in the data center. For MCP specifically, Edge MCP governance does three things:

• Discovery. Edge reads the MCP configuration inside each supported AI app on every machine and builds a live, fleet-wide inventory of which servers are configured, where, and across how many devices, including how each server connects (local command or remote URL) and the tools it exposes. Teams can finally answer "what MCP servers are running on our fleet?" with real data.
• Per-server decisions. Administrators allow the servers the organization trusts and deny the rest, server by server, from the central Approvals dashboard. Catalogs are deduplicated across the fleet, so the same server appearing on many machines is approved or denied once, and bulk actions can deny every pending server at once.
• Enforcement on the device. A denied MCP server is blocked on the machine itself, not merely flagged. Even an app that had the server configured before the policy existed cannot use it.

Every discovered MCP server carries one of three statuses, and the pending behavior is configurable:

MCP discovery covers the major AI apps that support the protocol today, including Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex, and Cursor; the supported applications list tracks current coverage. Setup is a one-time approval and browser sign-in through the organization's existing SSO, after which an always-on agent in the menu bar or system tray keeps policy in sync.

Edge also handles whole-application control through app governance and applies the guardrails already configured at the gateway to the prompts and responses moving through endpoint AI. For fleet rollout, Edge installs silently through existing device management platforms using a managed MDM configuration for Jamf, Microsoft Intune, Kandji, Omnissa Workspace ONE, and JumpCloud.

How the Two Layers Work Together

The Bifrost AI gateway is the control plane and policy engine, and Bifrost Edge is the layer that carries that policy out to every machine. Policies are defined once at the gateway, including virtual keys, budgets, guardrails, and audit logging, and Edge enforces those same policies on the endpoint, adding per-server MCP approvals for the AI installed on each machine. There is no separate rule set to maintain for the laptop. The same model is described end to end in closing the last mile of AI governance from the gateway to the endpoint.

This pairing covers both sides of the problem. The gateway secures the MCP traffic an organization already routes centrally, and Bifrost Edge reaches the rest on the endpoint, with the Bifrost Enterprise feature set supplying the audit logs and compliance controls that regulated industries require.

How to Implement MCP Server Governance in Five Steps

MCP server governance is implemented by defining policy once at the gateway and then extending it to every machine. The sequence below moves from central control to fleet coverage, so each step builds on the policy the previous one established.

1. Enable governance and virtual keys. Issue virtual keys per team or workload so every MCP call carries an identity, a budget, and a rate limit.
2. Allow-list tools per key. Configure MCP tool filtering and group approved tools into Virtual MCPs, leaving everything else denied by default.
3. Set per-server authentication. Replace shared static secrets with OAuth 2.0 or per-user credentials on each MCP server connection.
4. Roll out Bifrost Edge through MDM. Push Edge to the fleet with MDM deployment through Jamf, Intune, Kandji, Workspace ONE, or JumpCloud, generate or import the organization certificate in Edge configurations, and decide whether pending MCP servers are allowed or blocked.
5. Review the MCP server catalog. Approve trusted servers, deny the rest, and revisit new pending entries as Edge discovers them.

For a tool-by-tool comparison of approaches, the companion guide to MCP server governance best practices and tools covers the same problem from the buyer's side.

Frequently Asked Questions (FAQs)

Does MCP server governance require changing developer tools?

Very little. At the gateway, each MCP client is pointed once at a Bifrost /mcp endpoint, and on the endpoint, Edge governs traffic at the machine level with no base URL changes and no SDK swaps. After a one-time setup approval and browser sign-in through the organization's SSO, developers keep using Claude Code, Cursor, or Claude Desktop as before.

What happens to an MCP server that was approved and is later denied?

The denial takes effect at the device's next check-in, and Edge blocks the server on the machine even if an app had it configured previously. The check-in frequency is set by the fleet-wide sync interval, which administrators can shorten (down to a few seconds) so policy changes reach machines sooner.

Are newly discovered MCP servers blocked automatically?

Not by default. A newly discovered MCP server enters the Pending state and keeps working until an administrator denies it, so existing workflows do not break on rollout. Organizations that want a stricter posture can configure pending servers to be blocked until they are reviewed and approved.

How are MCP credentials kept off developer machines?

Identity comes from the user's SSO sign-in rather than static keys, and the MDM configuration that points Edge at Bifrost carries only non-sensitive connection settings. On the gateway side, OAuth 2.0 with automatic token refresh and per-user authentication replace long-lived secrets in local configuration files.

What are Virtual MCPs?

Virtual MCPs are curated bundles of tools drawn from one or more MCP servers and served at their own /mcp/<slug> endpoint. Each one is reachable only through the virtual keys it is attached to, so a team sees exactly the tools it needs. Virtual MCPs were previously called MCP tool groups and are now part of open-source Bifrost.

How does shadow AI relate to MCP server governance?

Shadow AI is AI usage that happens outside approved, governed channels, and MCP servers wired into local apps are one of its most direct forms because they can read files and take actions. MCP server governance addresses it by discovering those servers on every machine and enforcing approve or deny decisions on them from the central Approvals dashboard. See what shadow AI is and how to detect it.

Getting Started with MCP Server Governance

MCP server governance works best as a single policy enforced in two places: at the gateway for the traffic you route centrally, and at the endpoint for the AI your teams run on their own. Bifrost provides both, governing MCP traffic at the control plane as an open-source AI gateway and extending that governance to every machine in the fleet through Bifrost Edge. Teams new to the topic can start with the fundamentals of MCP governance before planning a rollout. To see how MCP server governance maps to your environment, book a demo with the Bifrost team.