A Tool Call Is Not Authorization

Technology Deep Dive

The security boundary is the state transition, not the button

The article's most useful design move is to split proposal from execution. A model may construct an action, but the backend stores that exact payload under an action ID before any side effect occurs. Confirmation then claims the stored action instead of accepting replacement parameters from the browser. This turns approval from a conversational gesture into a verifiable transition over server-owned state.

Action binding closes the gap between preview and execution

The proposed digest binds the operation, target, parameters, represented user, tool schema, and policy version. That matters because approval is meaningful only when it names the exact action that will execute. Actor matching and pending-state checks answer who may approve and whether the approval is still valid; the digest answers what was approved. Together they prevent a harmless preview from authorizing a modified payload.

Durable pending state is part of the authorization model

The single-replica limitation exposes a production requirement rather than a minor deployment detail. If proposal and confirmation reach different replicas, in-memory state cannot prove what the user saw or approved. Shared durable storage and atomic claiming are therefore security properties. The same action ID must also remain the idempotency key so a timeout or retry cannot turn one authorization into two external mutations.

Audit records must preserve authority, not merely behavior

Telemetry can explain latency, retrieval, failures, and tool activity, but it does not necessarily preserve who approved which payload and what result followed. The article's sharper implementation lesson is that authorization history needs its own retention, access, and integrity guarantees. The model may recommend an action; the system must independently establish the authority to perform it.