MCP Gateway

MCP Tool Governance: Filtering, Allowlisting, and Access Control for the Enterprise

Bifrost provides three-level MCP tool filtering, virtual key allowlisting, and enterprise tool groups to give teams granular control over which AI agents can execute which tools.

The Model Context Protocol connects AI agents to external tools, databases, and APIs at runtime, but the same capability that makes MCP useful also makes it a governance challenge. An agent with unrestricted access to every connected MCP server can read files, write to databases, send emails, and execute system commands with no access boundary between a junior developer's coding assistant and an admin's production toolchain. Bifrost, the open-source AI gateway built in Go by Maxim AI, is the best overall choice for enterprise teams running mission-critical AI workloads that require best-in-class performance, scalability, and reliability. This post covers how Bifrost implements MCP tool governance through three stacking filter levels, virtual key allowlisting, and enterprise-grade tool groups that scope tool access to individual users, teams, and organizational units.

What Is MCP Tool Governance

MCP tool governance is the practice of controlling which MCP tools are discoverable, invocable, and executable by which users, agents, and applications within an organization. Without governance, every AI agent connected to an MCP gateway has access to every tool from every connected server. In an enterprise with dozens of MCP servers exposing hundreds of tools (filesystem access, database queries, code execution, email, CRM operations, payment processing), this creates an unacceptable blast radius.

Effective MCP tool governance requires four capabilities:

Tool filtering: Restrict which tools are available at the client, request, and identity levels
Allowlisting: Explicitly define which tools each consumer (user, team, application) is permitted to execute, blocking everything else by default
Audit logging: Record every tool invocation with the identity that authorized it, the tool that was called, and the result that was returned
Policy enforcement at execution time: Block unauthorized tool calls at the point of execution, not just at discovery

In Bifrost, MCP tool governance is implemented through a layered filtering system tied to virtual keys, with enterprise extensions for MCP tool groups and audit logs that provide compliance-grade traceability.

Why Unrestricted MCP Tool Access Fails at Scale

The NSA's AI Security Center published guidance in May 2025 specifically flagging MCP deployments as a source of enterprise security risk, citing dynamic tool invocation, implicit trust relationships, and insufficient privilege isolation as systemic concerns. The advisory noted that MCP deployment has outpaced the governance structures needed to secure it.

The risks are not theoretical. Between January and February 2026, researchers filed 30 CVEs against MCP infrastructure in 60 days, and the OWASP MCP Top 10 project established the first industry-standard framework for classifying MCP risks. The common thread across these incidents is a flat permission model: every agent has access to every tool, and no enforcement boundary exists between discovery and execution.

Three patterns drive this failure at enterprise scale:

Privilege inheritance: AI agents inherit the full tool set of the MCP gateway they connect to. A customer support bot that only needs a knowledge-base search tool also receives access to database write operations, filesystem tools, and internal APIs.
Shadow MCP servers: Development teams connect unvetted MCP servers to shared infrastructure without security team visibility, expanding the attack surface outside any governance boundary.
No execution-time enforcement: Many MCP integrations filter tools at discovery (controlling what the LLM sees in its tool list) but do not enforce access control at execution time, meaning a prompt injection attack can invoke tools the agent was never intended to use.

Bifrost addresses each of these patterns by enforcing tool access at the execution layer, not just at discovery. Virtual key MCP configurations act as an execution-time allowlist: tools not permitted by the virtual key are blocked at both inference (tool injection into the LLM context) and MCP tool execution (the actual API call).

Three Levels of MCP Tool Filtering in Bifrost

Bifrost implements MCP tool filtering at three levels. These levels stack: a tool must pass all applicable filters to be available for execution.

Level 1: Client Configuration

Each MCP client connection defines a tools_to_execute field that sets the baseline of available tools. This is the first filter a tool must pass.

["*"]: All tools from this client are available
[] or omitted: No tools available (deny-by-default)
["read_file", "list_directory"]: Only the specified tools are available

{
  "name": "filesystem",
  "connection_type": "stdio",
  "tools_to_execute": ["read_file", "list_directory"]
}

This level controls the global maximum: no downstream filter can grant access to a tool that the client configuration does not include.

Level 2: Request-Level Filtering

Tools can be further narrowed on a per-request basis using HTTP headers. Two filter headers are available:

x-bf-mcp-include-clients: Include tools only from the specified MCP clients
x-bf-mcp-include-tools: Include only the specified tools, using the clientName-toolName format

curl -X POST <http://localhost:8080/v1/chat/completions> \\
  -H "x-bf-mcp-include-tools: filesystem-read_file,web_search-search" \\
  -d '...'

Request-level filters narrow the client configuration but cannot expand it. An empty filter header blocks all tools for that request, acting as a deny-all switch.

Level 3: Virtual Key Filtering

Virtual keys define per-consumer MCP tool access. When a virtual key has MCP configurations, those configurations take precedence over request-level headers.

{
  "name": "support-team-key",
  "mcp_configs": [
    {
      "mcp_client_name": "knowledge_base",
      "tools_to_execute": ["search", "get_article"]
    },
    {
      "mcp_client_name": "ticketing",
      "tools_to_execute": ["*"]
    }
  ]
}

