←All Posts
mcpsecurityprotocol-controlsnetwork-policyai-agents

MCP Tool Access Control: Restrict Which Tools AI Agents Can Call

Sandbox0 Team·

MCP makes tools easy to connect.

That is also the problem.

Once an agent can reach an MCP server, it often inherits every tool exposed by that server: read tools, write tools, admin tools, deployment tools, database tools, browser tools, and shell-like tools. In a prototype, that feels productive. In production, it turns tool access into a security boundary.

The question teams are starting to ask is not just "Can my agent use MCP?"

It is:

How do I control which MCP tools an agent is allowed to call?

That is the job of MCP tool access control. Prompt instructions and client-side allowlists help with usability, but they are not an execution boundary. A production agent runtime needs a place where a tool call can be denied before it reaches the upstream MCP server.

Sandbox0 Protocol Controls add that enforcement point at the sandbox network boundary.

The Real MCP Permission Problem#

MCP standardizes how agents discover and call tools. That makes it much easier to connect agents to GitHub, Slack, databases, internal APIs, browser automation, file systems, ticketing systems, and custom business workflows.

But MCP does not automatically make those tools least-privilege.

A common production shape looks like this:

  • a shared MCP server exposes many tools
  • several agents connect to that server
  • each agent should only use a subset of the tools
  • some tools are safe for read-only work
  • some tools mutate external systems
  • some tools should require approval
  • some tools should never be reachable from a given sandbox

The dangerous case is not always a malicious model. It can be a normal agent making a wrong decision with too much capability.

An analyst agent may need query_dashboard but not export_customer_table. A docs agent may need read_file but not write_file. A coding agent may need create_pr but not deploy_production. A support triage agent may need to inspect logs but not change account state.

Tool-level permissions matter because each MCP tool is an action surface.

Why Prompt Rules Are Not Enough#

Many teams start with prompt-level rules:

You may only use read-only tools.

That is useful guidance, but it is not enforcement.

The model can misunderstand the instruction. A future prompt can conflict with it. A tool result can contain malicious instructions. A different agent client can ignore the local permission model. A retry path can behave differently from the happy path.

Client-side allowlists are better, but they still live inside the agent control plane. If the agent process, client config, or local runtime is compromised or misconfigured, the upstream MCP server may still receive the request.

For production MCP security, there should be an execution checkpoint outside the agent's reasoning loop.

That checkpoint should answer a narrow question:

For this sandbox, destination, MCP endpoint, and tool name, should this tool call be forwarded?

Where Sandbox0 Enforces MCP Tool Access#

Sandbox0 already has sandbox network policy for outbound traffic. That policy controls where a sandbox can connect by domain, CIDR, port, and application protocol.

Protocol Controls add one more layer:

  • trafficRules decide whether the sandbox can reach the destination
  • protocolRules inspect supported protocol operations on allowed traffic
  • credentialRules resolve and inject credentials for matching destinations

For MCP, Sandbox0 inspects HTTP-carried JSON-RPC requests. When a request calls tools/call, netd reads params.name and evaluates the configured MCP tool policy.

This runs in the data plane. Regional control plane services store and distribute policy, but they are not in the per-request path.

That distinction matters: MCP tool access control should not depend on the model, the app prompt, or the MCP server voluntarily enforcing every client-specific policy.

Example: Allow Read, Deny Write and Shell#

Here is a sandbox network policy that allows a docs MCP server, but only permits the read_file tool. It explicitly denies write_file and run_command.

yaml
mode: block-all
egress:
    trafficRules:
        - name: allow-docs-mcp
          action: allow
          domains:
              - mcp.example.com
          ports:
              - port: 443
                protocol: tcp
    protocolRules:
        - name: docs-mcp-tools
          protocol: mcp
          domains:
              - mcp.example.com
          ports:
              - port: 443
                protocol: tcp
          tlsMode: terminate-reoriginate
          httpMatch:
              methods:
                  - POST
              paths:
                  - /mcp
          mcp:
              tools:
                  allowed:
                      - read_file
                  denied:
                      - write_file
                      - run_command

The evaluation rule is simple:

  • denied is evaluated first
  • if allowed is empty, tools are allowed unless denied
  • if allowed is non-empty, only listed tools are allowed

When a tool call is denied, Sandbox0 does not forward the request upstream. The sandbox process receives a JSON-RPC policy error, and netd records the protocol decision in its audit event stream.

