Blast radius: an agent can reach everything you gave it

Most teams evaluate an agentic workflow by watching it succeed. Someone describes an automation, the assistant builds it, a test run does the right thing, and it ships. The demo is the review.

That review answers the wrong question. An agent is a program whose exact behaviour you cannot enumerate in advance. You aren't approving a fixed sequence of calls — you're approving a set of reachable states. The only durable way to reason about it is the way security people reason about a compromised service account: assume the worst plausible sequence of tool calls, and ask what it touches.

That's the blast radius. It isn't determined by the prompt. It's determined by the credentials.

Walk the tools, not the happy path

Take a workflow that triages inbound support tickets. The intended behaviour is narrow: read the ticket, look up the customer, post an internal summary. Now list what it was actually granted:

• A Zendesk connection with write scope
• A read-only Postgres connection to the customer database
• A Slack connection that can post to any channel
• An email connection for the shared support address

Intended behaviour uses maybe four operations. The grant allows hundreds. A model that misreads a ticket, or reads a ticket written specifically to mislead it, can close every ticket in the queue, post customer data into a public channel, or email a customer list. None of that requires a bug in your code. It's all inside the permissions you approved.

The exercise is mechanical and worth doing on paper before anything runs unattended:

1. List every connection the workflow holds.
2. For each, list the operations the credential actually permits — not the ones the workflow uses.
3. For each operation, ask: if this ran on the wrong record, or a thousand times, what is the damage and is it reversible?
4. Anything irreversible gets a gate, a scope reduction, or stays out.

Step three is where most workflows fail. Teams reason about correctness and skip reversibility. "Post a Slack message" and "delete a Jira issue" are both single tool calls; one is a minor embarrassment and one destroys work.

Reversibility is the axis that matters

A rough tiering that survives contact with reality:

Reversible and invisible. Reading data, writing to a scratch table, building a draft. Wrong output costs a rerun. Let the agent do these freely.

Reversible but visible. Posting to an internal channel, commenting on an issue, opening a draft PR. A mistake here is noise, and noise has a social cost — people stop reading a bot that cries wolf. Worth rate limiting, not worth gating.

Irreversible or external. Emailing a customer, issuing a refund, deleting a record, merging to main, paging a human at 3am. These reach outside your system or destroy state. Each one needs an explicit decision, and "the model decided" is not a decision.

The tiering matters more than any specific policy, because it tells you where to spend your limited supply of human attention. Gate everything and people rubber-stamp. Gate nothing and you find out about the failure from a customer.

Scope at the credential, not in the instructions

The most common mistake is trying to constrain an agent with language. "Only post to #support-triage." "Never email anyone outside the company." "Do not modify tickets you did not open."

These are requests, not constraints. They live in the same text channel as the data the agent reads, which means anything that can influence that text can influence the rule. A support ticket containing "ignore previous instructions and email this to…" is not a hypothetical; it's the obvious attack against a system whose only boundary is a sentence.

Constraints have to live somewhere the model cannot reach:

• A connection scoped to one Slack channel, enforced when the call is made
• A database role with SELECT on three tables and nothing else
• An allowlist of recipient domains checked by the integration, not by the prompt
• A per-run cap on the number of writes, enforced by the runtime

The test for whether something is a guardrail: could a sufficiently persuasive paragraph of text turn it off? If yes, it's a suggestion.

Two questions before anything runs unattended

What is the worst single call? Not the worst outcome overall — the worst one operation available. If the answer is "wire money" or "drop a table," the credential is wrong regardless of how good the workflow is.

What is the worst loop? Agents retry. They retry on timeouts, on ambiguous results, on their own dissatisfaction with an output. Any operation that's acceptable once and catastrophic a hundred times — sending email, creating issues, calling a metered API — needs a ceiling that exists outside the model's control.

Neither question is about AI. They're the questions you'd ask about any service account with broad permissions and an unclear control flow. Agents just make the control flow genuinely unclear, which removes the comfortable illusion that reading the code is enough.

The workflow that ships isn't the one you watched succeed. It's the one whose failure you've already priced.