Scoping an Agent's Tools: Read, Write and Destructive

The practical version of blast radius is one question per tool: what is the worst outcome if this tool is called with the wrong arguments, at the wrong moment, on the wrong object? Three classes are enough to start, and each maps to a concrete reviewer action.

Two rules sharpen the classification.

First, classify by the tool's maximum scope, not the parameters it usually receives. A "search documents" tool that accepts a wildcard can return the entire document store. A "manage calendar" tool that happens to include delete rights is destructive even if the agent only ever reads from it (the permission surface audit).

Second, treat "sends" and "pays" as destructive even when nothing is deleted. Sending an email to a customer or charging a card cannot be fully undone by revoking a token afterwards; the token was valid and the action ran (Scalekit on approval gates). Reversibility, not deletion, decides whether a failure is a nuisance or an incident.

Keep the classification in the code that registers tools, not in a wiki, so the enforcement layer can read it:

TOOLS = {
    "search_tickets":  {"risk": "read",        "approval": "none"},
    "draft_reply":     {"risk": "write",       "approval": "none"},
    "update_crm":      {"risk": "write",       "approval": "prod_only"},
    "send_reply":      {"risk": "destructive", "approval": "always"},
    "delete_account":  {"risk": "destructive", "approval": "always"},
}

The third entry is where most judgment lives: a write tool that is gated only against production data. Write that conditional down instead of leaving it to the prompt.

An approval gate is not a confirmation dialog. It is an authorization decision at the moment of invocation: should this specific call execute, with these arguments, right now? OAuth scope answers a different question, namely whether the agent may call this category of operation at all, and that grant was made weeks ago (Scalekit).

Where the gate lives matters. If you gate inside the model's reasoning, by instructing the agent to ask before deleting, you have asked the same component that formed the plan to certify it. The evidence on reliability says that is too much to ask: a benchmark study of three open-source agent frameworks with two model backbones found roughly a 50% task completion rate, with failures clustered in planning errors, execution problems and incorrect response generation (Exploring Autonomous Agents). A component that gets the plan wrong about half the time on unfamiliar tasks should not decide whether the plan is safe.

Put the gate in the execution path. The pattern is a pause-resume interrupt: the agent proposes the call, the runtime suspends, a human approves or rejects, and execution resumes or aborts (Scalekit). Two engineering details matter more than they look. The approval prompt must show arguments, not just the tool name: "approve send_reply" tells a reviewer nothing, while "send the drafted reply to 40 customers on the enterprise tier" is reviewable. And credentials can expire during the pause, so hold them in a vault and let the agent reference an identity rather than a raw token.

Supervisory systems are converging on the same shape. A guardian agent runs a continuous loop: observe the context, interpret the intended action and its risk, decide against policy, then allow, block or escalate, and record the decision for audit (Sweet Security on guardian agents). The escalation trigger is exactly the threshold from your classification table: financial value, regulatory scope, ambiguity or irreversibility. Risky calls get judged at the point of action rather than filtered at the input.

