Limiting the Blast Radius of an Autonomous Agent

Picture this: you're the on-call SRE, it's 2 a.m., and your infrastructure agent — the one that automates routine deploys and cleanups — just deleted a production database. Not because it was hacked. Because a cleanup task matched more resources than anyone expected, and the agent had permission to act on all of them. The agent did exactly one wrong thing, and one wrong thing was enough to take down the company for six hours. That gap between "one mistake" and "six-hour outage" is the autonomous agent blast radius, and it's almost always a configuration choice you made months earlier without noticing.

Let's tear down a real infra-agent setup and rebuild it to contain the damage.

Before: The Weak Setup

Here's the configuration that produced the 2 a.m. call. It's clean, it's readable, and it's a loaded gun.

agent: infra-ops
credentials:
  service_account: infra-admin        # full read/write on everything
environment: production                # acts directly on prod
network: unrestricted                 # can reach any host
limits: {}                            # no spend or action ceiling

What this does: gives one agent an admin credential over all of production with no environment separation, no network limits, and no ceiling on how much it can do — so any single mistake has the run of the house.

Why It Fails

The autonomous agent blast radius here is the entire production estate, and it's the product of three factors that all point the wrong way. The credential is broad (admin, everything). The environment is shared (it acts on prod directly, with no staging buffer). And the reach is unlimited (it can touch any resource, call any host). Multiply those together and a single overscoped cleanup command becomes an unbounded delete.

The insight that changes how you configure agents: blast radius isn't one setting, it's a product. Damage = permissions × reversibility × reach. To shrink it you don't need one big fix; you need to pull down each factor, because they multiply. Cut permissions to a tenth, make actions reversible, and fence the reach, and a mistake that used to be catastrophic becomes a shrug. This is also why a single strong control is never enough on its own: a tight permission scope with open egress, or perfect egress with an admin credential, still leaves one factor large — and a product is only as small as you make all of its terms together.

⚠️ Common mistake: Giving an agent a broad service account "for now" because scoping one is tedious. That account is the difference between an agent that can annoy you and an agent that can end you. The convenience is measured in minutes; the blast radius is measured in outages.

After: A Smaller Autonomous Agent Blast Radius

Rebuild the config so every factor in that product is small.

agent: infra-ops
credentials:
  mode: per_task_scoped              # mint a fresh token per run
  scopes: ["compute:restart", "logs:read"]   # exactly what THIS task needs
  ttl_s: 300
environment: staging_first           # dry-run in staging, promote on pass
network:
  egress_allowlist: ["metrics.internal", "deploy.internal"]
limits:
  max_actions: 20                    # ceiling per run
  destructive_requires: approval     # deletes block for a human
  spend_cap_usd: 10
guardrails:
  protected_resources: ["prod-db-*", "prod-vpc-*"]   # off-limits, always

What this does: replaces the admin account with a task-scoped credential, forces a staging dry-run before production, fences network reach, caps actions and spend, and puts protected resources permanently off-limits — so no single run can reach the database that took the company down.

Breaking Down Each Element

Per-task scoped credentials. The single biggest lever. Instead of a standing admin account the agent carries everywhere, mint a short-lived token scoped to exactly the operations one task needs. A restart task gets compute:restart and nothing else — it cannot delete a database because it was never handed the ability to. Static credential rotation actually works against you here; a token that rotates mid-migration kills the job, whereas per-task tokens sidestep the problem by expiring on completion. The mental shift is from "who is this agent and what is it allowed to do" to "what does this specific task need for the next five minutes" — a much smaller, much safer question to answer, and one you can answer automatically from the task definition itself.

Staging-first execution. Reversibility as a workflow. The agent runs its plan against staging first; only a passing dry-run promotes to production. This converts a whole class of irreversible prod mistakes into caught-in-staging non-events. The overscoped cleanup that deleted the database would have deleted a staging database first, produced an obviously-wrong result — "this task wants to remove 4,000 resources?" — and never been promoted. Staging-first is the cheapest insurance in this whole config, because it catches the mistakes that come from the agent misunderstanding the task rather than from anything malicious, and those are the majority.

