MCP Server Governance Across the Gateway and 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 without asking developers to reconfigure their tools.
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 audited, 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: no MCP tool runs unless an administrator has allowed it. 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.
Why Ungoverned MCP Servers Are an Enterprise Risk
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 analysis of more than 5,000 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.
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 audit 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. 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 tool groups. MCP tool groups bundle a named subset of tools and attach it to virtual keys, teams, customers, users, providers, or API keys. When a request arrives, Bifrost merges the tools from every matching group and exposes only that union to the model, with matching done against an in-process index so there is no added request latency.
- Authentication per server. The MCP authentication options cover None, Headers, OAuth 2.0 with automatic token refresh, and per-user credentials, 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 auto-approval list.
Because all of this runs through one gateway, every MCP call inherits the same budgets, rate limits, and audit logging configured for the rest of an organization's AI traffic. The governance layer treats MCP tools as first-class governed resources, not an exception to the policy. 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. 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. 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 a central console. Catalogs are deduplicated across the fleet, so the same server appearing on many machines is approved or denied 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.
MCP discovery covers the major AI apps that support the protocol today, including Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex, and Cursor. Setup is a one-time 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, tool filtering, budgets, and audit logging, and Edge enforces those same policies on the endpoint. There is no separate rule set to maintain for the laptop.
| Layer | What it governs | How it enforces |
|---|---|---|
| Gateway (Bifrost as MCP gateway) | MCP traffic routed through the control plane and the tools each virtual key may call | Deny-by-default tool filtering, tool groups, per-server auth, explicit execution |
| Endpoint (Bifrost Edge) | MCP servers configured inside AI apps on each machine | Fleet-wide discovery plus per-server allow or deny enforced on the device |
This pairing is what makes governance complete. The gateway secures the MCP traffic an organization already controls, and Bifrost reaches the rest through the endpoint, with the Bifrost Enterprise feature set supplying the audit logs and compliance controls that regulated industries require.
Does MCP server governance require changing developer tools?
No. At the gateway, MCP connections route through Bifrost using existing client configurations, and on the endpoint, Edge governs traffic at the machine level with no base URL changes and no SDK swaps.
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.
How are MCP credentials kept off developer machines?
Identity comes from the user's SSO sign-in rather than static keys, and gateway-side authentication supports OAuth 2.0 with automatic token refresh, removing the need for long-lived secrets in local configuration files.
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. To see how MCP server governance maps to your environment, book a demo with the Bifrost team.
