White paper

The agent blast radius:
what can it actually touch?

An AI agent's risk is not what it is — it's what it can reach. Permissions, data stores, tools, MCP servers, other agents, and the humans who stopped watching it. This paper looks at why a flat inventory can't answer the question that matters, and what a relationship graph reveals.

The wrong question

Most AI risk conversations start with the model: which LLM does the agent use, is it hosted in the right region, what was it trained on. Those questions matter, but they miss where the actual risk concentrates. An agent wrapping the most carefully aligned model in the world is still dangerous if it holds write access to your CRM, a mailbox, and a payment workflow. And a crude agent with access to nothing is a curiosity, not a threat.

The question is not "how smart is the agent?" It is "what happens if it goes wrong — and how far does that travel?"

Risk is reach

Security teams already have a name for this: blast radius. For an AI agent, the blast radius is the union of everything its identity can touch — the API permissions it holds, the data sources it's connected to, the tools it can invoke, the actions those tools can perform, and the downstream systems those actions land in. Two agents that look identical in a list can differ by orders of magnitude in reach, because reach lives in the connections, not the object.

Reach also compounds quietly. Each new connector added to an agent multiplies what a single misfire, prompt injection or compromised credential can do. An agent's risk profile is therefore not a property you assess once — it's a shape that changes every time an edge is added or removed.

Where flat inventories fall down

A flat inventory — one row per agent, columns for name, platform, owner, date — answers "what exists?" It cannot answer "what can this reach?", "what else breaks if this is compromised?", or "which agents can touch this dataset?" Those are traversal questions, and rows don't traverse. The analyst ends up reconstructing the connections by hand, per incident, from six admin consoles — exactly the work that should have been done once, continuously, by the inventory itself.

A list tells you what you have. Only a graph tells you what you're exposed to.

Thinking in graphs

The natural model connects each canonical agent to its source observations (where it was seen and by which collector), its owners (business sponsor, technical owner), the resources it can reach, the tools it can call, and the servers those tools live on. With those edges in place, the important questions become one-hop queries: show this agent's neighbourhood; show every agent with a path to the finance data; show what becomes unowned if this person leaves. Attack-path thinking, applied to the AI estate.

The same graph is what makes governance decisions defensible. An approval that recorded the agent's neighbourhood at decision time can be compared against its neighbourhood today — and the delta is precisely what recertification should be reviewing.

Tools and MCP servers: the new edges

The fastest-growing edges in the graph are tool connections — increasingly standardised through the Model Context Protocol. MCP is excellent news for interoperability and troubling news for governance: it makes attaching a new capability to an agent nearly frictionless, and each MCP server is a shared dependency whose own access rolls up into the blast radius of every agent connected to it. A single over-permissioned MCP server can silently widen the reach of dozens of agents at once.

That makes tool servers first-class citizens of the inventory — not an implementation detail. You need to know which servers exist, which agents connect to them, and what those servers can themselves reach.

Content-free by design

There's an obvious objection: a map of every agent, permission and data connection is itself a sensitive artefact. This is why the graph must be content-free — it records that an agent is connected to a data source, not what flows across the connection; the shape of access, not the accessed data. Structure without payload keeps the governance system from becoming the very exfiltration risk it exists to manage, and keeps it deployable inside your own tenant boundary.

From list to picture

Agent governance that stops at a list will always be one incident behind: it can tell you the agent existed, but not what the incident could have touched. Governance built on a relationship graph starts from the question that actually matters — reach — and keeps the answer current as the estate changes. Apex Warden builds exactly this: a content-free relationship graph connecting every canonical agent to its observations, owners, resources, tools and MCP servers, queryable per agent or across the whole estate.

See your agents' blast radius

Book a walkthrough of the relationship graph across a live estate — per-agent neighbourhoods and estate-wide reach.

Get a demo