Blast radius: what delegation actually delegates

Before you let an agent loose, answer one question: if this thing is wrong in the worst plausible way, for as long as it plausibly takes anyone to notice, what is the total extent of the damage? That is the blast radius, and it is the only number in agent governance that matters more than accuracy.

It has three dimensions, and organisations usually reason about the first and ignore the other two.

Reach: what the agent can touch

Reach is the set of systems, records and people the agent can affect through its tools and its credentials. It is not what the agent was built to do; it is what it is capable of doing.

The commonest way reach becomes enormous is invisible. The agent runs under a service account or a human account that already had broad rights, because provisioning a narrow identity was extra work. ASI03 in the OWASP Top 10 for Agentic Applications 2026 names this as Identity and Privilege Abuse. The fix is not clever and it is not popular: give the agent its own identity, with only the permissions its actual task requires, and accept that this takes a week.

Reach also grows sideways. An agent that can send email can reach anyone with an address. An agent that can write to a shared record can reach everyone downstream of that record, including other automated processes that will consume its output without question.

Rate: how much it can do before anyone notices

A person making a poor decision makes one poor decision. An agent making a poor decision makes it for every case in the queue, in the time it takes to work through them, which may be minutes.

Rate is why a low error probability is not reassuring on its own. Multiply any error rate by volume and the question stops being how often it is wrong and becomes how many wrongs accumulate before detection. The governing quantity is therefore time to detection, and that is a property of your monitoring, not of the agent.

ASI08, Cascading Failures, is rate compounding with reach. One wrong step becomes the input to the next, each individually plausible, the sequence moving further from anything a person would have chosen.

Reversibility: what can be undone

This is the dimension that decides whether the other two are survivable, and the one most often left out of the design conversation.

Some actions are cheap to reverse: a draft, a record updated with a full history, a queued item not yet released. Some are expensive: a payment made, a contract issued. Some cannot be reversed at all: an email received and read, a decision communicated to a customer, personal data disclosed to a third party.

Sort every tool the agent can call into those three buckets before deployment. The sorting is the control. Irreversible actions either sit behind a human step or are not in the agent's reach at all, and that is a design decision made before anyone writes a prompt, not a policy written afterwards.

The controls that follow

Blast radius reduction is dull and it is what works.

• Its own identity, minimum rights. The agent is not a person and should not borrow one's credentials.
• Irreversible actions gated. A named human approval step, on a unit small enough to be genuinely reviewed.
• A ceiling. A limit on how many actions the agent can take before it must stop and be re-authorised, so that time to detection has a hard bound rather than a hopeful one.
• Logging sufficient to reconstruct the sequence. Article 12 of the EU AI Act requires automatic event logging over the system's lifetime for high-risk systems, and Article 26(6) requires deployers to keep those logs for at least six months. For an agent, the log has to record what it decided and what it called, not merely that it ran.
• A stop that lands somewhere safe. Article 14(4)(e) requires intervention or interruption through a stop button with the system halting in a safe state. Work out what that state is for a half-finished sequence, in advance.

Who is answerable

The agent is not. Under Article 26 a deployer must assign oversight to people with the competence, training and authority to exercise it, and must suspend use and inform the provider where a risk is identified. FINMA Guidance 08/2024 makes the same point for supervised institutions in one sentence worth memorising: responsibility remains with the institution even where the AI is bought in or outsourced. Delegating the work never delegates the answerability.

As of 24 September 2026.