Controlling MCP Tool Execution: A Gateway-Level Approach with Bifrost

Tool governance controls which tools models can invoke and who has permission to use them. Bifrost enforces filtering, approval, and audit controls.

The Model Context Protocol gives language models the ability to discover and automatically invoke tools based on the conversation context. But Bifrost, the open-source MCP gateway written in Go by Maxim AI, takes a more conservative stance. It refuses to execute tool calls automatically. Instead, your application must explicitly authorize each call before it reaches the underlying system. This architectural choice becomes the bedrock for governing MCP tool execution safely in production environments. This article explores how Bifrost enables teams to control which tools are available, who can use them, and how every action is tracked.

Understanding MCP Tool Execution Governance

MCP tool execution governance encompasses the controls that determine whether a tool call will be allowed to run, which identity the call executes under, and what happens to that action in the logs. The system answers four core questions: which tools does the model get to see, are the requested calls permitted, what credentials authorize the execution, and how is the call recorded.

Bifrost achieves this by keeping tool discovery separate from tool execution. When a model generates tool calls in its response, rather than immediately invoking them, Bifrost passes those calls back to your application. Your code has the opportunity to validate, reject, or approve each individual call before invoking the execution API. The design is intentional: propose, evaluate, execute only approved calls. Only after your system okays an action does the call travel to the MCP server.

This design matches what the protocol itself recommends. MCP's specification explicitly recommends that human operators always have the power to deny tool execution for safety, trust, and security reasons. Bifrost ensures this denial checkpoint is a permanent, architectural component of the entire request flow rather than something bolted on by individual client implementations.

The Risks of Uncontrolled Tool Execution

Tool calls that run without oversight convert the model's output into a direct pipeline to your infrastructure. Several real-world failure scenarios emerge when controls are absent.

• Prompt injection at execution. Injected malicious instructions from within retrieved content or previous tool responses can cause models to call dangerous or data-exfiltrating tools. Automatic execution means the attack succeeds even when earlier layers of input validation fail to detect it.
• Unintended large-scale actions. Tools capable of deletion, mutation, or payment processing can execute based purely on the model's decision. Models struggle to comprehend scale correctly, so a request intended to affect ten records can become a request affecting thousands.
• Shared credentials and lost attribution. Without a controlled path for execution, tool calls typically run under shared accounts. This breaks the least-privilege principle and prevents you from knowing which specific user or consumer triggered which action.
• Rogue servers and automatic approval fatigue. Research by the Coalition for Secure AI highlights how unmonitored MCP servers become governance blind spots, and how users who automatically approve tool invocations weaken human-in-the-loop safeguards.

Putting tool governance controls at the gateway solves these problems in a single, central location instead of requiring each application, model, and developer to independently solve them. A single MCP gateway gives infrastructure teams one location to apply uniform policy across all connected servers.

Bifrost's Approach to Tool Execution Governance

Bifrost places controls between the model's request and the actual tool execution, stacking multiple safeguards at different points in the request path. The end result is that no tool runs until your rules permit it.

Explicit authorization gates every execution

Bifrost returns tool_calls without running them; your application decides what happens next. You look at the tool name and arguments, perform any necessary checks, and send calls to the execution API only after approval. Here's what a tool execution request looks like:

curl -X POST http://localhost:8080/v1/mcp/tool/execute \
  -H "Content-Type: application/json" \
  -d '{
    "id": "call_xyz789",
    "type": "function",
    "function": {
      "name": "filesystem_list_directory",
      "arguments": "{\"path\": \".\"}"
    }
  }'

MCP client names prefix tool names (so you get filesystem_list_directory instead of just list_directory), which ensures calls stay unambiguous when multiple servers are connected. Tool results come back with the appropriate role and a matching tool_call_id, making them directly appendable to chat history without manipulation.

Filtering limits what the model can request

Before approval happens, filtering acts as the first perimeter. Tool filtering determines which tools are even visible on a request, preventing high-risk tools from appearing in the model's available options to start with. If a client that shouldn't have access somehow requests a filtered tool, you get a rejection:

