MCP Server Governance: Best Practices and Tools
Six best practices for MCP server governance, covering tool access control, authentication, approval gating and audit logging.
TL;DR
- MCP server governance is the set of controls deciding which agents call which tools, under whose identity, with a record of what happened.
- Governance has to operate at the tool level, not the connection level, because an MCP-connected agent discovers new tools at runtime.
- Six best practices cover it: least-privilege tool access, identity-aware authentication, approval for high-risk calls, per-call request logging with caller identity, filtering at multiple layers, and role-based control over the governance configuration itself.
- Bifrost enforces these through tool filtering that stacks across three levels, six MCP authentication types, and role-based access control.
- Approval gating behaves differently depending on deployment: the auto-execute setting applies in Agent Mode and is ignored when Bifrost runs purely as an MCP gateway, where the host application owns the approval step.
Model Context Protocol (MCP) governance is the set of controls that determine which AI agents can call which tools, on which servers, under whose identity, with a record of what happened. Over 30 CVEs were filed against MCP servers, clients, and infrastructure components between January and February 2026 alone, according to a Cloud Security Alliance analysis, and that analysis concludes that standard security practices, least privilege and explicit trust verification among them, would have prevented or substantially mitigated the attacks it examines. Bifrost, the open-source MCP gateway built in Go by Maxim AI, enforces MCP server governance through per-virtual-key tool filtering, six authentication types, and role-based access control, without requiring a separate MCP security product. This post covers the core best practices and how Bifrost enforces each one.
What Is MCP Server Governance
MCP server governance is the combination of authentication, authorization, tool-level access control, and audit logging that determines what an AI agent can do through a connected MCP server, and who is accountable for each action. Unlike a traditional API integration, an MCP-connected agent can discover new tools at runtime, which means governance has to operate at the tool level, not just at the connection level.
The Model Context Protocol specification standardizes how tools are discovered and invoked, but it does not enforce security at the protocol level, leaving authentication, authorization, and transport security to whoever implements each host, client, and server. The November 2025 revision of the specification did formalize OAuth 2.1 for remote servers, which closes part of that gap, but tool-level scoping and per-invocation authorization remain the deploying platform's responsibility. That gap is exactly where governance controls need to sit. For the wider picture of MCP server governance across the gateway and the endpoint, the same controls extend to where agents actually run.
Why MCP Server Governance Matters
MCP server governance matters because the failure mode is quiet rather than loud: an over-privileged agent does exactly what it was permitted to do, and nothing alerts on it. Traditional application security controls sit at the network and API layers, which is the wrong altitude for a system where the unit of access is an individual tool discovered at runtime. The security risks of ungoverned MCP server access show up in four recurring shapes.
Four risk shapes recur:
- Over-privileged access. A default MCP setup often grants an agent every tool a connected server exposes, rather than the specific tools a task requires.
- Shared, static credentials. One API key or OAuth token shared across every caller means a single leaked credential exposes every system that server touches.
- No per-action audit trail. Without structured logging of caller identity, tool name, and outcome, reconstructing what an agent actually did after an incident becomes guesswork.
- Tool-level blind spots. Server-level access policies cannot express that a support agent should read CRM records but never delete them; that distinction requires tool-level, not server-level, control.
Wiz's analysis of Model Context Protocol security describes MCP's integration layer as introducing trust-boundary risks across identity, network, supply chain, and runtime, which is why governance needs to be enforced at the gateway rather than left to each individual MCP server's implementation. That argument is set out in full in why MCP needs a governance layer.
Best Practices for MCP Server Governance
Six practices cover MCP server governance in production: scope tool access to the task, tie credentials to an identity, gate high-risk calls behind approval, log every call with its caller, filter at more than one layer, and restrict who can change the governance configuration. They are ordered roughly by blast radius when absent, not by how hard they are to implement. Centralizing agent tool access through an MCP gateway is what makes enforcing them once rather than per server practical.
The practices below hold regardless of which platform enforces them:
- Enforce least-privilege tool access. Every agent, virtual key, or client should have access only to the specific tools its task requires, not every tool a server exposes.
- Use identity-aware authentication. Credentials should be tied to a caller's identity (a user, a virtual key, or a session), not shared as a single static secret across every request.
- Require approval for high-risk tool calls. Autonomous execution should be opt-in per tool, with destructive or sensitive actions routed back to a human or an explicit approval step.
- Log every tool call with caller identity. Request logs should capture who called which tool, with what arguments, and what the result was, structured enough to query during an incident.
- Isolate and filter at multiple layers. Tool access should be filterable at the client, request, and identity level, so a single misconfiguration at one layer does not expose every tool.
- Apply role-based access to governance itself. Who can create, edit, or delete MCP client configurations and virtual keys should be restricted by role, not open to every team member.
How Bifrost Enforces MCP Governance
The Bifrost AI gateway maps each of these practices to a specific, configurable control rather than leaving them as guidance. The MCP governance resources cover these controls in more depth for teams standardizing configuration across multiple agents.
Per-Virtual-Key Tool Filtering
Tool filtering in Bifrost stacks across three levels: client configuration, request headers, and virtual key configuration (the last of these in Gateway deployments), and a tool must pass all applicable filters to reach the model. MCP tool filtering on virtual keys is deny-by-default: a virtual key with no MCP configuration gets no tools at all, with one exception: clients marked Allow by Default remain reachable from any key that does not configure them explicitly. Adding a client to a virtual key requires explicitly listing which tools from that client are allowed, or using a wildcard to allow all of them, and an empty tool list blocks that client entirely.
This gives a direct answer to the "over-privileged access" and "tool-level blind spots" practices above, since access is scoped per virtual key rather than per server. Filtering, allowlisting, and access control for the enterprise covers how teams structure those allow-lists at scale.
Authentication Options for MCP Servers
Bifrost supports six MCP authentication types. Server-level types use a single admin-configured credential shared across callers, per-user types tie a credential to the caller's identity, and token exchange passes the caller's own identity-provider token through without storing anything.
| Auth type | Who supplies the credential | What reaches the server |
|---|---|---|
none |
Nobody | No upstream auth, for public or local servers |
headers |
Admin, once | Static HTTP headers shared by every caller |
oauth |
Admin, once | One OAuth 2.0 access token shared by every caller |
per_user_headers |
Each end-user, lazily | That user's own header values |
per_user_oauth |
Each end-user, lazily | That user's own OAuth 2.0 access token |
token_exchange |
Each caller, every call | An exchanged identity-provider token, never stored (Enterprise) |
Per-user identity can be a signed-in user, a virtual key, or an asserted session ID. Per-user credentials are stored per identity and can be revoked or re-authenticated individually from the MCP sessions view, without touching every other caller's access. Securing agent tool access with MCP server authentication walks through choosing between these types, and stopping secret exfiltration from an MCP server covers the credential-leak case specifically.
Agent Mode and Human-in-the-Loop Approval
By default, Bifrost does not execute any tool call automatically; every tool call requires an explicit execution request, giving a human or the calling application a checkpoint before anything runs. Agent Mode allows specific tools to be marked auto-executable via tools_to_auto_execute, which must be a subset of the tools already allowed for that client. Tools left out of the auto-execute list are still returned to the application for approval, so a team can automate low-risk tools while keeping destructive or sensitive actions gated behind a manual step. This setting applies only in Agent Mode, where Bifrost runs the model loop itself; the next section covers what changes when Bifrost runs purely as a gateway.
RBAC and Audit Logs for MCP Governance Itself
Governing what agents can do is only half the picture; who can change the governance configuration matters just as much. Role-based access control in Bifrost Enterprise restricts who can create, edit, or delete MCP client configurations and virtual keys, with system roles for Admin, Developer, and Viewer access plus custom roles for specialized teams.
Two different logs cover the two halves. Audit logs record administrative activity: who changed what, when, and which resource was affected, with entries that can be HMAC-signed and archived to object storage. Tool calls themselves belong to request logging, not to the audit trail. Reading them together is what gives security and compliance teams a record of both agent behavior and configuration changes.
Where Each Control Is Enforced: Gateway Mode Versus Agent Mode
Governance controls do not all live in the same place, and which ones apply depends on how Bifrost is deployed. Tool filtering and authentication are enforced by Bifrost in both modes. Approval gating is not: it belongs to whichever component runs the agent loop, and that is Bifrost in Agent Mode but the host application in gateway mode.
| Control | Gateway mode | Agent Mode |
|---|---|---|
| Tool filtering (client, request, virtual key) | Enforced by Bifrost | Enforced by Bifrost |
| Authentication to the upstream server | Enforced by Bifrost | Enforced by Bifrost |
Auto-execute vs approval (tools_to_auto_execute) |
Ignored; the host application owns approval | Enforced by Bifrost between model turns |
| Audit of configuration changes | Enforced by Bifrost | Enforced by Bifrost |
In gateway mode, a host such as Claude Desktop or Cursor connects to Bifrost over the MCP protocol and runs its own agent loop, so it decides whether each tool call needs confirmation and surfaces the approval interface. Setting tools_to_auto_execute there is not an error; it simply has no effect. Teams that need approval enforced centrally rather than per host should plan for Agent Mode, and teams using gateway mode should treat host-side confirmation as part of their governance design rather than assume the gateway supplies it.
What does not change between the two is the allow-list. A virtual key returns only the tools it permits on discovery, the same allow-list is checked on execution, and a key that is inactive or expired is refused outright.
Common Questions About MCP Server Governance
Does MCP server governance require a separate security product?
Not necessarily. Bifrost as the MCP gateway enforces tool filtering, authentication, and audit logging at the gateway layer, so the same platform that connects agents to MCP servers also governs what they can do through those servers.
What is the difference between tool filtering and authentication?
Tool filtering controls which tools an agent can see and call at all. Authentication controls whose credential is used when a tool call reaches the upstream MCP server. Both are required; a well-authenticated agent can still be over-privileged if tool filtering is not configured.
Should MCP servers use shared credentials or per-user credentials?
Per-user credentials, via per-user OAuth or per-user headers, scope access and revocation to an individual caller. Shared, server-level credentials are appropriate only when every caller is meant to act under the same identity, such as a single company-wide integration.
Does human approval slow down every tool call?
No. Auto-execution allows specific, lower-risk tools to be marked auto-executable while leaving higher-risk tools gated behind an explicit approval step, so approval is applied selectively rather than to every call.
Does Bifrost store per-user credentials for MCP servers?
It depends on the auth type, and the distinction matters for compliance. Per-user headers and per-user OAuth store a credential against each caller's identity and reuse it on later calls. Token exchange stores nothing: each call carries the caller's identity-provider token, which Bifrost exchanges on a cache miss, so no per-user secret is persisted.
How quickly does revoking a user's MCP access take effect?
That varies by auth type. Per-user credentials are revoked individually from the MCP sessions view and stop working immediately, without disturbing other callers. With token exchange there is nothing to revoke in Bifrost, so offboarding at the identity provider is what removes access, and it takes effect within the cached token lifetime rather than instantly.
Getting Started with Bifrost as an MCP Gateway
MCP server governance is not a one-time setup step; it is an ongoing combination of tool filtering, authentication, human approval, and audit logging that has to hold as new servers and agents get added. Bifrost enforces tool filtering, authentication, and audit logging at the gateway layer, with approval gating enforced centrally in Agent Mode and delegated to the host in gateway mode. The MCP Gateway resource hub covers configuration patterns for teams standardizing MCP access across multiple agents and teams. Teams whose agents also run on employee machines should read how governance extends from the gateway to the endpoint. To see MCP governance configured against a real set of servers and virtual keys, book a demo with the Bifrost team.
