The Pre-Launch Blast Radius Inventory: The Document Your Agent Team Forgot to Write

The first hour of an agent incident is always the same. Someone notices the agent did something it shouldn't have — invoiced the wrong customer, deleted a calendar event for the CEO, posted a half-finished apology in a public Slack channel — and the response team starts asking questions nobody has written answers to. Which downstream system holds the audit log? Which on-call rotation owns that system? Was the call reversible, and within what window? Who owns the credential the agent used, and does that credential also let it touch other systems we haven't checked yet? The team that wrote the agent rarely owns those answers, because the answers live in the systems the agent calls, and nobody at launch wrote them down in one place.

That document is the blast radius inventory, and it is the artifact most agent teams discover the absence of during their first incident. It is not a security checklist, not a tool schema, not a runbook. It is an enumerated list of every external system the agent can touch and every fact you need on the worst day of that system's life. Teams that ship agents without one are betting that incident-response context can be reconstructed faster than the blast spreads, and that bet keeps losing as agents get more tools and the tools get more powerful.

What goes in the inventory

A blast radius inventory has one row per tool, and each row is filled in as if the tool's worst day has already happened. The columns aren't optional and they aren't aspirational — every cell needs to be real before the tool is registered, because every empty cell becomes a question someone asks at 2 a.m.

A workable starting schema:

• Tool name and binding: the registered tool name, the agent or agents that can call it, and the function or schema the planner sees.
• Downstream system: the actual external system the call hits. Not "the CRM API" — salesforce-prod.us-east. Specificity matters because that's the thing that gets paged.
• Credential: the service account, OAuth scope, API key alias, or signed identity the call presents. If the credential is shared with non-agent callers, that gets noted explicitly.
• Worst-case effect: what the call does if a prompt injection successfully hijacks it. Not the happy path — the assume-compromise path. "Sends an email from the CEO's address to a list" beats "sends notifications."
• Reversibility class: reversible (under 60 seconds), reversible-with-effort (manual rollback within an hour), or irreversible (money moved, message delivered, key rotated, file overwritten in a system without versioning).
• Audit trail location: where the action's record lives — the SaaS app's audit log, an internal data warehouse table, a CloudTrail bucket, the agent's own structured event stream — and the retention window.
• Downstream on-call: which team gets paged when this tool's downstream system breaks, regardless of whether the agent caused the break.
• Rate-limit budget: the share of the downstream's quota the agent is allowed to consume, separated from the share other internal callers consume.
• Composition effect: the worst case when the planner combines this tool with another tool in the catalog. This is the column most teams skip and most postmortems land on.

The composition column is the one that turns the inventory from a tool list into a blast-radius map. A read_email tool is low-risk on its own. A send_email tool is low-risk on its own. The two together with a fetch_url tool form Simon Willison's lethal trifecta — private data, untrusted instructions, and an exfiltration channel — and the agent's planner can compose those three into an effect none of their owners signed up for. The composition column forces the team to write down which combinations have been considered, and which haven't.

Filling in the worst-case column honestly

The temptation is to write what the call does on the happy path. "Updates a lead's status." "Posts a summary to a project channel." That entry is useless, because the only time anyone reads the inventory is when the call did something nobody wanted.

The correct frame is to assume a prompt injection has succeeded and the planner is now hostile. Then ask: with the credential this tool holds, with the scope it's been granted, with the rate limit it's been given, what is the worst thing it can do before something else stops it? The answer is rarely the thing the tool was designed for. A update_lead_status tool with broad write scope can mass-mutate every lead in the CRM if the prompt is constructed to iterate. A post_to_channel tool that doesn't pin to a specific channel ID can post to leadership channels. A fetch_calendar tool that returns full event bodies can exfiltrate meeting notes that contain unannounced acquisition targets.

The 2025-Q4 data is unambiguous on this point: documented prompt-injection attempts against enterprise AI systems rose 340% year-over-year, with successful attacks rising 190%. The CVE-2025-53773 disclosure showed prompt injection in a pull request description achieving remote code execution through a coding agent at CVSS 9.6. The teams that survived these incidents had pre-written answers to the worst-case question. The teams that didn't had to invent the answers while the incident was live.

Loading…