How to measure an AI agent's blast radius

Every conversation about agent security eventually asks the wrong question first. This article is about the right one, and about how to answer it with something more useful than a vibe.

The wrong question

The wrong question is: how likely is this agent to do something bad?

It is wrong for three reasons.

It is unanswerable. Nobody can put a number on the probability that a model misreads an instruction, and anyone who claims to has produced a number by choosing one.

It is unstable. The answer changes with every model update, every prompt change, and every document the agent happens to read. A risk assessment that expires on the next release is not a risk assessment.

And it is the wrong shape. Security has never worked by predicting failures. It works by bounding them. We do not deploy a database with production credentials in the frontend and reason carefully about how unlikely a bug is; we scope the credential. The whole discipline is built on the assumption that things go wrong and the job is to limit what "wrong" can reach.

The right question is the one you can actually answer from configuration:

If this agent is compromised, manipulated, or simply wrong, what could it do?

That is the blast radius. It has the properties a security metric needs: it is knowable, it is stable until someone changes something, and, critically, it is actionable, because every input to it is a decision somebody made and can unmake.

Nine dimensions

Blast radius is not one thing. Nine dimensions determine how bad an agent failure is, and they are close to independent.

1. Reachable systems

How many distinct systems can the agent act against? An agent with one MCP server has one failure domain. An agent with six has six, and, because it can move information between them, it has more than six.

This is the dimension that grows fastest and gets noticed least. Adding a server is four lines of JSON.

2. Available tools

The tool surface. Not just how many, but how specific: fifteen narrow tools that each do one thing are a smaller radius than three tools that each take a free-form string.

3. Destructive capability

Can the agent destroy state? This is the sharpest single dimension, because it is the one where "we noticed and fixed it" stops being available. Every other class of mistake is recoverable at some cost. Deletion frequently is not, and the cost lands on whoever needed the data.

4. Credential privilege

The agent acts with the authority of whatever credentials it holds. A read-only, single-table, expiring database credential and an owner-role connection string produce identical-looking configuration and radically different blast radii.

This is where the leverage is. Narrowing a credential is usually cheaper than narrowing a tool, and it bounds every tool at once.

5. Data sensitivity

What can it read? Not "does it have a read tool". What is on the other side of it. Public documentation and a customer database are the same capability class and different incidents.

6. External communication

Can information leave? Email, Slack, a comment on a public issue, an outbound HTTP request, a DNS lookup. This dimension is routinely underestimated because it looks passive. It is not: it is the difference between "the agent read something it should not have" and "an attacker now has it."

7. Execution ability

Can the agent run code? Arbitrary execution collapses every other dimension: an agent that can run sh -c can read what the process can read, write what it can write, delete what it can delete, and open a socket to anywhere. It does not matter which other tools you did or did not grant.

Unrestricted SQL belongs here too. execute_query against a database can read every table, write every table, drop every table, and on several engines reach the filesystem or the network.

8. Reversibility

If the wrong thing happens, can you undo it? A git commit is reversible. A force-push over a branch nobody else has is not. A Slack message is technically deletable and practically not, because people read it.

Reversibility is what separates "we had an incident" from "we had an outage", and it is almost never in anyone's threat model.

9. Environment

Is this production? Every other dimension gets worse when the answer is yes, and production access has a habit of being granted during an outage and never taken back.

The capability graph

Nine dimensions is a checklist, and a checklist does not compose. To reason about an agent you need a structure.

The structure is a bipartite graph: agents connect to systems through tools, and each tool carries capabilities.

                  ┌──────────────┐
                  │    Agent     │
                  └──────┬───────┘
         ┌───────────────┼───────────────┐
         │               │               │
  ┌──────▼─────┐  ┌──────▼─────┐  ┌──────▼─────┐
  │  postgres  │  │ filesystem │  │   slack    │
  └──────┬─────┘  └──────┬─────┘  └──────┬─────┘
         │               │               │
  execute_query     read_file       post_message
  read · write      read            communicate
  delete · execute  ~/ (home)       write

Once you have this, the interesting facts stop being about individual tools and start being about paths through the graph:

• Is there a path from any read to any communicate? That is an exfiltration path, whether or not one server has both.
• Is there a path from execute to a production credential? That is a remote shell on production.
• Is there a path from admin to anything? Then the graph can be rewritten by the thing you are analysing.

