MCP Server Governance: Best Practices and Tools

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 most of the reported incidents trace back to over-privileged access and shared credentials rather than novel exploits. Bifrost, the open-source MCP gateway built in Go by Maxim AI, enforces MCP server governance through per-virtual-key tool filtering, five authentication modes, and audit logging, without requiring a separate MCP security product. This post covers the core best practices for MCP server governance 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 defines how tools are discovered and invoked, but it leaves enforcement of authentication, authorization, and logging to the platform running the connection, per the Cloud Security Alliance's analysis of the protocol's security model. That gap is exactly where MCP server governance controls need to sit.

Why MCP Server Governance Matters

Unmanaged MCP deployments create a specific set of risks that traditional application security controls do not fully address:

• 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.

Best Practices for MCP Server Governance

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. Audit records 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

Bifrost 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, 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, and 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. 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.

Authentication Options for MCP Servers

Bifrost supports five MCP authentication types: none, headers, OAuth 2.0, per-user headers, and per-user OAuth. Server-level auth types (headers, OAuth) use a single admin-configured credential shared across callers, while per-user types tie a credential to the caller's identity, whether that identity is a signed-in user, a virtual key, or a 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.

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 or virtual key. 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.

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. Combined with audit logs covering governance changes and tool execution, this gives security and compliance teams a queryable record of both agent behavior and configuration changes over time.

Common Questions About MCP Server Governance

Does MCP server governance require a separate security product?

Not necessarily. Bifrost 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. Agent Mode 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.

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 all four at the gateway layer, and the MCP Gateway resource hub covers configuration patterns for teams standardizing MCP access across multiple agents and teams. To see MCP governance configured against a real set of servers and virtual keys, book a demo with the Bifrost team.