The Agent Reach Matrix. Agent type by access, access by data.
A framework for answering one question in a repeatable way: for each agent in your environment, which access does it hold, and what sits at the end of that access. Free to use, free to copy, and every cell has a documented incident behind it.
- Two matrices. Agent type by access layer, then agent type by the data behind it.
- The cells say always, often, sometimes, rarely. Not numbers, because nobody can verify a number they did not measure in their own environment.
- Every pattern in the matrix has a documented incident behind it, linked below.
- A cell nobody can fill is not a blank, it is a finding. It means an agent without an owner.
Part one: which access does each agent type hold?
The fourth column is the one most inventories skip, and it is the one that turns a narrow role into wide reach.
| 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 |
Part two: what does that access reach?
Same rows, read through to the end. This is the half that decides what to fix first.
| 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 |
Every pattern, with an incident behind it.
The matrix is not a model. Each card below is a record in the Agent Incident Database.
Download the matrix.
Both tables as CSV, plus the method as a readme. Licensed CC BY 4.0: use it, change it, put it in a vendor evaluation or a board pack. Credit Elmoz and link back, that is the whole licence.
Rather not start from a blank table? The Agent Reach Calculator fills this matrix in from six questions about your own environment, in your browser, and hands you the same two tables as a CSV.
How to fill it. Four steps.
The method is short on purpose. The work is in step two, and the value is in step four.
One row per agent that runs with its own identity. Two instances of the same product with different credentials are two rows, because their reach differs.
For each row, record what the identity may do directly, which roles it can assume, which secrets it can read and which grants it inherits from the account it runs as. The fourth column is the one most inventories skip.
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.
An unknown is a result. A cell nobody can fill is an agent nobody owns, which is the definition of a shadow agent.
What the matrix is not
It is not a maturity model and it does not produce a number. Two organisations with identical matrices can be in very different shape, because the matrix describes which doors exist and not how well each one is watched.
It also 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. That is deliberate: likelihood changes weekly, reach changes when somebody changes access.
Use it with agent reach for the measurement and breakpoints for the fix.
Which doors exist, and what is behind each one.
Questions, answered.
What it is, why it has no score, and how to use it.
What is the Agent Reach Matrix?
A two-part matrix for mapping agent reach. The first part maps five agent types against the four layers of access an agent can hold. The second maps the same types against the data classes those layers lead to. Filling it for your environment produces a prioritised list rather than a score.
Why a matrix and not a score?
A score hides the step you would have to change. The matrix keeps the structure visible, so the output is a cell you can act on: this agent type, through this layer, reaches this data. That is also why the cells say always, often, sometimes and rarely rather than giving numbers nobody can verify.
Can I use it for my own assessment?
Yes. It is published to be copied, including into vendor evaluations and internal reviews. The four steps under How to fill it are the whole method, and the rows are meant to be replaced with the agents you actually run.
Use it with these.
The matrix gives the structure. These give the method and the evidence.
See what your agents can reach. Before someone else does.
Book a demo and we walk through the access paths in an environment like yours.