The graph is also why tool names are the wrong unit of analysis. write_file, fs.put, edit and apply_patch are four names for one consequence. Normalising to capabilities is what makes the analysis portable across ecosystems, and what makes it possible to say something about a server nobody has ever seen before.

Composition is the whole problem

Individual capabilities get reviewed individually, and individually most of them look reasonable. Every incident of consequence comes from a combination.

Simon Willison named the most important one the lethal trifecta:

1. access to private data
2. exposure to untrusted content
3. the ability to communicate externally

Any one is fine. Any two are usually fine. All three means attacker-controlled text can cause your data to be sent to the attacker, and no amount of model quality closes that, because the model is behaving correctly. It read an instruction and followed it.

Other combinations that are worse than the sum of their parts:

This is the argument for measuring blast radius as a property of the agent rather than reviewing tools one at a time. Reviewing each tool in isolation is exactly the process that lets a lethal combination through, because at no point does anyone see both halves.

Turning it into a number

You can score this. You should be careful about how much you claim for the score.

Gate assigns points per dimension, sums them, and clamps to 100:

systems                4 per server, max 12
tools                  2 per 5 tools, max 10
capability mix         weighted by class, max 30
credential privilege   3 / 8 / 12 (some / broad / production)
filesystem scope       2 / 8 / 12 / 15 (repo / external / home / root)
environment            10 if production indicators
reversibility          8 if delete or execute available
execution              15 if arbitrary execution
egress                 6 if external communication
consequential actions  10 financial, 7 destructive
combinations           3 each, max 9

Some facts are counted twice. execute raises the capability mix and fires the execution contributor. Each dimension has to stand on its own in the output, so they overlap. The clamp means overlap changes ordering, not the ceiling.

Four bands, because more precision would be false precision:

LOW        0-19
MODERATE  20-44
HIGH      45-69
CRITICAL  70-100

The weights are judgement, not measurement. There is no dataset of agent incidents to calibrate against: the field is eighteen months old. Anyone publishing a precise agent risk score is publishing a precise-looking opinion.

What makes the score honest is that it is fully decomposed. Gate always prints the contributors, so the output is not "84/100, trust us" but a list of specific facts, each of which you can go and change:

Blast radius: CRITICAL (84/100)

Why:
  + arbitrary SQL execution
  + production-looking credential in scope
  + destructive operations available
  + filesystem access beyond the repository

If a reader disagrees with a weight, they can see exactly which one and by how much.

Where the number stops

Arithmetic is a bad way to express "this one fact is decisive".

An agent with a single tool, a shell, scores low on systems, low on tool count, low on everything except execution. Summed naively it lands in MODERATE, which is nonsense: it can do anything the process can do.

So the model has escalation floors that override the score:

Floors are where the qualitative judgement lives. It is stated in the output instead of buried in a coefficient:

Escalated because a credential directory is in scope alongside an external
communication channel.

What the number is for

Not for comparing your agent to someone else's. The weights are not calibrated well enough for that, and a cross-organisation agent risk benchmark would be fiction.

It is for two things.

Ordering your own work. Which of the eleven things you could fix this afternoon moves the level? The contributors are sorted by points, so the answer is the top line.

Detecting change. This is the real value. A repository compared against itself over time gives a signal with no calibration problem at all, because both measurements use the same flawed weights:

This change increases the agent's blast radius.

NEW capabilities: execute, delete
Baseline blast radius was MODERATE, recorded 2026-08-01.

That sentence changes reviewer behaviour in a way that "47 issues found" never does. It is specific, it is attributable to the diff in front of them, and it is falsifiable. You can point at the line that caused it.

A one-line addition to .mcp.json can grant an agent the ability to delete production data. It reviews like configuration and behaves like a privilege grant. Measuring blast radius is how that stops being invisible.

Reducing it

In rough order of value per unit of effort:

1. Scope the filesystem. Changing ~ to ./project in one argument frequently removes several findings and an escalation floor at once.
2. Narrow the credential. A read-only, expiring, single-purpose credential bounds every tool on that server simultaneously.
3. Remove destructive tools. Ask what breaks if the agent cannot delete. Usually nothing.
4. Break a combination. Splitting secrets and communicate across two agents with two credentials is often far cheaper than hardening either.
5. Replace arbitrary execution with named operations. Three parameterised queries instead of execute_query. This is the expensive one, and the one with the largest effect.
6. Keep a human in the loop for the irreversible things. Approval is the control everything else quietly assumes.

None of these make the agent smarter. All of them make its failures survivable, which is the only property that has ever reliably worked.