Which MCP servers, which tools, and which users get access to your AI traffic is exactly what MCP server governance decides. Bifrost puts that decision into force at the gateway and again at the endpoint.
Ask most companies to name the MCP servers humming away inside the AI tools their staff open daily, and they cannot. The reason this matters: Model Context Protocol (MCP) servers hand AI agents the ability to read files, hit internal APIs, and act on enterprise systems. Leave one of those connections ungoverned and you have built a clean exit for sensitive data, complete with zero audit trail. Governing MCP servers, then, is about deciding three things together and enforcing them the same way at the gateway and the endpoint: which servers get to run, which tools they are allowed to surface, and which people may invoke them. The Go-based open-source MCP gateway from Maxim AI, Bifrost, handles the control-plane side of that traffic, while Bifrost Edge takes the identical policy out to every machine across the fleet. What follows is a look at how this governance behaves on both layers, and how to stand it up without telling a single developer to reconfigure anything.
What MCP Server Governance Actually Means
Three questions sit at the heart of MCP server governance: which MCP servers does the organization sanction, which of their tools can be exposed to AI models, and which users or workloads are cleared to call them. Answering those questions happens in two separate places. One is the gateway, where traffic that is already pointed at a centralized MCP gateway gets filtered and logged. The other is the endpoint, where the MCP servers someone has wired into an AI app on their own laptop get spotted and then either cleared or blocked.
The intent never changes between the two layers: an MCP tool does not run until an admin has signed off on it. Reach is where they part ways. Traffic deliberately pointed through the gateway is what the gateway can govern; the AI that people set up and connect themselves is what the endpoint covers.
The Enterprise Risk Hiding in Ungoverned MCP Servers
Controls were supposed to keep pace with MCP. They did not. When Trend Micro looked into it, their researchers watched the population of publicly exposed MCP servers almost triple to 1,467 over just a few months, and a large share of those were running without any client authentication or encryption on the wire. Astrix Security went through over 5,000 MCP servers in a separate review and found 53% leaning on static, long-lived API keys or personal access tokens that almost never get rotated. Meanwhile, prompt injection sits at number one on the OWASP Top 10 for Large Language Model Applications, and once a model is wired to an MCP server, a successful injection stops being a bad text reply and becomes a real action fired at internal systems.
A few patterns keep showing up wherever the governance gap is open:
- Credential sprawl: Plaintext config files on developer machines quietly hold long-lived secrets.
- No audit trail: Nothing records which tool ran, at what moment, or against which system when a tool call fires.
- Invisible connections: Which MCP servers people have plugged into Claude Desktop, Cursor, or a coding agent is a list security teams simply do not have.
- Overprivileged tools: Because a server hands over every tool it owns, an agent can touch far more than the job in front of it calls for.
Reliably shutting the MCP governance gap therefore takes in two streams at once: the traffic moving through a central gateway, and the traffic that starts life on the endpoint.
Putting MCP Servers Under Control at the Gateway
Sitting between AI models and the outside tools they reach for is possible because Bifrost plays both roles, MCP client and MCP server at once. Run it as an MCP gateway and every MCP connection collapses behind one control plane, which means tool access, authentication, and audit logging land in a single spot rather than spread across one app config after another. Over STDIO, HTTP, or SSE, Bifrost reaches the servers, then surfaces their tools to clients like Claude Desktop through a single governed endpoint.
Several mechanisms do the enforcing at the gateway:
- Deny-by-default tool filtering. Under MCP tool filtering, a virtual key with no MCP configuration attached to it ends up with no MCP tools whatsoever. Rather than maintaining a block-list that somehow has to predict every dangerous tool, admins name the clients and tools they want, which produces a tight allow-list scoped to each key.
- Curated tool groups. A named slice of tools gets bundled by MCP tool groups and pinned to virtual keys, teams, customers, users, providers, or API keys. As a request lands, Bifrost folds together the tools from each group that matches and shows the model only that combined set, doing the matching against an in-process index so nothing gets added to request latency.
- Authentication per server. None, Headers, OAuth 2.0 with automatic token refresh, and per-user credentials are the choices the MCP authentication layer offers, letting every server connect under the correct identity instead of one shared static secret.
- Explicit execution by default. Tool calls do not auto-fire in Bifrost. It reads a model's tool call as a suggestion that still needs its own execution step; anything autonomous is something you opt into via Agent Mode and its configurable auto-approval list.
Routing all of this through one gateway means every MCP call picks up the very same budgets, rate limits, and audit logging already set for the rest of a company's AI traffic. To the governance layer, MCP tools are first-class governed resources, never a carve-out from policy. Anyone operating MCP at scale can dig into how access control pairs with cost governance in the Bifrost MCP gateway breakdown.
Carrying MCP Governance Out to the Endpoint with Bifrost Edge
What a gateway governs stops at the MCP traffic deliberately routed through it. Out in the real world, employees set up AI apps and hook MCP servers to their own machines, and none of that ever shows up at the control plane. Call it the shadow AI problem in MCP form: tools attached to local apps that security teams have no way to see. Bifrost Edge shuts that gap by stretching the AI gateway down to the endpoint. Edge is in alpha for now.
Living on every computer in the organization, Bifrost Edge sends AI traffic through the company's Bifrost, so the laptop gets the same virtual keys, budgets, guardrails, and audit logs that the data center already has. On the MCP front in particular, Edge MCP governance handles three jobs:
- Discovery. Reading the MCP configuration in each supported AI app on each machine, Edge assembles a live, fleet-wide inventory of which servers are set up, where they sit, and on how many devices. The question "what MCP servers are running on our fleet?" finally has a data-backed answer.
- Per-server decisions. From one central console, admins clear the servers the organization trusts and turn down the rest, one server at a time. Because catalogs are deduplicated across the fleet, a server showing up on dozens of machines is cleared or blocked a single time.
- Enforcement on the device. Denying an MCP server blocks it right on the machine itself rather than just raising a flag. Even an app that already had that server configured before the policy landed cannot use it.
The major protocol-supporting AI apps in use today are all covered by MCP discovery, Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex, and Cursor among them. Getting started is a single browser sign-in via the organization's own SSO, and from then on an always-on agent in the menu bar or system tray keeps the policy current.
Beyond servers, Edge also takes on whole-application control through app governance, and the guardrails already set at the gateway get applied to the prompts and responses flowing through endpoint AI. Rolling it out across a fleet is quiet: Edge installs through the device management platforms already in place using a managed MDM configuration covering Jamf, Microsoft Intune, Kandji, Omnissa Workspace ONE, and JumpCloud.
How the Two Layers Reinforce Each Other
Think of the Bifrost AI gateway as the control plane and policy engine, with Bifrost Edge as the layer that delivers that policy out to each machine. You author the policies a single time at the gateway, virtual keys, tool filtering, budgets, and audit logging included, and Edge then enforces those identical policies on the endpoint. The laptop never needs its own separate rule set.
| 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 |
That combination is what rounds governance out to completion. Traffic an organization already holds is secured by the gateway, the remainder is reached through the endpoint by Bifrost, and the Bifrost Enterprise feature set delivers the audit logs and compliance controls that regulated industries cannot do without.
Does MCP server governance require changing developer tools?
It does not. MCP connections at the gateway flow through Bifrost on top of the client configurations already in place, and at the endpoint Edge governs traffic down at the machine level, with no base URL to change and no SDK to swap.
What happens to an MCP server that was approved and is later denied?
At the device's next check-in the denial kicks in, and even where an app had the server configured beforehand, Edge blocks it on the machine.
How are MCP credentials kept off developer machines?
Instead of static keys, identity flows from the user's SSO sign-in, and authentication on the gateway side backs OAuth 2.0 with automatic token refresh, which takes long-lived secrets in local configuration files out of the picture.
Getting Started with MCP Server Governance
One policy, enforced in two places, is how MCP server governance pays off best: at the gateway for whatever traffic you route centrally, and at the endpoint for the AI your teams spin up themselves. Both come from Bifrost, which governs MCP traffic at the control plane as an open-source AI gateway and then carries that governance out to every machine in the fleet via Bifrost Edge. To see how MCP server governance maps onto your own environment, book a demo with the Bifrost team.
Top comments (0)