Govern dangerous tool calls

What you will build

A policy test matrix for a synthetic MCP server. The live Docker governance version requires the separately paid organization feature; without it, complete the same reasoning with a local mock authorizer.

Read the mechanism

A registration rule answers whether a server may be stored. A use-time rule answers whether a request may proceed. Existing registrations are not automatically evicted by a new admission restriction. Revocation therefore needs a plan for both existing connections and subsequent use.

Docker’s governed gateway uses Cedar policies. Forbid wins over permit. Tool annotations are advisory inputs; a missing readOnly annotation is treated as false in the documented policy model. A server’s claim that a tool is safe is not a substitute for knowing its effect.

An approval-gated request requires a client capable of presenting that approval interaction. If the client cannot do so, the request is denied. Do not invent an out-of-band approval that the gateway does not implement.

Worked lab · harmless simulated write

Define a mock server with two operations:

{
  "tools": [
    {"name": "read_fixture", "effect": "returns a synthetic record"},
    {"name": "simulate_write", "effect": "increments an in-memory counter"}
  ]
}

The following is a policy design table, not deployable Cedar syntax:

For an entitled organization, translate these intentions using Docker’s current policy editor and reference. Validate the policy there before rollout. Keep example identities synthetic until an administrator selects the real scope.

Test registration, loading, tool listing and invocation independently. A denied tool may remain discoverable; visibility alone is not evidence of execution permission. Retain request identity, policy revision, decision and the counter’s before/after value.

Expected observations

The mock write counter remains unchanged after a denied request. A permission decision with no observable side-effect check is incomplete evidence. If the read tool secretly modifies state, your capability classification was wrong even if policy behaved exactly as configured.

Blocking the gateway route does not inherently block an agent’s separately configured remote MCP client. Network policy and agent configuration must account for that alternate route.

Troubleshooting

If no approval UI appears, check client support rather than retrying until a call slips through. If a policy edit seems ineffective, check propagation, scope and whether the operation uses the governed gateway. If a server was already registered, distinguish admission-time behavior from use-time behavior.

Interview practice

Completion check

Demonstrate a denied simulated write with an unchanged counter, and state the licensing, client and gateway-path assumptions behind the result.

Sources and version notes

Checked 6 October 2026; current baseline: sbx v0.46.0. MCP access policies · MCP policy reference