TL;DR
- MCP governance is the set of controls that decides which agents can call which MCP tools, records what each tool call did, and caps the spend that tool-using agents generate.
- The Model Context Protocol standardizes how agents discover and call tools, but it does not define organization-wide tool permissions, audit trails, or budgets.
- Bifrost enforces MCP governance at the gateway with deny-by-default tool allow-lists per virtual key, MCP log entries for tool activity, and hierarchical budgets across virtual keys, teams, and customers.
- Bifrost Code Mode reduced input tokens by 92.8% and estimated cost by 92.2% in a benchmark with 508 tools across 16 MCP servers.
An AI agent connected to ten MCP servers can typically reach every tool on those servers, under whichever shared credential was configured, with no record tying each call to a user and no ceiling on the tokens those tool definitions consume. MCP governance closes those gaps by placing access control, audit, and cost policy between agents and tool servers. Bifrost, the open-source AI gateway for LLM and MCP traffic built by Maxim AI, applies that policy at a single enforcement point for every agent in an organization. This article explains why MCP needs a governance layer and how each of its three pillars works in production.
What Is MCP Governance?
MCP governance is the policy layer that controls how AI agents use Model Context Protocol tools across an organization. It covers three concerns: access control (which identities may call which tools), audit (a durable record of tool activity), and cost (limits on the model spend that tool-using agents drive). A gateway is the usual place to enforce all three.
The protocol itself is intentionally narrow. The MCP specification defines how clients list and invoke tools, resources, and prompts on a server. It does not define which of 500 tools a finance agent may call, how long tool logs are retained, or what limits an agent loop's spend. Those are organizational decisions that need an enforcement point.
The broader concept, including how governance differs from basic MCP server management, is covered in our explainer on what MCP governance is and how it works.
MCP Security Risks That Governance Addresses
MCP security risks grow with the number of servers, tools, and agents in play. Without governance, agents run with broader permissions than the humans who invoke them, credentials are shared across users, tool calls cannot be attributed, and spend has no ceiling. Each of these failures maps to one governance control.
| Ungoverned MCP pattern | Resulting risk | Governance control |
|---|---|---|
| Agents reach every tool on a connected server | Destructive or data-exfiltrating tools are callable by any agent | Tool-level, deny-by-default allow-lists |
| One admin token serves all users | Upstream systems cannot distinguish who acted | Per-user credentials or token exchange |
| Tool calls go directly from client to server | No record of which identity called which tool | Centralized MCP logging with identity metadata |
| Tool definitions load on each request | Token spend scales with catalog size, not with work done | Tool filtering, on-demand tool loading, budgets |
| Configuration changes happen ad hoc | No history of who widened access and when | Administrative audit logs |
The MCP project documents several of these threats directly. The MCP security best practices describe the confused deputy problem in OAuth proxy flows and warn against token passthrough, where a server forwards a client's token to downstream APIs without validating that it was issued for that server. Our breakdown of MCP security risks and how to mitigate them covers the attack patterns.
MCP Authorization and Tool-Level Access Control
MCP authorization at the governance layer means enforcing, on every request, which tools a given identity can see and execute. Effective access control is tool-level rather than server-level, deny-by-default rather than allow-by-default, and tied to real identities rather than one shared key, so a compromised or confused agent can only reach what it was explicitly granted.
The MCP authorization specification treats a protected MCP server as an OAuth 2.1 resource server. That secures the connection to one server, but not how tools are scoped across dozens of servers and hundreds of users, which a dedicated MCP governance layer handles at the gateway.
Deny-by-default tool filtering
In Bifrost, a virtual key is the primary governance entity. A virtual key with no MCP configuration exposes no MCP tools, apart from clients an administrator explicitly marks as allowed by default. MCP tool filtering per virtual key turns the key's configuration into a strict allow-list that request headers can narrow but never widen, and the allow-list is enforced again at execution time.
Filtering stacks across three levels:
-
Client configuration: Each MCP client's
tools_to_executefield sets the baseline of tools that can ever be exposed. - Request headers: Individual requests can narrow the tool set further for a specific task.
- Virtual key: Each consumer's key defines its own allow-list, and a tool must pass every applicable level.
Virtual MCPs add curated bundles on top of this model. A Virtual MCP groups selected tools from several servers behind a stable /mcp/<slug> endpoint that is reachable only through the virtual keys it is attached to. The enterprise patterns for these controls are covered in MCP tool governance with filtering and allow-listing.
Identity-bound credentials
Bifrost authenticates in both directions. Clients connect to the /mcp endpoint with virtual key headers or through OAuth 2.1 browser consent, where Bifrost issues short-lived JWTs. Toward upstream servers, Bifrost supports six authentication types, including per-user OAuth and per-user headers, which store each credential against the caller's identity, and token exchange (enterprise), which exchanges the caller's identity-provider token on each call without persisting it.
Explicit execution by default
Bifrost does not execute tool calls automatically. A model's tool call is treated as a suggestion, and execution requires a separate API call unless Agent Mode is enabled for specific tools. This default keeps a human or application checkpoint in front of write operations until a team deliberately opts into autonomous execution.
MCP Logging and Audit Trails
MCP logging and audit trails answer two separate questions: what did agents do with tools, and who changed the policy that allowed it. A governance layer needs both, because investigating an incident requires the tool-call record, and proving compliance requires a tamper-evident history of access changes.
Bifrost records these at two layers:
- Tool activity: Built-in observability captures MCP log entries alongside LLM log entries, and configured request headers are copied into each entry's metadata for tenant and request tracing.
- Administrative activity: Enterprise audit logs record who changed what, when, and on which resource. Entries can be HMAC-signed for verification and exported as JSON, JSON Lines, or Syslog.
- Long-term retention: Audit events can be archived to S3 or GCS as time-windowed JSONL objects, and log exports offload request and response payloads to object storage while searchable metadata stays in the logs database.
An incident review typically uses both: the MCP log entry shows the tool call, and the audit log shows when that agent's key gained access to the tool. For a deeper look at tool-call logging patterns, see auditing every AI tool call through an MCP gateway.
Controlling MCP Cost as Tool Catalogs Grow
MCP cost is driven mainly by model tokens, not tool execution. When an agent connects to many MCP servers, tool definitions are sent to the model on each turn, intermediate tool results flow back through the context, and agent loops repeat both. Governance controls that cost by limiting which definitions reach the model and by enforcing budgets on the traffic.
The scale of the problem shows up clearly in Bifrost's Code Mode benchmark, which ran the same query set with classic MCP and with Code Mode enabled:
| MCP footprint | Input tokens, classic MCP | Input tokens, Code Mode | Input token change | Estimated cost change |
|---|---|---|---|---|
| 96 tools across 6 servers | 19.9M | 8.3M | -58.2% | -55.7% |
| 251 tools across 11 servers | 35.7M | 5.5M | -84.5% | -83.4% |
| 508 tools across 16 servers | 75.1M | 5.4M | -92.8% | -92.2% |
Classic MCP token usage rose with every server added, while Code Mode usage stayed between 5.4M and 8.3M tokens because it exposes four meta-tools and loads tool definitions on demand. Pass rates held at 100% for Code Mode in all three rounds. The MCP gateway cost governance benchmark details the methodology, and the hidden cost of connecting multiple MCP servers to an agent explains why the curve looks this way.
Budgets supply the hard ceiling. Bifrost applies hierarchical budgets across virtual keys, teams, and customers, plus rate limits at the virtual key and provider level, and a request proceeds only if every applicable budget in that chain has remaining balance. Reset durations range from one minute to one year, budgets can align to calendar periods in UTC, and Bifrost Enterprise adds alert rules that notify Slack, Microsoft Teams, PagerDuty, or webhooks when a budget crosses a threshold.
How Bifrost Implements MCP Governance
Bifrost implements governance for MCP by attaching tool permissions, logging, and spend limits to the same virtual key that authenticates an agent's model traffic. Because one gateway sees both the LLM request and the tool call, a single policy object governs what an agent can reach, what gets recorded, and how much it can spend.
| Governance pillar | Bifrost mechanism | Availability |
|---|---|---|
| Tool access | Deny-by-default tool allow-lists per virtual key; three-level filtering; Virtual MCPs | Open source (Virtual MCPs require governance enabled) |
| Client authentication | Virtual key headers or OAuth 2.1 with short-lived JWTs | Open source |
| Upstream credentials | None, headers, OAuth 2.0, per-user OAuth, per-user headers; token exchange | Open source; token exchange in Enterprise |
| Tool activity records | MCP and LLM log entries with header metadata | Open source |
| Change history | HMAC-signable audit logs with export and object storage archival | Enterprise |
| Spend control | Hierarchical budgets, virtual key rate limits, Code Mode | Open source |
| Policy at scale | Access profiles, RBAC, budget alerting | Enterprise |
Access profiles are the mechanism that makes this manageable across an organization. An access profile defines providers, models, budgets, rate limits, and MCP tool access once, then auto-issues a write-protected virtual key to every user in a role, so users cannot weaken their own policy and every profile change is recorded with snapshot history. The Bifrost governance resource page shows how these pieces fit together, and our guide to AI governance with virtual keys for LLM and MCP traffic walks through a full configuration.
Bifrost Enterprise Prompt Guardrails add content-level policy, using an LLM judge to allow or block LLM and MCP inputs and outputs. The gateway adds 11 microseconds of overhead per request at 5,000 RPS in sustained benchmarks.
An MCP Governance Framework for Rollout
A practical MCP governance framework introduces controls in the order that reduces risk fastest: centralize connections first, restrict tools second, attribute activity third, and cap spend last.
- Centralize MCP connections. Route agents through one gateway endpoint instead of letting each client connect to servers directly, so there is a single enforcement point.
- Start deny-by-default. Issue virtual keys with no tool access, then grant tools per team or use case, bundling them into Virtual MCPs where several agents share a tool set.
- Bind credentials to identities. Move shared admin tokens to per-user OAuth or token exchange for upstream systems where attribution matters.
- Turn on logging with identity metadata. Capture tenant, user, or session headers into MCP log entries so each tool call is attributable.
- Set budgets at every level. Apply budgets to virtual keys, teams, and customers, and enable Code Mode for agents connected to three or more MCP servers.
- Review access changes. Use audit logs to verify who granted which tools, and prune grants that logs show are unused.
Teams operating in regulated environments can compare this sequence with the Bifrost Enterprise controls for identity, in-VPC deployment, and audit, and with the controls in our enterprise MCP security best practices checklist.
Frequently Asked Questions
What is MCP governance?
MCP governance is the set of policies and controls that determine how AI agents use Model Context Protocol tools. It covers access control over which identities can call which tools, audit records of tool activity and policy changes, and cost limits on the model spend that tool-using agents generate. Organizations typically enforce these controls at a gateway between agents and MCP servers.
Is MCP secure?
MCP defines secure building blocks, including OAuth 2.1-based authorization for protected servers, but security in practice depends on deployment. The MCP specification itself documents risks such as confused deputy attacks and token passthrough. Organizations running many servers need additional controls, such as tool-level allow-lists, per-user credentials, and centralized logging, to use MCP safely at scale.
How is MCP governance different from MCP security?
MCP security focuses on protecting individual connections and servers from attacks like token misuse or malicious tool descriptions. Governance is broader and organizational: it decides who is allowed to use which tools, keeps records for audit and compliance, and controls cost. A secure MCP server can still be poorly governed if every agent can reach every tool with no spend limit.
How do you control MCP token costs?
MCP token costs are controlled by reducing the tool definitions sent to the model and by capping spend. Tool filtering per virtual key removes irrelevant tools, and Bifrost Code Mode loads tool definitions on demand through four meta-tools. Hierarchical budgets across virtual keys, teams, and customers then set a hard ceiling that requests cannot exceed.
What is agentic AI governance?
Agentic AI governance is the practice of controlling what autonomous AI agents can access, do, and spend. Because agents choose actions at runtime, governance has to cover both model access and tool access. Tool governance is a core part of it, since MCP is how many agents reach external systems. Bifrost governs both through one virtual key policy model.
Put MCP Governance in Place with Bifrost
MCP governance turns an open tool protocol into infrastructure an organization can trust: agents reach only the tools they are granted, every tool call and policy change leaves a record, and spend stays inside defined budgets. Bifrost enforces all three at one gateway for both LLM and MCP traffic. Explore implementation guides in the Bifrost resources library.
To see how Bifrost applies access control, audit, and cost governance to MCP tools across your teams, book a demo with the Bifrost team.
Top comments (0)