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 incid...
Scanned 9/3/2026
Install to Claude Code
npx -y skills add mohitagw15856/pm-claude-skills --skill blast-radius-drill --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Blast Radius Drill?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/mohitagw15856-blast-radius-drill-pm-claude-skills)More formats (shields.io, HTML) on the badges page.
---
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."
---
# 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](../tool-permission-review/SKILL.md) 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](../browser-agent-preflight/SKILL.md)/[file](../file-access-preflight/SKILL.md) 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.
## 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
- [ ] The worst case was walked assuming total compromise, made concrete per capability
- [ ] Every high-blast capability has a cap that halts
- [ ] Irreversible actions are denied or gated for autonomous runs
- [ ] An isolation boundary contains the spread
- [ ] The kill-switch, audit trail, and restore steps exist before go-live
## Anti-Patterns
- [ ] Do not skip the drill because "it'll probably be fine" — the worst case is found during the incident by those who don't run it
- [ ] Do not run uncapped autonomy — unbounded actions is unbounded blast radius, hijack or bug alike
- [ ] Do not let irreversible actions flow unattended — undoable can flow; sent/spent/deleted-forever gates or denies
- [ ] Do not skip isolation — the boundary is the difference between a bad sandbox and a production breach
- [ ] Do not improvise recovery — the kill-switch composed mid-runaway is a panic; write it while calm
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!