There is a limit worth naming. Oversight researchers argue a pause button is meaningful only if the reviewer has knowledge, observation, control and intervention, and many setups supply the formal moment of intervention while leaving the conditions for a real one underdeveloped (Data & Society's oversight agenda). A reviewer who cannot tell why the agent changed strategy mid-run is not gating anything. Gate design and trace design are the same project.

Approvals feel cheap when one agent makes three destructive calls a day. They stop feeling cheap when the fleet grows. Estimate the load with four numbers you can measure before rollout.

1. Expected destructive calls per hour across the fleet, meaning agent count times calls per agent per hour times the destructive share.
2. The approval rate, the fraction of destructive calls that route to a human once conditional write gates are included.
3. Minutes per approval, including reading arguments, checking context and clicking through.
4. Reviewer minutes actually available per hour, remembering that the same person usually has other duties.

The formula is destructive calls per hour times approval rate times minutes per approval, compared against available reviewer time. Publisher-reported research puts managers at roughly 37% of their working time spent making decisions, with more than half of that wasted (McKinsey, cited by Prialto), which is a warning that decision capacity is scarce, not infinite.

A worked example: 60 destructive calls per hour at peak, a 40% approval rate, and 90 seconds per approval.

60 calls/hr x 0.40 = 24 approvals/hr
24 x 1.5 min       = 36 reviewer minutes/hr
Reviewer capacity   = 30 min/hr
Load ratio          = 36 / 30 = 1.2

A ratio above 1.0 means the queue grows without bound and reviewers start rubber-stamping to keep up. The fix is not more reviewers by default. Four levers exist, and the order matters.

Removing unneeded permission is cheapest, because it eliminates work instead of managing it. The permission audit framing is explicit: an agent built to summarize tickets does not need file-system write access, and the most effective blast-radius reduction is taking away tools rather than adding guardrails (the permission surface audit). Batch approval is second, and it fits the async tier: read-write operations on non-critical internal data can proceed with an audit trail good enough for a human to reverse within hours, without in-flight approval.

Recompute in both directions. Before you add a tool, compute the load it creates at expected volume. Before you relax a gate, recompute. A gate that gets rubber-stamped is worse than no gate, because it manufactures evidence of review that never happened.

A single gated call is a manageable unit. An agent loop that can retry, re-plan and chain calls is the amplifier. One framework for bounding this treats autonomy as a spectrum and insists useful autonomy is bounded by hard permissions, approvals, budgets, tool limits, guardrails and stopping rules, expanding only when measured reliability justifies the added risk (PrompTessor on autonomous agents). Chained tool calls are the primary expansion mechanism: each call looks reasonable alone, and the risk lives in the sequence across trust boundaries (Aurascape).

So scope has a second dimension beyond class: how far can a sequence travel? An agent with read access to five systems has five times the reach of one with a single system, even though no individual call is destructive. Constraints that keep reach proportionate:

• Cap workflow depth, so a plan cannot chain more tool calls than a reviewer can follow.
• Cap retries on destructive tools at zero. A failed destructive call escalates; it never loops.
• Cap spend and volume per task, so a runaway loop hits a budget wall before it hits a customer.
• Scope credentials per task with just-in-time grants revoked on completion, instead of standing tokens.

The failure taxonomy is instructive here: planning errors, not just execution errors, cause a large share of failures (Exploring Autonomous Agents). A well-formed plan can be wrong in a way that aims a destructive tool at the wrong object. Depth caps and per-task credentials bound how far a wrong plan gets before something stops it.

A tool scope is a specification, and it deserves the treatment any task brief gets. Guidance on specs for coding agents transfers directly: state the output and boundaries explicitly, describe what failure looks like, constrain inputs, and define the review condition up front, because vague briefs produce output the agent has to guess at (Addy Osmani on agent specs) and tasks without criteria push guesswork into review time (acceptance criteria for agent tasks).

For a tool scope, the spec has four parts:

• The tool list with class. Every tool, its read, write or destructive label, and its approval rule. This is the artifact a reviewer checks against.
• The worst case, written down. One sentence per destructive tool: "worst case is a customer-visible email to the full list." If you cannot write the sentence, you do not understand the tool.
• The review condition. Which class triggers a gate, and what the reviewer must see: arguments, target, volume and the agent's stated reason.
• The escalation rule. What happens on rejection or ambiguity: abort, return to the user, or re-plan with the tool removed.

The spec should record where the agent's authority ends, too. That is the part of oversight interface design quietly teaches: when confirmation is required and when the agent may continue shapes what people learn to notice (Data & Society). A scope that gates every call teaches reviewers to click through. A scope that gates only the irreversible ones teaches them to read.

Tie expansions to evidence. To move a write tool from gated to autonomous, apply the acceptance-criteria process directly: define the output, list the conditions that must hold, describe failure, constrain scope, and set the review condition (acceptance criteria). Then measure the rejection rate over a fixed number of approvals. If reviewers approve nearly everything and the reversible failures you tolerated were all recoverable, widening is justified. If the rejection rate is meaningful, the gate is earning its keep.

Starting from a prompt-only system, this order keeps the work tractable.

1. Inventory every tool the agent can call, including ones behind a generic code runner. Reach through a code-execution tool is reach.
2. Label each tool read, write or destructive, judged by worst case and reversibility.
3. Delete tools that are destructive and not clearly necessary before doing anything else.
4. Encode the approval rule per tool in the registration code, including conditional gates for production writes.
5. Estimate review load with the four numbers above, at expected and peak volume.
6. Add depth caps, retry caps and per-task credentials around the loop.
7. Log every call with arguments and the approval decision, so the trail proves what was authorized at the timestamp it ran.

Step 3 pays for itself immediately, and step 5 prevents the gate from becoming theater. If the estimate shows a fleet generating approvals faster than a person can read them, one natural next step is to give the agents that need broad authority their own workspace with its own model access and per-person keys, rather than granting everything to every agent (Quanta for Teams).