If the MCP request body cannot be safely read and inspected, the rule fails closed with a JSON-RPC policy error.

That is the important property: a policy failure does not silently become an upstream tool call.

What This Solves#

Protocol Controls are designed for a specific production problem: a sandbox must reach an MCP endpoint, but it should not be allowed to call every tool available there.

That gives teams a practical way to enforce least privilege for agent execution:

Per-sandbox tool boundaries. Different sandboxes can have different MCP tool policies even when they connect to the same server.

Runtime enforcement. The allow or deny decision happens outside the agent process, after the agent has produced a real MCP request and before the upstream server sees it.

Network and tool policy in one place. The destination allowlist and the tool allowlist live in the same sandbox network policy model.

Fail-closed behavior. If Sandbox0 cannot inspect the request safely, the policy denies the operation instead of forwarding an ambiguous request.

Auditability. Denied tool calls are visible as protocol decisions, not buried in an agent transcript.

For many agent workloads, that is the missing layer between "the agent can connect to the MCP server" and "the agent can do anything that server exposes."

What This Does Not Replace#

Protocol Controls are not a complete MCP gateway.

They do not replace upstream authentication. Your MCP server should still authenticate clients and validate tokens. The official MCP authorization guidance still matters.

They do not replace business authorization inside the tool. A database tool should still check whether a user can access a table. A ticketing tool should still check whether a user can modify a ticket. Sandbox0 can block a tool call by name, but the upstream system still owns domain-specific authorization.

They do not hide unauthorized tools from discovery. Some MCP gateways filter tools/list so a model never sees tools it cannot use. Sandbox0's current Protocol Controls focus on invocation enforcement for tools/call. In practice, many teams should use both patterns:

  • discovery filtering to reduce model confusion and context bloat
  • invocation enforcement to make sure forbidden calls do not execute

They also do not replace human approval for high-impact actions. A tool can be allowed by policy and still require a product-level confirmation step before it mutates a real system.

The clean mental model is:

MCP gateway policy shapes what the agent sees. Sandbox0 Protocol Controls enforce what the sandbox can execute.

Why Tool Access Belongs Near Network Policy#

MCP tool calls are not just application events. They often cause networked side effects:

  • query a database
  • read a private repository
  • create a pull request
  • call a SaaS API
  • upload or download files
  • start a deployment
  • trigger a payment or paid API call

That is why tool policy and egress policy belong close together.

If a sandbox can only reach mcp.example.com, and only call read_file there, the execution boundary is much easier to reason about than a prompt rule that says "do not call write tools."

The same boundary also composes with Sandbox0 credential projection. A sandbox can be allowed to use a credential for a specific destination without holding the credential inside the agent process. The tool call, network destination, and credential injection all become part of one runtime policy surface.

That is the kind of boundary production agents need. The agent can do useful work, but the runtime still decides which external actions are possible.

A Practical Policy Pattern#

For production MCP tool access control, start from a narrow default:

  1. Use mode: block-all for the sandbox network policy.
  2. Add explicit trafficRules for the MCP hosts the sandbox needs.
  3. Add protocolRules for MCP endpoints that expose mixed-risk tools.
  4. Prefer allowed lists for task-specific sandboxes.
  5. Add denied entries for tools that should never execute from that sandbox.
  6. Bind credentials only for the destinations that need them.
  7. Treat denied tool calls as audit events worth reviewing.

For example:

  • docs review sandbox: allow search_docs, read_file
  • coding sandbox: allow read_file, write_file, create_pr; deny deploy_production
  • analyst sandbox: allow query_metrics; deny export_raw_customer_data
  • support sandbox: allow get_ticket, summarize_logs; deny refund_payment, close_account

The exact tool names depend on your MCP server. The control pattern is the same.

Protocol Control, Not Prompt Control#

The broader lesson is simple:

Prompts are intent. Protocol policy is enforcement.

MCP is becoming a standard way for agents to reach real systems. That makes MCP tool permissions a runtime infrastructure problem, not just an agent design problem.

Sandbox0 Protocol Controls let you keep MCP useful without treating every connected tool as equally available to every sandbox. The agent can still use the protocol. The sandbox still gets a real network path. But tool execution is governed at the boundary where the request leaves the sandbox.

That is the right place to decide whether an agent is allowed to act.

Further Reading#