Bifrost 开源 AI 网关推出企业级 MCP Gateway，治理 MCP 工具访问

Model access controls what an AI system can know and generate. Tool access controls what it can do.

The previous posts in The AI Control Plane have moved progressively closer to the point where policy becomes action. Governance established who gets to decide. Virtual keys turned those decisions into runtime policy. RBAC and access profiles constrained who could change that policy. User provisioning made those permissions follow people as they joined, moved, and left.

Bifrost is the open-source AI gateway through which this series has been examining those control-plane concerns, with its implementation available in the Bifrost GitHub repository.

MCP tool access changes the stakes. The Model Context Protocol defines tools as capabilities exposed by servers that clients can discover and invoke. A model allowed to answer a question can produce a bad answer. A model allowed to invoke a tool can change another system. It can create a ticket, query a customer database, update a record, trigger a deployment, send a message, or call whatever capability an MCP server exposes.

The question is no longer only which model may receive a request. It is which actions that model can reach, under whose authority, and what happens when a request crosses from inference into execution.

Why Is MCP Tool Access Different From Model Access?

Model governance controls destinations and consumption. Which providers are approved, which models a workload may use, how much it may spend, and what rate limits apply. Tool governance adds capability.

Consider a customer support agent with access to three tools: lookup_customer, issue_refund, and close_account. All three may live on the same MCP server, behind the same authentication, exposed through the same connection. They do not have the same consequences.

That is why the useful unit of governance is not the server. A server is a deployment boundary. A tool is an action boundary, and the two rarely line up.

Authentication does not close the gap either. Valid credentials for an MCP server prove a connection can be made; they say nothing about whether a given workload should reach every capability behind it. This is the same separation the virtual key post drew between holding a provider credential and being permitted to use a particular model, and it gets sharper when MCP authentication is per-user. A person may legitimately authenticate to an external service while the AI workload acting on their behalf should still receive a subset of what that service offers. The credential establishes identity at the external boundary. The control plane still has to govern capability at the tool boundary.

What Should MCP Authorization Policy Control?

The simplest policy is an allow list, and it does more than it appears to, because filtering constrains discovery as well as execution. A workload never needs to be shown capabilities it will not be permitted to invoke. Bifrost applies that filtering per request, per client, or per virtual key, which means tool access can attach to the same policy boundary that already governs provider access, model allow lists, budgets, and expiry.

Enterprise authorization needs more structure than a growing collection of individual tool grants. Access profiles provide a reusable policy layer for grouping permissions around a role or workload rather than configuring each identity independently. A support workload, for example, can inherit the provider, model, and MCP permissions appropriate to support without requiring those decisions to be recreated every time another user or key is provisioned.

Virtual MCP servers provide another boundary by controlling the capability surface presented to a workload. Rather than treating every tool exposed by every connected MCP server as one flat namespace, an organization can present a curated MCP surface appropriate to a particular application or class of users. Tool filtering can then narrow that surface further to the specific actions a workload is authorized to discover and invoke.

Together, those layers answer different authorization questions. An access profile establishes the policy associated with an identity or workload. A virtual MCP server establishes the MCP capability surface available to it. Tool-level policy determines which actions within that surface are actually reachable.

That distinction matters because enterprise policy gets nuanced quickly. A research agent may search documentation and retrieve customer information without modifying either. A support agent may open a case while refunds route through a separate path. An engineering agent may inspect deployment state while production mutation stays out of reach. Policy should track the consequence of the action rather than the convenience of the integration.

Because those permissions live in the control plane rather than in twenty repositories, changing the decision does not require twenty releases. It also means refusal happens in the right place. If a workload is not permitted to invoke issue_refund, the useful outcome is not that the refund service rejects the call later. It is that the refund service never sees it. The application receives a deterministic policy refusal instead of an unpredictable downstream error, and the external system is never asked to adjudicate an unauthorized attempt.

What Changes When an Agent Can Execute Tools Automatically?

There is a meaningful difference between a model suggesting a tool call and infrastructure executing one, and Bifrost's default preserves it. Tool calls returned by a model are suggestions, not actions:

