# The Agent Reach Matrix

An open matrix for mapping what AI agents can reach. Published by [Elmoz](https://elmoz.de)
under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). Copy it, change it, use it in
your own reviews and vendor evaluations.

Full version with the evidence behind every cell: <https://elmoz.de/agent-reach-matrix>

## Why

Most agent inventories list what agents exist. The question that decides risk is a different
one: for each agent, which access does it hold, and what sits at the end of that access.
The matrix keeps both halves visible, so the output is a cell you can act on rather than a score.

The cells say `always`, `often`, `sometimes`, `rarely`. Not numbers, because a number nobody
measured in their own environment is a claim, not data.

## Part one: agent type by access layer

| Agent type | Direct permissions | Assumable roles | Readable secrets | Inherited grants |
|---|---|---|---|---|
| Coding agent | often | often | **always** | often |
| OAuth-connected AI tool | **always** | rarely | rarely | **always** |
| MCP-connected agent | sometimes | sometimes | **always** | often |
| Cloud automation agent | **always** | **always** | often | rarely |
| Customer-facing agent | **always** | sometimes | sometimes | rarely |

The fourth column is the one most inventories skip, and it is the one that turns a narrow role
into wide reach.

## Part two: agent type by data reached

| Agent type | Source code | Production data | Customer PII | Secrets | Destructive actions |
|---|---|---|---|---|---|
| Coding agent | **always** | often | sometimes | **always** | often |
| OAuth-connected AI tool | sometimes | rarely | **always** | sometimes | rarely |
| MCP-connected agent | sometimes | often | often | often | often |
| Cloud automation agent | rarely | **always** | often | often | **always** |
| Customer-facing agent | rarely | often | **always** | rarely | sometimes |

## How to fill it for your environment

1. **List the agents, not the tools.** One row per agent that runs with its own identity. Two
   instances of the same product with different credentials are two rows.
2. **Fill the access columns from the environment.** What the identity may do directly, which
   roles it can assume, which secrets it can read, which grants it inherits from the account it
   runs as.
3. **Translate access into data.** Follow each filled cell to what sits at the end of it. A role
   is not a finding, the production database behind the role is.
4. **Mark the cells you cannot answer.** An unknown is a result. A cell nobody can fill is an
   agent nobody owns.

## What it is not

Not a maturity model, and it does not produce a number. It does not rank agents by how likely
they are to be attacked, it ranks them by what an attacker or a confused agent would get.
Likelihood changes weekly. Reach changes when somebody changes access.

## Evidence

Every pattern above has a documented incident behind it. The ones linked on the web version:

| Cell | Incident |
|---|---|
| Coding agent x readable secrets | [PocketOS production volume](https://elmoz.de/agent-incidents/cursor-deleted-production-database-railway-pocketos) |
| Coding agent x inherited grants | [Screenshots in public repos](https://elmoz.de/agent-incidents/coding-agents-public-repos-screenshot-leak) |
| OAuth tool x inherited grants | [Vercel via an AI tool](https://elmoz.de/agent-incidents/vercel-breach-ai-oauth-attack-path) |
| MCP agent x readable secrets | [AWS AgentCore](https://elmoz.de/agent-incidents/aws-agentcore-vault-plaintext-credentials) |
| Cloud automation x assumable roles | [Storm-3168](https://elmoz.de/agent-incidents/storm-3168-azure-service-principal-attack) |
| Customer-facing x direct permissions | [Medicare statistics portal](https://elmoz.de/agent-incidents/openai-agent-medicare-portal-breach) |

More records: <https://elmoz.de/agent-incidents/>