MCP Governance Framework: Controls for Enterprise AI
TL;DR
- An MCP governance framework is the set of identity, authorization, tool-scope, cost, and audit controls an organization applies to every MCP server its AI agents can reach.
- A December 2025 survey of 300 IT and security professionals by the Cloud Security Alliance and Google Cloud, The State of AI Security and Governance, found that only 26% of organizations have comprehensive AI security governance policies in place.
- Governance written into each application's config file cannot be enforced centrally or audited, so the control point has to sit where every MCP request already passes.
- Bifrost enforces MCP governance at the gateway with six authentication types, three stacked levels of tool filtering, virtual keys that carry budgets and rate limits, and signed audit logs.
- Code Mode reduced input tokens by up to 92.8% in benchmarks spanning 16 MCP servers and 508 tools, which is what makes a large governed MCP deployment affordable to run.
An MCP governance framework is the set of controls that decides which MCP servers an organization allows, which identity each tool call runs as, which tools that identity may invoke, and how every invocation is recorded. Most enterprises now need one: MCP moved to vendor-neutral stewardship under the Linux Foundation's Agentic AI Foundation in December 2025 with more than 10,000 active public servers already deployed, and agent traffic reaching those servers rarely passes through anything a security team controls. Bifrost, the open-source MCP gateway built in Go by Maxim AI, applies these controls at a single point in the request path. This post covers what belongs in an MCP governance framework, where each control is enforced, and how to configure it.
What Is an MCP Governance Framework?
An MCP governance framework is a layered control model covering server approval, identity, tool authorization, cost, and audit for every Model Context Protocol connection in an organization. It answers five questions about each tool call, and each answer maps to a control that has to be enforced somewhere in the request path rather than described in a policy document.
| Question | Control | Risk when it is missing |
|---|---|---|
| Which MCP servers are allowed? | Server inventory and allowlist | Unreviewed servers reach internal data |
| Who is this tool call running as? | Per-user identity and credential binding | Shared credentials, no attribution |
| Which tools can that identity invoke? | Tool filtering and scoping | An agent scoped to read also receives write tools |
| What may this cost? | Budgets and rate limits | Token spend grows without a ceiling |
| What happened, and can it be proven? | Request logs and audit trails | No evidence for SOC 2, HIPAA, or GDPR review |
Most published guidance stops at the first and fifth rows. The three in the middle are where agent behavior actually diverges from intent, and they are the reason MCP governance needs a runtime enforcement point rather than a review process. Bifrost treats governance as request-path enforcement, so each of the five rows resolves before a tool executes, not after.
Why MCP Governance Fails at the Application Layer
MCP configuration lives inside each AI application: a JSON file listing servers, commands, and credentials. That placement is the core problem, because policy expressed in a file on a developer's machine has no central enforcement point, no inventory, and no record of what ran.
Three failures follow from it. Credentials are copied into config files and never rotated, so offboarding a user does not revoke their tool access. Every application holds its own server list, so no one can answer which MCP servers are reachable across the organization. And tool calls execute locally, leaving no trace in any system a compliance team reviews. This is the argument for treating MCP as a governed layer rather than a developer convenience, and it is why the framework has to be anchored to infrastructure that sits in front of the protocol. Everything else in how MCP governance works in practice follows from where that enforcement point sits.
Shadow AI and Unapproved MCP Servers
Shadow AI is the AI usage inside an organization that was never configured to point at approved infrastructure: personal chat accounts, browser assistants, coding agents, and the MCP servers wired into each of them. It is the failure mode that defeats an otherwise sound MCP governance framework, because a control that users opt into is a control that the least careful team skips.
The scale is the issue. A single engineer connecting a filesystem server, a database server, and a ticketing server to a local agent has created three new paths to internal data, none of them reviewed. Getting visibility and control over shadow MCP servers means discovering what is configured on each machine and deciding server by server, which is a different problem from governing the traffic that already reaches the gateway. A complete framework covers both, and governs MCP servers across the gateway and the endpoint rather than assuming every request arrives at the front door.
MCP OAuth and the Identity Behind Each Tool Call
Identity is the control that most MCP deployments skip. The MCP specification requires authorization servers to implement OAuth 2.1 and requires MCP servers to publish Protected Resource Metadata (RFC 9728), but a shared admin credential still satisfies that requirement while erasing the distinction between users.
Bifrost, the open-source AI gateway, supports six MCP authentication types, split between server-level credentials configured once by an admin and per-user credentials bound to the caller's identity.
| Auth type | Who authenticates | When to use it |
|---|---|---|
none |
Nobody | Public servers and local STDIO tools |
headers |
Admin, once | A shared API key the whole team uses |
per_user_headers |
Each end user | Per-user API keys or signed tokens |
oauth |
Admin, once | A shared third-party service |
per_user_oauth |
Each end user | Per-user services such as Notion, GitHub, or Sentry |
token_exchange |
Each caller, every call | Internal servers that trust your identity provider |
Token exchange is the option built for regulated environments: the caller's identity-provider token is exchanged on each call and never stored, so revoking a user at the IdP takes effect within the cached token lifetime rather than requiring a credential sweep. Teams choosing between these models can compare OAuth, API keys, and token management for MCP before standardizing on one.
MCP Server Security Starts With Tool Scope
MCP server security depends less on the transport than on how narrowly each identity's tool access is drawn. A server exposing 40 tools grants all 40 unless something narrows the set, and an agent that can read a repository and also open pull requests is a materially different risk from one that can only read.
Tool filtering in the Bifrost gateway stacks three levels, and a tool has to pass all of them:
- Client configuration sets the baseline through
tools_to_execute, which is deny-by-default when omitted. - Request headers narrow the set for a single request.
- Virtual key configuration binds a tool set to the credential making the call.
Virtual MCPs take this further by bundling chosen tools from several servers behind one addressable endpoint at /mcp/<slug>, reachable only through the virtual keys it is attached to. A support team gets a curated bundle rather than raw access to six servers, and the same filtering, allowlisting, and access control patterns apply whether the tools come from one server or ten.
Scope is only half of it. By default the gateway does not auto-execute tool calls at all: tool execution is an explicit step, and autonomous execution is opt-in per tool, which keeps a human decision in the path for anything destructive.
What Is an MCP Gateway, and Where Does It Sit?
An MCP gateway is a control layer that sits between AI applications and MCP servers, centralizing connection, authentication, tool filtering, and logging for every tool call. It is the enforcement point an MCP governance framework needs, because it is the one place where identity, scope, cost, and audit can all be resolved before a tool runs.
The Bifrost AI gateway operates as both an MCP client and an MCP server, connecting outward to tool servers over STDIO, HTTP, or SSE while exposing a governed tool surface to clients such as Claude Desktop. That two-sided position is what lets one configuration serve an entire organization.
For a fuller architectural picture, the MCP gateway resource page covers deployment topologies, and how an MCP gateway works end to end walks through the request path.
Budgets and Rate Limits for Enterprise MCP Traffic
Cost control belongs in the framework because agentic tool use multiplies token consumption. Enterprise MCP deployments connecting 8 to 10 servers push every tool definition into context on every turn, and the bill grows with the tool count rather than with the work completed.
In the Bifrost platform, virtual keys are the primary governance entity: each carries model and provider access rules, its own budget, and token or request rate limits, and attaches to exactly one team or one customer. Budgets and limits are hierarchical, so a customer budget, a team budget, and a key budget are all checked before a request proceeds, with reset periods from one minute to one year.
The structural fix for context cost is Code Mode, which exposes four meta-tools instead of the full catalog and lets the model write sandboxed Python to orchestrate the rest. Across 16 servers and 508 tools, that cut input tokens by 92.8% and estimated cost by 92.2%, with pass rates holding at 100%; the full MCP gateway benchmark documents all three rounds.
Audit Logs and MCP Observability for Compliance
Auditability is the row of the framework that regulators read. Two distinct records are needed, and conflating them is a common gap: request-level telemetry showing what agents did, and administrative records showing who changed the policy.
Bifrost captures both. Built-in observability records inputs, outputs, tokens, cost, and latency for every request, written asynchronously so logging adds no request latency.
Audit logs in Bifrost Enterprise record administrative activity instead: who changed which resource and when, optionally signed with an HMAC key, retained for a configurable period, exportable as JSON, JSON Lines, or Syslog, and archivable to S3 or GCS for long-term retention. For regulated deployments, the Bifrost Enterprise tier adds role-based access control and data access control that scopes which configuration rows each operator can see.
Extending MCP Governance to Every Endpoint
Gateway-side controls govern the traffic that reaches the gateway. The remainder, meaning the desktop chat apps, browser AI, and coding agents nobody reconfigured, is where an MCP governance framework leaks. Closing that gap is the job of the AI Gateway plus Bifrost Edge model: the gateway remains the control plane and policy engine, and Bifrost Edge extends the same policies to each machine.
Edge inventories the MCP servers configured inside supported AI apps on every device, reports them into a fleet-wide view, and enforces an allow or deny decision on the device itself, so a denied server cannot be used by an app that had it configured before the policy existed.
The budgets, audit trails, and guardrails already defined at the Bifrost gateway, including secrets detection, PII redaction, and prompt-injection defense, are the policies Edge carries to the endpoint. Edge runs on macOS, Windows, and Linux and deploys fleet-wide through MDM tools such as Jamf, Intune, and Kandji. It is currently in alpha, so plan a pilot rather than a fleet-wide rollout.
Frequently Asked Questions
How to govern MCP servers?
Route MCP traffic through a gateway that authenticates each caller, filters the tool set per identity, applies budgets, and logs every call. Maintain an approved server inventory, bind credentials to users rather than machines, and deny by default. The governance resource page covers the configuration sequence for each of those controls.
What are the four pillars of AI governance?
Most frameworks group controls into accountability, transparency, fairness, and security, with risk management running through all four. The NIST AI Risk Management Framework organizes the same ground as govern, map, measure, and manage. For MCP specifically, the pillars translate into server approval, identity, tool scope, and audit.
What is an MCP in business?
MCP is the Model Context Protocol, an open standard that lets AI applications connect to external tools and data sources through one interface. In business terms, it is how an AI assistant reaches a CRM, a data warehouse, or a ticketing system without a custom integration for each. That reach is exactly why it needs governance.
What is an MCP gateway?
An MCP gateway is infrastructure that sits between AI applications and MCP servers and centralizes authentication, tool filtering, execution policy, and logging. It replaces per-application configuration with one governed connection point. The MCP gateway overview details how the gateway connects outward to tool servers and inward to clients.
Does the MCP specification require OAuth?
The specification requires authorization servers to implement OAuth 2.1 and requires MCP servers to publish Protected Resource Metadata for authorization server discovery. STDIO connections are the exception, since they inherit credentials from the spawned process environment. A gateway can add per-user OAuth or token exchange on top of servers that support neither.
How is MCP governance different from API governance?
API governance assumes a human or a service account made a deliberate call. MCP governance has to account for a model choosing which tool to call, with arguments it generated, inside a loop. That shifts the emphasis toward tool-level scoping, execution approval, and per-call identity rather than endpoint-level rate limiting alone.
Getting Started With MCP Governance in Bifrost
An MCP governance framework becomes real at the point where a tool call is either allowed or refused. Bifrost as the enforcement layer puts that point in the request path: six authentication types, three levels of tool filtering, virtual keys carrying budgets and rate limits, request-level observability, and signed administrative audit trails, all configured once for every agent in the organization. Connect a first MCP server through the gateway and scope it to one virtual key, then widen from there. To walk through MCP governance for a regulated or fleet-scale deployment, book a demo with the Bifrost team.