1. POST /v1/chat/completions  
   → model returns tool call suggestions, not executed

2. Application reviews the proposed calls  
   → apply business rules, request human approval

3. POST /v1/mcp/tool/execute  
   → execute approved calls explicitly

4. POST /v1/chat/completions  
   → continue the conversation with tool results  

Step two is the pause. It is where an application can inspect a proposal, ask a human, apply additional logic, or refuse outright.

Agent mode removes it. Tools named in the tools_to_auto_execute configuration run without waiting for approval, which is useful precisely because it eliminates friction and consequential for the same reason.

So the authorization decision moves earlier. If no human will be present when the action is taken, the control plane has to establish beforehand which actions are acceptable. An allow list stops being a convenience for hiding irrelevant tools and becomes part of the safety boundary around autonomous execution. That does not mean every call needs an approval dialog. It means the absence of a human at execution time makes pre-established policy more important, not less.

How Should Enterprises Think About MCP Tool Blast Radius?

A workable way to classify tools is by what happens when the authorization turns out to be wrong.

The categories matter less than the exercise. Two tools on the same server can sit three rows apart, which is the concrete reason server-level grants are too coarse.

Why Do Individually Safe Tools Become Unsafe Together?

Here is the part that no allow list solves.

A workload permitted to read customer data and to send email has a different effective capability from one permitted to do either alone. An agent holding a database tool, a payment tool, and outbound messaging is not carrying three permissions. It is carrying a workflow, and nobody approved the workflow. Each grant was reviewed on its own and each was defensible on its own.

This is an uncomfortable property of agentic systems: capability emerges from combinations of individually reasonable permissions, and the emergent capability is a property of the set rather than of any member of it. Filtering evaluates tools one at a time, because that is what filtering is. Reviewing grants one at a time will not surface it either, for the same reason.

There is no product answer as no gateway-level enforcement exists today. What there is, for now, is a review practice: when adding a tool to an existing grant, ask what the new tool makes possible in combination with what is already there, rather than whether the new tool is acceptable by itself. That is a weaker control than enforcement, and it is worth naming as a gap rather than papering over it.

A second assumption runs underneath everything above: that the MCP server itself is trustworthy, and the only open question is which of its tools a given workload should reach. That assumption deserves its own scrutiny, because a compromised or careless server can return content engineered to be read as instruction rather than as data. I have written separately about classifying MCP servers by trust zone, which is the layer beneath the one this post governs.

Who Authorized This Tool, and What Happens When They Leave?

Filtering answers whether a call is permitted right now. It does not answer why.

"The developer added the tool to the agent" describes implementation, not authority. The permission may have arrived through a team role, an access profile default, a temporary exception, or a direct assignment created during an incident at two in the morning. Those paths have different lifecycle behavior, which is where the provisioning problem returns. A tool grant attached to an identity has to disappear when the authority behind it disappears. Deleting a user or key causes Bifrost to clean up the associated per-user credentials. Session-keyed credentials and upstream provider tokens, however, may have separate revocation lifecycles that administrators need to account for.

And a tool grant attached to a workload with no human identity needs an owner and a lifecycle of its own, because nothing will trigger one on its behalf.

MCP governance is not a list of allowed tool names. It is the connection between capability and authority.

Why MCP Governance Belongs in the AI Control Plane

This series has worked through increasingly specific forms of control: organizational governance, workload policy, administrative authority, identity lifecycle, and now capability. Tools are where those controls finally meet something able to change the world outside the AI stack.

Which is why tool governance cannot stop at authentication, server access, or whether a model supports function calling. Enterprises have to decide which capabilities are visible, which are executable, which demand stronger authority, and how all of that changes when the people and workloads behind them change. Bifrost brings those decisions into the same control plane as model access, routing, and budgets, and because it is open source, the MCP implementation can be inspected rather than taken on trust.

The principle outlives any implementation. Model access governs what AI may ask. Tool access governs what AI may do.

Five layers in, the remaining question is not which controls exist. It is what order to build them in, and what breaks when you get the order wrong.