How it works
A tool definition shows what an agent may request. The tool-invocation blast radius describes what that request can actually affect. The radius is the intersection of the exposed operation, accepted arguments, runtime identity, reachable infrastructure, and downstream behavior. A narrow-looking function can therefore have a wide radius. deploy(service) may accept one service name while its credential can modify every workload in an account.
Trace the radius through four layers:
- Invocation: Which operations and arguments can the model select?
- Authority: Which permissions does the runtime identity carry when executing them?
- Reach: Which files, records, hosts, accounts, or external systems are accessible?
- Consequence: What indirect actions can follow, and can they be reversed or contained?
The last layer is easy to miss. Sending one message can trigger a human workflow. Updating one configuration value can restart many services. Calling an internal API can exercise permissions that are not visible in the agent-facing schema.
Blast radius is therefore a property of an execution path, not just a tool. It can change with credentials, tenant context, network placement, approval state, and argument validation even when the tool description stays unchanged.
Why it matters in an agent harness
Models can choose the wrong tool, supply an overbroad argument, repeat a valid operation, or act on untrusted context. The harness must assume these failures are possible and limit their consequences mechanically. Prompt instructions help shape behavior, but they do not narrow the authority exercised after a call is accepted.
A bounded blast radius improves failure containment. A mistaken delete request is less damaging when the credential covers one staging namespace instead of an entire account. An incorrect notification is easier to recover from when recipients must come from a run-specific allowlist. A repeated payment-like action is safer when the operation requires an idempotency key and enforces a per-run limit.
The radius also determines where stronger controls belong. Wide, irreversible, or externally visible operations may require an approval gate. Moderate-risk writes may need a preview, diff, checkpoint, or compensating action. Read operations still need boundaries because they can expose private data, expand context with hostile instructions, or move information across authorization domains.
Observability must follow the same path. A useful execution record connects the model's requested call to validated arguments, the effective identity, the authorization decision, the systems touched, and the result. Recording only the tool name hides the difference between reading one repository and enumerating every repository available to a shared credential.
Reducing blast radius does impose friction. More credentials, narrower endpoints, and additional policy checks create operational work. The defensible tradeoff is to spend that complexity where a single incorrect invocation could cross a control boundary or leave an outcome that cannot be reliably undone.
Tool-invocation blast radius vs tool surface
These concepts are related, but they answer different design questions.
| Concept | Primary question | Typical control |
|---|---|---|
| Tool surface | What operations can the agent see and request? | Tool registration, descriptions, schemas, routing |
| Tool-invocation blast radius | What can an accepted request ultimately affect? | Scoped credentials, validation, isolation, approvals, limits |
Removing an unnecessary tool reduces both exposure and reach. It does not follow that a small tool surface has a small blast radius. One generic shell, database, or administrative tool may expose a single interface while carrying broad authority. Conversely, several narrow tools can present a larger surface yet keep each call confined to a specific resource and action.
The design decision changes accordingly. Use surface reduction to simplify model choice and remove unused capabilities. Use blast-radius reduction to contain the consequences of capabilities that must remain available.
The Rifty take
We optimize for authority that is narrow at execution time, not merely tools that look narrow in a prompt. We accept some policy and credential-management overhead when an operation is destructive, externally visible, or difficult to reverse. If the harness cannot state what one accepted call may touch, the boundary is not yet engineered.
Implementation checks
- Resolve and record the effective runtime identity for every sensitive call.
- Compare the tool schema with the permissions actually held by its executor.
- Constrain resource identifiers to the current run, tenant, workspace, or task where possible.
- Validate arguments outside the model before exercising authority.
- Treat network reach and downstream automation as part of the radius.
- Require approval for wide, irreversible, or externally visible effects.
- Add idempotency, execution limits, and duplicate-call handling where repetition matters.
- Preserve per-call attribution from request through authorization and result.
- Test denied, malformed, repeated, and partially completed invocations.
- Define recovery before granting the operation: rollback, compensation, isolation, or an explicit statement that recovery is unavailable.
Frequently asked questions
How do you measure a tool-invocation blast radius?
Measure it by tracing one accepted call from arguments to final effects. Inventory the effective identity, permission scope, reachable resources, downstream triggers, external side effects, and recovery options. Use the maximum credible reach under current controls, not the narrow outcome expected during normal operation.
Can an approval gate eliminate tool-invocation risk?
No. An approval gate can prevent or delay selected calls, but it does not narrow the authority exercised after approval. The request shown to the reviewer may also omit transitive effects. Approval should sit above scoped credentials, argument validation, execution limits, and auditable results.
Why are shared credentials dangerous for agent tools?
Shared credentials make a narrowly assigned agent inherit authority intended for other users, jobs, or environments. They also weaken attribution because several execution paths appear under one identity. Prefer task-, tenant-, or environment-scoped credentials, with expiration and permissions matched to the operation being performed.
Do read-only tools have a meaningful blast radius?
Yes. Read-only access can expose confidential data, retrieve hostile instructions, cross tenant boundaries, or place sensitive material into logs and model context. Its radius should include what can be observed and where that information can flow, even when the underlying source cannot be modified.
Is sandboxing enough to contain a tool invocation?
Sandboxing contains only the resources covered by its boundary. A sandboxed process may still hold network credentials, call external services, write mounted storage, or trigger remote automation. Evaluate the sandbox together with identity, network policy, mounts, tool arguments, and downstream effects rather than treating it as a complete boundary.