Blast Radius Drill

Blast Radius Drill Skill

Before an agent runs unattended, one question decides whether that's brave or reckless: if this agent were fully hijacked right now — every permission turned against you — what is the total damage? Most people never ask it, and find the answer during the incident. The drill asks it on purpose: walk the worst case through every capability, then build the containment that bounds it — caps that halt runaway loops, a kill-switch that stops it fast, reversibility so a bad run is undoable, and isolation so the damage can't spread. The goal isn't zero risk; it's bounded, recoverable risk, known in advance.

What This Skill Produces

• The worst-case walk-through — per capability, the maximum damage a fully-hijacked agent could do, made concrete
• The containment controls — the caps, halts, and isolation that bound each worst case
• The reversibility audit — which actions are undoable (and how) vs. irreversible (and thus gated or denied)
• The recovery runbook — the kill-switch, the "what did it do" audit trail, and the restore steps — decided while calm

Required Inputs

Ask for these if not provided:

• The agent's capabilities and environment — from the tool-permission-review inventory; the drill runs the worst case through each grant
• The autonomy scope — how long it runs unattended, how many actions between human checks (longer + more = larger blast radius to contain)
• What's reachable — the accounts, systems, data, and money the agent's permissions can touch; the worst case is bounded by reach
• The reversibility landscape — what's backed up, version-controlled, or restorable vs. what's gone-once-done (sent email, spent money, deleted-without-backup, public posts)

Framework: The Drill

1. Assume total compromise, then walk each capability: not "will it misbehave" but "it is hijacked — now what." File access → what could it read (secrets?) and destroy (which directories?). Send → who could it mail, how many? Shell → that's everything, so the drill for shell is "the whole machine and everything it can reach." Network → what data could leave. Money/actions → what could it spend or commit. The walk-through makes each abstract permission a concrete worst case: "it could email our entire customer list" is a sentence that changes configurations.
2. Bound the loops with caps: the runaway isn't always malicious — an agent stuck in a loop can send 400 emails, make 1,000 API calls, or delete a directory tree just as fast as a hijacked one. Every high-blast capability gets a cap (N actions/hour, M total, then halt-and-alert) so the worst case is bounded by the cap, not by how fast the agent runs. Uncapped autonomy is unbounded blast radius by definition.
3. Reversibility is the safety net — audit it honestly: sort every possible action into undoable (file changes under git, drafts not sent, sandboxed operations — a bad run is restore) and irreversible (sent email, spent money, public posts, deleted-without-backup, external API side effects). Irreversible actions either get denied for autonomous runs or gated to a human; reversible ones can flow, because the recovery cost is a restore. The drill's honesty: name what genuinely can't be undone and treat it accordingly.
4. Isolation contains the spread: the blast radius should stop at a boundary — an isolated environment (the browser/file sandbox), a dedicated account with limited reach, network egress limits. The difference between "the agent messed up its sandbox" and "the agent reached production" is isolation, decided before the run. A compromised agent contained to a scratch environment is a story; one with production reach is a postmortem.
5. The recovery runbook exists before it's needed: the kill-switch (the exact step to stop it now — revoke the token, kill the process, flip the toggle), the audit trail (so "what did it actually do" is answerable in minutes, not forensically), and the restore steps per reversible-damage type. Written while calm, because the version composed during a runaway at 2am is a panic, and a bounded-but-unrecovered incident is still an incident.