Egress allowlist. Reach control. An agent that can only reach two internal hosts can't exfiltrate to a pastebin or pull a payload from an attacker's server, no matter what it's told to do. This is the leg of the blast radius most teams forget, because it doesn't show up until an incident: an agent with broad permissions but no network path out can leak nothing, while an agent with narrow permissions but open egress can still phone a stolen secret home. Treat outbound network as a permission in its own right, deny it by default, and open only the specific destinations a task needs.

Action and spend ceilings. The cap that turns a runaway into a rounding error. Twenty actions per run means a loop stops at twenty, not twenty thousand. A ten-dollar spend cap means the worst overnight surprise is ten dollars. The important thing about these ceilings is that they're enforced in the runtime, outside the agent's control — an agent stuck in a loop can't raise its own ceiling any more than it can talk its way past a budget it doesn't own. Set them deliberately low at first; a ceiling that never trips during normal operation but caps the abnormal is doing exactly its job, and you can always raise it once you've watched a week of real runs.

⚡ Pro tip: Rank every tool by reversibility and put your protected-resource list in front of the irreversible ones. "Can I undo this in under a minute?" is a better gating question than "is this sensitive?" — an irreversible action on a boring resource often outranks a reversible one on a sensitive resource.

⚡ Pro tip: Make protected resources a deny rule in the governance layer, not an instruction in the prompt. "Never touch prod-db" in a system prompt is a suggestion an injection can override; a deny rule in the credential's scope is physics.

How Do You Actually Measure Blast Radius?

"Shrink the blast radius" is only actionable if you can put a number on it, so make it concrete before and after every change. A workable definition: the maximum damage a single run could do if every decision in it were wrong. Write it as the worst-case triple — how many resources it can reach (reach), how much it can spend or destroy (permissions), and how much of that is unrecoverable (reversibility).

For the before config, that triple was roughly "all production resources, unlimited spend, mostly irreversible" — effectively unbounded. For the after config it's "the resources matching two scoped permissions, capped at $10 and 20 actions, with deletes gated and protected resources off-limits" — a number you can say out loud in a review. The point isn't precision to the dollar; it's that the after number is small enough that a fully wrong run is survivable, and you decided that on purpose.

⚡ Pro tip: Write the blast-radius triple into the pull request that ships a new agent capability. Reviewers who can see "worst case: 20 actions, $10, all reversible" approve confidently; reviewers shown only "adds delete tool" are guessing. Making the number visible is how blast radius stops being an afterthought.

For a data-pipeline agent, blast radius is mostly about write scope and idempotency — grant read broadly, write narrowly, and make every write idempotent so a re-run can't double-apply. For a customer-facing agent, reach is the dominant factor: cap how many external messages it can send per window so a loop can't email your entire list. For a financial or payments agent, reversibility dominates everything — the config leans almost entirely on gating irreversible actions and keeping spend ceilings tight, because there's no staging equivalent for a wire that cleared. For a multi-agent system, watch the handoff — constraints defined on an orchestrator do not automatically propagate to subagents, so a tightly-scoped orchestrator can hand work to a subagent that inherited nothing. Re-assert scopes at every handoff.

⚡ Pro tip: Run a "blast radius review" whenever you add a tool: write down the single worst thing this tool lets the agent do, then confirm a gate, a scope, or a ceiling caps it. If you can't name the cap, you just widened the blast radius without deciding to.

Save and Reuse This

The specific scopes and ceilings change per agent, but the shape — per-task credentials, staging-first, egress allowlist, action and spend caps, a governance-layer deny list — is identical every time. That's what makes it worth templating rather than hand-writing under pressure at 2 a.m.

Keep your blast-radius configs and protected-resource lists versioned in a shared library like PromptABCD, so every new agent starts contained by default and the autonomous agent blast radius is a number you chose on purpose — not one you discover during an outage. The teams that sleep through the night aren't the ones with smarter agents; they're the ones whose agents physically can't reach far enough to cause the 2 a.m. call in the first place.