| name | blast-radius-drill |
| description | Run the worst-case drill before an agent goes autonomous — the 'if this agent were fully hijacked right now, what's the damage' walk-through, the containment controls (caps, kill-switch, reversibility, isolation), and the recovery plan. Use when asked what's the worst my agent could do, run a blast-radius assessment, prepare for an agent going rogue, or am I ready to let this run unattended. Produces the worst-case walk-through, the containment controls, the reversibility audit, and the incident-recovery runbook. |
| homepage | https://mohitagw15856.github.io/pm-claude-skills/skill/blast-radius-drill.html |
| metadata | {"openclaw":{"emoji":"🧠"}} |
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
- 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.
- 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.
- 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.
- 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.
- 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.
Output Format
Blast Radius Drill: [agent] — autonomy: [scope] · env: [reach]
The Worst Case (per capability, assuming full compromise)
| Capability | Maximum damage | Concrete example |
|---|
Containment Controls
[Caps per high-blast capability (rate + total + halt) · isolation boundary · egress limits]
Reversibility Audit
Undoable: [actions → how] · Irreversible: [actions → denied or human-gated for autonomous runs]
Recovery Runbook
[The kill-switch (exact step) · the audit trail (how to see what it did) · restore steps per damage type — written now]
The Verdict
[Ready for autonomy / gate these first / not yet — with the bounded-worst-case stated]
Quality Checks
Anti-Patterns
