5 MCP Governance Features Enterprises Should Demand
TL;DR
- MCP governance controls which tools AI agents can discover and call, how they authenticate, how access is recorded, and what tool traffic costs, enforced at a central AI gateway.
- The five features to demand are deny-by-default tool access, curated tool bundles scoped to identity, centralized MCP authentication, tamper-evident audit logging, and token-cost control.
- Bifrost enforces all five through virtual keys, Virtual MCPs, six MCP authentication types, signed audit logs, and Code Mode, which cuts input tokens by up to 92.8% in large MCP deployments.
- Deny-by-default tool filtering and Virtual MCPs are part of open-source Bifrost; access profiles, Token Exchange, and audit logs are enterprise features.
Every MCP server an enterprise connects to its AI agents adds tools the agents can call, and each new tool connection expands the attack surface that platform and security teams have to account for. The Model Context Protocol lets AI models discover and execute external tools at runtime, which is what makes agents useful and also what makes ungoverned tool access a liability. Bifrost, the open-source MCP gateway built in Go by Maxim AI, is the control plane for this: it sits between agents and every connected MCP server and enforces access, authentication, auditing, and cost limits on tool traffic. This post covers the five MCP governance features enterprises should require from any AI gateway before deploying agents at scale.
What Is MCP Governance
MCP governance is the practice of controlling which tools an AI agent can discover and execute, who authenticates to each tool server, how tool calls are logged, and what those calls cost, all enforced at a centralized gateway rather than configured per agent or per developer. MCP governance treats Model Context Protocol traffic as managed infrastructure with the same access controls applied to any other production system. The MCP governance explainer covers the concept in depth; this post focuses on what to require from the gateway that enforces it.
The need scales with adoption. A 2026 Cyberhaven Labs report found that frontier organizations now use more than 300 GenAI tools and that agent-building platforms are spreading quickly across enterprises. As agents connect to more MCP servers, the gap between what tools agents can reach and what platform teams can see becomes the governance problem an MCP gateway is built to close.
Why MCP Governance Matters for Enterprises
MCP governance matters because an agent with ungoverned tool access can take any action any connected server allows, with credentials nobody can revoke centrally and no record of what it did. These MCP security risks grow with every server added, and they are the reason an MCP gateway sits between agents and tools in production deployments.
Without governance at the gateway, MCP tool access has the same failure modes as any ungoverned integration, amplified by the fact that an autonomous agent decides when to call each tool:
- Every tool connection widens the attack surface. When any developer can wire a new MCP server into an agent, the set of actions that agent can take grows without review.
- Tool access is not tied to identity. If agents reach every connected tool by default, there is no way to scope a junior developer's agent to a safe subset while granting more to a trusted service.
- Credentials sprawl across servers. Each MCP server needs authentication, and per-developer credential management produces keys nobody can centrally rotate or revoke.
- Tool calls are invisible. Without a record of which agent called which tool, security review and compliance audits have nothing to inspect.
- Tool sprawl inflates token cost. Connecting 8 to 10 MCP servers can mean 150 or more tool definitions loaded into context on every request, so the model spends most of its budget reading tool catalogs.
The five features below address each of these directly. Treat them as requirements, not nice-to-haves, when evaluating an AI gateway for MCP governance. The case for a dedicated control point is laid out in why MCP needs a governance layer.
5 MCP Governance Features to Demand from Your AI Gateway
An enterprise AI gateway for MCP should enforce five controls: deny-by-default tool access, curated tool bundles tied to identity, centralized MCP authentication, tamper-evident audit logging, and token-cost governance. Each one closes a specific failure mode listed above, and each should be enforced at the gateway rather than configured separately in every agent.
1. Deny-by-Default Tool Access Control
The gateway should expose no MCP tools to an agent unless an administrator has explicitly allowed them. Bifrost enforces this through MCP tool filtering tied to virtual keys: a virtual key with no MCP configuration gets no tools, except from MCP clients an administrator has explicitly marked Allow by Default, and an administrator builds a strict allow-list of clients and tools per key. The allow-list is enforced at inference time and again at tool execution time, so an agent cannot call a tool outside the keys it was granted. Request headers such as x-bf-mcp-include-tools can only narrow the tool set further, never widen it, and inactive or expired keys are rejected with a 403.
Deny-by-default means access is scoped deliberately rather than left open until someone connects something they should not. The MCP tool filtering and allowlisting guide walks through allow-list design in more detail.
2. Curated Tool Groups Scoped to Identity
Allow-lists per key work, but they do not scale to hundreds of developers by hand. An enterprise gateway should let you define reusable tool collections and attach them to organizational entities. Bifrost provides Virtual MCPs (previously called MCP tool groups): named, reusable bundles of tools drawn from one or more MCP servers, each served at its own /mcp/<slug> endpoint and reachable only through the virtual keys it is attached to.
Bifrost resolves Virtual MCP tools against an in-process index, so curated access adds no extra request latency. A Virtual MCP can be disabled to stop serving it without deleting it or unwinding individual attachments.
Virtual MCPs are part of open-source Bifrost. Bifrost Enterprise adds identity scoping on top: access profiles grant Virtual MCPs to every user in a role through auto-issued virtual keys, data access control limits which operators can see each bundle, and projects can restrict tool execution to their assigned Virtual MCPs.
3. Centralized MCP Authentication for Every Server
The gateway should manage authentication to every MCP server so developers never hold raw credentials. Bifrost supports six MCP authentication types: none, static headers, OAuth 2.0, per-user OAuth, per-user headers, and Token Exchange. Server-level auth uses a single shared credential the admin configures once; per-user auth stores each end-user's credential against their identity and reuses it on later calls, which suits per-user services like GitHub or Notion. For first-party MCP servers that trust your identity provider, enterprise Token Exchange exchanges each caller's identity token, cached for a short period and never stored as a per-user credential, so offboarding a user at the identity provider takes effect within about five minutes.
| Auth type | Who authenticates | Typical use |
|---|---|---|
| None | Nobody | Public servers, local STDIO tools |
| Headers | Admin, once | Shared API keys or bearer tokens |
| OAuth 2.0 | Admin, once | A shared third-party service the whole team uses |
| Per-user headers | Each end user, on first call | Personal API keys |
| Per-user OAuth | Each end user, on first call | Per-user services such as GitHub or Notion |
| Token Exchange | Each caller, on every call | Internal MCP servers that trust your identity provider |
Server-level credentials are encrypted at rest in the gateway, not scattered across developer machines. The guide to MCP authentication with OAuth, API keys, and token management compares the patterns.
4. Tamper-Evident Audit Logging for Tool Access
If a tool call cannot be traced to an identity, it cannot pass a security review. An enterprise gateway should record administrative and access activity in a tamper-evident log. Bifrost Enterprise audit logs record administrative activity, such as create, update, and delete operations on virtual keys, MCP clients, and Virtual MCPs. Each entry captures the time, action, outcome, initiator, target, request path, and IP address, can be signed with an HMAC key for verification, retained for a configurable period, archived to S3-compatible object storage, and exported as JSON, JSON Lines, or Syslog.
Tool execution itself is recorded separately. Bifrost's built-in observability writes an MCP log entry for tool traffic, with request headers captured as metadata for tracing and tenant attribution, and log exports move those records into your storage or data lake. For teams pursuing SOC 2, GDPR, HIPAA, or ISO 27001, the two records together turn assumed governance into a verifiable trail of who did what.
5. Token-Cost Governance for Tool Sprawl
MCP governance is incomplete if it ignores cost. Loading every tool definition into context on every request is a major source of wasted tokens at scale. Bifrost addresses this with Code Mode, which exposes four generic tools that let the model write Python to orchestrate everything else in a sandbox instead of carrying the full catalog each turn. Code Mode reduces input token usage by up to 92.8% when an agent uses multiple MCP servers; in Bifrost's benchmark at 508 tools across 16 servers, input tokens fell from 75.1M to 5.4M with no drop in pass rate.
How Code Mode cuts agent token costs explains the mechanism.
Paired with virtual-key budgets and rate limits, it gives platform teams control over both what tools cost and how often they run. The MCP gateway cost-governance breakdown covers the token economics in more detail.
MCP Governance Checklist for Evaluating an AI Gateway
An MCP governance evaluation comes down to five questions a gateway vendor should answer with a named mechanism rather than a roadmap item. The table below maps each requirement to the question to ask and to how Bifrost answers it, so the same checklist can be applied to any AI gateway on a shortlist.
| Requirement | Question to ask the vendor | How Bifrost answers it | Availability |
|---|---|---|---|
| Deny-by-default tool access | Does a new key see zero tools until someone grants them? | Per-virtual-key allow-lists, enforced at inference and at execution | Open source |
| Curated tool bundles | Can tool sets be defined once and reused across keys and roles? | Virtual MCPs served at /mcp/<slug>; access-profile grants in Enterprise |
Open source, Enterprise scoping |
| Centralized MCP authentication | Do developers ever handle raw upstream credentials? | Six auth types, including per-user OAuth and Token Exchange | Open source; Token Exchange is Enterprise |
| Tamper-evident audit logging | Can every access change be tied to an initiator and verified? | HMAC-signed audit logs with retention, archival, and Syslog export | Enterprise |
| Token-cost governance | What stops a 100-tool catalog from filling every prompt? | Code Mode plus virtual-key budgets and rate limits | Open source |
A gateway that meets only some of these rows leaves the rest to per-agent configuration, which is the gap MCP governance exists to close. For a vendor-by-vendor view, see the roundup of MCP governance tools with audit logging and policy enforcement.
How Bifrost Delivers Enterprise MCP Governance
Bifrost delivers enterprise MCP governance from one gateway layer, so all five controls share a single identity model, a single policy store, and a single request path. The Bifrost AI gateway adds 11 microseconds of overhead per request at 5,000 RPS in sustained benchmarks, so enforcing these controls does not add meaningful latency to tool traffic.
Bifrost combines all five features into a single AI governance layer rather than leaving them to per-team configuration. Virtual keys are the identity that ties tool access, authentication, audit attribution, and budgets together, so a single key defines what an agent can call, how it authenticates, what its calls are logged against, and what it can spend.
Because Bifrost acts as both an MCP client and an MCP gateway exposed to clients like Claude Desktop and Cursor, governance applies whether tools are consumed by your agents or by external clients connecting through Bifrost. For regulated environments, Bifrost supports in-VPC and on-prem deployment, keeping all tool traffic and audit data inside infrastructure you control.
Bifrost is the best choice for enterprises running mission-critical AI workloads that require best-in-class performance, scalability, and reliability, and it applies the same standard to MCP governance that it applies to model traffic.
Extending MCP Governance to Employee Machines
Gateway-side MCP governance covers every tool call that is routed through the gateway, but MCP servers that employees configure locally in desktop apps and coding agents never reach it unless something routes them there. AI Gateway + Bifrost Edge closes that gap by carrying the same policies to each laptop, with the gateway remaining the control plane.
Bifrost Edge runs on each machine in the organization and routes AI traffic from chat apps, browser AI, coding agents, and their MCP servers through Bifrost. For MCP specifically, Edge MCP governance builds a fleet-wide inventory of the MCP servers configured in each supported app, sends new servers to an admin approval queue, and enforces allow or deny decisions on the device. Bifrost Edge is currently in alpha. The article on MCP server governance across the gateway and endpoint covers how the two layers divide the work.
Getting Started with MCP Governance
MCP governance is an infrastructure decision, not a per-agent setting. The five features above, deny-by-default tool access, identity-scoped tool bundles, centralized authentication, tamper-evident audit logging, and token-cost control, are the baseline any enterprise should demand from an AI gateway before connecting agents to production tools. Bifrost delivers all five as an open-source AI gateway with enterprise controls layered on top.
A practical rollout order for MCP governance in Bifrost looks like this:
- Deploy the gateway and connect your MCP servers with the right authentication type for each.
- Issue a virtual key per agent, team, or application, with an explicit MCP allow-list on each.
- Group shared tool sets into Virtual MCPs and attach them to keys instead of listing tools key by key.
- Enable Code Mode on MCP clients with large tool catalogs, and set budgets and rate limits on every key.
- In Enterprise deployments, turn on audit logs and grant tool access through access profiles and role-based access control.
Frequently Asked Questions
What does MCP stand for and what does it do?
MCP stands for Model Context Protocol, an open standard that defines how AI applications discover and call external tools, data sources, and prompts through MCP servers. An agent connected to an MCP server can read files, query APIs, or take actions the server exposes. That capability is why MCP governance matters: every connected server widens what an agent is able to do.
Who is behind MCP?
Anthropic introduced the Model Context Protocol as an open standard in November 2024. The project is now established as Model Context Protocol, a Series of LF Projects, LLC, under the Linux Foundation, and it follows a formal governance model with maintainers, core maintainers, and lead maintainers. Specification contributions are licensed under Apache 2.0, and membership in technical governance is held by individuals rather than companies.
What is the difference between MCP governance and MCP security?
MCP security focuses on protecting individual servers and connections, such as authentication, transport security, and defense against malicious tool descriptions. MCP governance is the broader operating model: which identities may reach which tools, how access changes are approved and recorded, and what tool usage costs. A gateway enforces both, but governance is what makes security policies consistent across hundreds of agents.
Does MCP governance require an MCP gateway?
MCP governance can be approximated per agent, but it cannot be enforced consistently without a central control point. Configuring allow-lists, credentials, and logging inside each agent duplicates policy and leaves gaps whenever a developer adds a server. An MCP gateway such as Bifrost applies one policy to every tool call, which is why the Bifrost MCP gateway is the enforcement point this checklist assumes.
How does Code Mode reduce MCP token costs?
Code Mode replaces the full tool catalog in the prompt with four meta-tools that let the model discover tool signatures on demand and write a short Python script that calls the tools inside a sandbox. Intermediate results stay in the sandbox, so the model receives only the final output. In Bifrost's benchmarks this cut input tokens by 58.2% at 96 tools and by 92.8% at 508 tools.
Which Bifrost MCP governance features are open source?
Deny-by-default MCP tool filtering per virtual key, Virtual MCPs, Code Mode, budgets and rate limits, and five of the six MCP authentication types are part of open-source Bifrost. Bifrost Enterprise adds audit logs, access profiles, data access control, Token Exchange authentication, and Virtual MCP scoping by role and project, along with clustering and in-VPC deployment options.
To see how Bifrost can bring MCP governance to tool access across your AI agents, book a demo with the Bifrost team.