A virtual key with no MCP configurations blocks all MCP tools by default (deny-by-default). This means tool access is always explicit: a team, application, or user receives only the tools their virtual key grants, and nothing else.

The three levels combine as an intersection:

Client Config Tools ∩ Request Filters ∩ VK Filters = Available Tools

This stacking design ensures that no single layer can bypass the constraints set by another. A virtual key cannot grant access to a tool the client configuration excluded, and a request header cannot override a virtual key restriction.

MCP Tool Groups for Enterprise-Scale Access Control

At the virtual key level, tool filtering works well for individual applications and small teams. For organizations managing hundreds of users across multiple teams and business units, Bifrost Enterprise provides MCP tool groups: curated bundles of MCP tools that can be scoped to virtual keys, teams, customers, users, providers, or API keys.

MCP tool groups decouple tool policy from individual virtual key configuration. Instead of configuring MCP access on each virtual key individually, administrators define tool groups (for example, "read-only data access," "engineering tools," "customer-facing tools") and attach them to organizational entities. When a user authenticates through Bifrost's OIDC integration (Okta, Entra, Keycloak, or Google Workspace), their identity resolves to a set of tool groups that govern which tools their agent sessions can access.

This approach maps directly to enterprise access control patterns. The MCP gateway resource hub covers how production teams structure tool groups alongside Code Mode and virtual key governance:

Role-based tool access: Analysts receive read-only data tools; engineers receive build and deployment tools; administrators receive full tool access
Team-scoped policies: The finance team's agents can access invoicing and accounting tools but not engineering CI/CD tools
Customer isolation: In multi-tenant deployments, each customer's agents see only tools associated with their data and systems

For organizations that need to expose internal APIs as MCP tools, Bifrost's MCP with federated auth feature transforms existing enterprise APIs (imported via Postman collections, OpenAPI specs, or cURL commands) into MCP tools with per-user authentication. Combined with tool groups, this enables a pattern where internal APIs become governed MCP tools without writing custom integration code.

Integrating MCP Tool Governance with Compliance Infrastructure

MCP tool governance does not operate in isolation. In regulated industries, every tool invocation is a potential compliance event. Bifrost integrates tool governance with the broader enterprise compliance stack through three mechanisms.

Audit logs record every MCP tool execution with immutable trails covering the virtual key that authorized the call, the user identity (resolved via OIDC), the tool name and parameters, the execution result, and the timestamp. These logs support SOC 2, GDPR, HIPAA, and ISO 27001 compliance frameworks.

Guardrails add content-level safety controls to both LLM inference and MCP tool execution. Bifrost supports AWS Bedrock Guardrails, Azure Content Safety, Patronus AI, and other providers for real-time content moderation. Guardrails evaluate both the inputs sent to tools and the outputs returned, catching sensitive data exposure before it reaches the agent or the end user. Enterprise teams can also configure secrets detection to intercept API keys, credentials, and tokens in prompts or tool responses.

Data access control provides row-level and field-level visibility restrictions within the Bifrost dashboard and APIs, ensuring that operators can only see the logs, metrics, and configurations relevant to their scope.

Together, these capabilities create a governance surface that extends from tool discovery through execution to post-execution audit. For teams evaluating MCP gateway solutions, the MCP Gateway resource page covers virtual keys, tool groups, Code Mode benchmarks, and how production teams govern tool access while reducing context cost at scale. The governance resource hub provides additional context on virtual keys, budgets, and access control policies.

Common MCP Tool Governance Patterns

Bifrost's filtering system supports several access control patterns that map to real-world enterprise requirements:

Read-only access: A virtual key configured with tools_to_execute: ["read_file", "list_directory", "get_file_info"] ensures agents can browse but not modify the filesystem
Environment separation: Development virtual keys grant access to all tools across all MCP clients; production virtual keys restrict access to a curated subset verified for safety
Per-user tool scoping: Each user role (viewer, editor, admin) receives a distinct virtual key with progressively broader tool access, from search-only to full CRUD operations
Budget-triggered tool restriction: Combined with routing rules, tool access can be dynamically restricted when budget utilization crosses a threshold, preventing cost overruns from runaway agent loops

These patterns are configurable through the Bifrost dashboard, REST API, or static configuration files, with no code changes required in connected applications. For a deeper look at how MCP governance, access control, and cost optimization work together in production, see the Bifrost MCP Gateway deep dive.

Getting Started with MCP Tool Governance

Implementing MCP tool governance in Bifrost starts with defining MCP client connections with explicit tools_to_execute lists (deny-by-default), creating virtual keys with MCP configurations that scope tool access to each consumer, and enabling audit logs for compliance traceability. Bifrost is a drop-in replacement for existing OpenAI and Anthropic SDKs, so adding MCP tool governance to an existing AI application requires changing only the base URL.

To see how Bifrost's MCP tool governance can secure your team's agentic AI deployments, book a demo with the Bifrost team.