The Blast Radius of an Agent

Every agentic deployment has a blast radius. It is the set of things the agent can touch, change, delete, or exfiltrate if its next action is wrong. Teams that do not calculate this number before going live will learn it after an incident.

The blast radius is not set by the agent's training. It is not set by the quality of the model. It is set almost entirely by the authority the deploying team chose to grant — the credentials, the scopes, the tools, the API surfaces it can call.

An agent given read-only access to a narrow dataset has a blast radius measured in information disclosure. An agent given write access to production infrastructure has a blast radius measured in outages. An agent with both has a blast radius measured in incidents that take days to unwind.

The one-question audit

Before any agentic deployment, ask a single question: if this agent's next action is the worst action it could take given its current authority, what happens?

If the honest answer is "we would recover in fifteen minutes and no customer would notice," the deployment is well-scoped.

If the honest answer is "we would have a multi-hour outage and regulatory notification requirements," the deployment is over-scoped, and the correct response is to reduce authority before proceeding.

If the honest answer is "we do not know," that is the real finding. You cannot reason about risk in a system whose authority you cannot enumerate.

Why this is hard to do in practice

The reason this question does not get asked often enough is that modern agentic frameworks make it easy to grant broad authority and hard to scope it tightly. A tool registration is usually a function signature, not a capability boundary. A credential issued to an agent is usually a long-lived API key, not a per-session scoped token. The infrastructure makes the overbroad choice the default choice.

Reducing blast radius is therefore not just a policy exercise. It is an infrastructure exercise. You need per-session credentials. You need tool interfaces that enforce scope at the API boundary rather than relying on the agent to stay inside its lane. You need logging at the authority layer, not just at the application layer, so that when an incident happens you can tell exactly which boundaries the agent crossed.

Most teams do not have this infrastructure. They have an agent that runs with a service account, and the service account has whatever permissions it was easiest to grant.

The design principle

The principle we build against is that an agent's authority should be the smallest set of capabilities that permit the task, and should be granted at the moment the task begins and revoked at the moment it ends. A session is scoped to a ticket. The credentials are scoped to the session. The tools are scoped to the credentials. An incident at any layer is contained by the layers above it.

This is more work than granting a service account and letting the agent loop. It is the work that separates an agentic deployment from a production incident waiting to trigger.

The blast radius of your next agent deployment is a number. Calculate it before you deploy. Do not wait for the incident to calculate it for you.