{
  "error": {
    "type": "tool_execution_error",
    "message": "Tool 'filesystem_delete_file' is not allowed for this request"
  }
}

The gateway enforces these restrictions directly, not through instruction-based prompting, so filtering holds its ground even when a model is tricked into requesting something outside its allowlist.

Per-identity scoping using virtual keys

The execution endpoint respects the same authentication scheme as chat endpoints, so virtual keys extend to tool execution the same way they do to inference calls. You can restrict tool access by virtual key, ensuring each consumer, team, or account sees only the tools appropriate for their role. When joined with rate limits and budget controls, every execution carries an authenticated identity with enforced constraints.

Immutable records of every execution

Governance lacks teeth without traceability. Regulated environments rely on audit logs for immutable records suitable for SOC 2, GDPR, HIPAA, and ISO 27001 compliance. You gain the ability to answer precisely which user ran which tool, what arguments went in, and precisely when it happened. MCP becomes a transparent, reviewable system rather than a black box.

Implementing Approval Workflows

Explicit execution maps cleanly onto human approval or policy-driven authorization. The workflow has four phases: generate tool calls, review them, approve and execute selected ones, incorporate results. In the Go SDK, your review logic sits between receiving the response and executing:

// Step 1: model proposes tool calls
response, _ := client.ChatCompletionRequest(ctx, request)

if response.Choices[0].Message.ToolCalls != nil {
    assistantMessage := response.Choices[0].Message
    history = append(history, assistantMessage)

    for _, toolCall := range *assistantMessage.ToolCalls {
        // Step 2: YOUR APPROVAL LOGIC
        // - validate arguments against a schema
        // - check the caller's permissions
        // - require human confirmation for destructive tools

        // Step 3: execute only if approved
        toolResult, err := client.ExecuteChatMCPTool(ctx, toolCall)
        if err != nil {
            continue
        }
        history = append(history, *toolResult)
    }
}

// Step 4: continue with approved results
finalResponse, _ := client.ChatCompletionRequest(ctx, finalRequest)

An effective strategy is to auto-execute read-only, low-risk tools while routing write operations and irreversible actions through confirmation. For scenarios where you want automation without manual review for each call, agent mode provides autonomous execution with tunable auto-approval rules; you can enable self-executing tools for a curated subset while keeping others behind an approval wall. See the detailed guide to MCP gateway access control and cost optimization for patterns suited to incremental adoption. See the detailed guide to MCP gateway access control and cost optimization for patterns suited to incremental adoption.

Scaling Governance Across Teams and Customers

Simple per-request filtering scales only so far. Orgs running multiple teams, departments, or external customers need composable, reusable policies. Bifrost offers building blocks designed for enterprise scale.

• Tool groups and virtual MCP servers. Tool groups bundle tools into curated collections that attach to virtual keys, teams, accounts, or regions. The gateway enforces these at execution time. Back-end tools sit behind this abstraction layer, so you can remap tool implementations without updating client configs.
• Role-based access control. RBAC separates who can modify governance policy from who uses the tools; admins configure providers and policies, while teams or customers consume them.
• Bring your own APIs into MCP. MCP with federated auth converts existing internal APIs into governed MCP tools without additional middleware code. Internal services immediately inherit the same controls as any other MCP server.

All of this runs in your own infrastructure. For teams needing on-premise, air-gapped, or VPC-isolated deployments, Bifrost Enterprise keeps the entire execution path and tool data inside your boundary. Organizations moving to scale can dive into the governance capabilities resource for the full picture, or the MCP gateway hub for tool management and policy patterns.

Starting with Governed Tool Execution

Bifrost gives you governance by default: tool calls never run without explicit approval. From that foundation, layer on filtering to limit tool visibility per client, virtual keys to tie execution to verified identity, custom approval logic for high-risk actions, and audit logs to maintain records. The gateway applies all these policies consistently across every connected model, client, and server.

Explore how Bifrost governs MCP tool execution across your AI stack by booking time with the Bifrost team.