Agent permission matrix
Access model
An agent permission matrix maps each AI agent against the actions it may take, and records the condition attached to every cell. It exists because role-based access control asks “who are you”, and the governing question for an agent is “what are you about to do, on whose behalf, and how far can it go wrong”. This page gives the model, a worked example, and the review discipline.
Why role-based access control breaks for agents
RBAC works because it makes a safe assumption: a principal's intent is roughly stable, and a human who holds a permission exercises it a few times an hour with judgement attached. Agents break all three parts of that.
| Human principal | Agent principal | |
|---|---|---|
| Rate | Bounded by attention | Bounded by rate limits. A wrong decision repeats thousands of times before anyone notices |
| Intent | Stable across a session | Derived per-step from context that may include untrusted input |
| Scope creep | Requires a request to IT | A line in a config file adds a tool, and the identity is unchanged |
| Judgement at the moment of action | Present, imperfectly | Absent by construction |
The second row is the one with teeth. An agent's effective intent at any moment is a function of its instructions and whatever text it has just read — a ticket, a web page, a document, a tool response. If any of that is attacker-controlled, the principal has not been compromised; it has been persuaded. Its credentials are working exactly as issued.
This is why identity-based permission is necessary and not sufficient. The question a permission matrix has to answer is not may this agent call this API but may it take this action, on this object, at this scale, given where the instruction came from.
The three-tier action model
Before building a matrix, classify actions. Almost every useful constraint falls out of putting each action into one of three tiers, and the tiers are defined by consequence rather than by API verb.
| Tier | Definition | Default posture | Examples |
|---|---|---|---|
| R — Read | Observes state. Changes nothing outside the agent's own process | Allow within a data-class boundary | Query a record, search documents, fetch a page |
| P — Propose | Creates an artefact a human must act on before it has effect | Allow, with attribution and rate cap | Draft an email, open a pull request, create a ticket, stage a change |
| A — Act | Changes state outside the agent with no further human step | Deny by default. Each cell individually justified | Send, deploy, pay, delete, grant access, message a customer |
Converting an A into a P is the highest-leverage move available in agent governance, and it is usually cheap. An agent that drafts a reply for one-click approval delivers most of the value of one that sends it, at a fraction of the risk, and the approval step is typically a few hours of work. Before writing a permission rule for an act-tier capability, check whether the propose-tier version is good enough — it often is, and nobody asks.
Two refinements that earn their complexity. Read is not automatically safe when the agent can also write somewhere: read access to special-category data plus propose access to an external channel is an exfiltration path assembled from two individually reasonable permissions. And reversibility splits the A tier — an action that can be undone in one step is a different animal from one that cannot, and the matrix should distinguish them.
Building the matrix
Agents on one axis, actions on the other. The content of each cell is the part that carries the meaning, and the common mistake is to make the cells boolean.
A cell is not yes or no. It is a tier plus its conditions. Six condition types cover nearly everything:
| Condition | Constrains | Example |
|---|---|---|
| Scope | Which objects | Only tickets in its own queue; only suppliers below tier 1 |
| Rate | How many, how fast | Max 50 per hour; max 5 per customer per day |
| Value | Magnitude | Refunds up to £100; no purchase orders above £5,000 |
| Provenance | Where the instruction came from | Allowed when triggered by an authenticated internal user; denied when the trigger is inbound external content |
| Time | When | Business hours only, when an approver is reachable |
| Escalation | What happens at the boundary | Above the cap, downgrade to propose — not fail |
Provenance is the condition most matrices omit and the one that addresses the actual attack. An agent that processes inbound email and can also send email needs a rule that distinguishes "act because an employee asked" from "act because something in a received message said to". Without it, every permission the agent holds is reachable by anyone who can send it text.
And escalation deserves its row. A permission boundary that fails closed and noisily is fine for a scheduled batch job and actively harmful for an agent in a customer conversation, where a hard failure mid-interaction is worse than a pause for approval. Prefer downgrade-to-propose over deny wherever a human is present.
A worked matrix
Four agents from a plausible mid-sized estate. Cells read as
tier: conditions; — is no permission.
| Action | Support triage | Invoice processing | Code assistant | Sales research |
|---|---|---|---|---|
| Read customer records | R: own queue only | R: billing fields only | — | R: CRM, no payment data |
| Read source repositories | — | — | R: non-secret paths | — |
| Update ticket status | A: own queue, max 200/hr, not to Closed | — | — | — |
| Email a customer | P: drafted, agent-attributed | — | — | P: drafted, max 20/day |
| Issue a refund | A: ≤£50, once per customer per 30d, human-triggered only | — | — | — |
| Approve an invoice | — | A: ≤£1,000, matched PO and receipt, known supplier | — | — |
| Create a new supplier | — | P: always — never act-tier | — | — |
| Open a pull request | — | — | P: max 10/day, never to main | — |
| Merge / deploy | — | — | — | — |
| Fetch external web content | R: allowlist | — | R: package registries only | R: open, marks output untrusted |
Three cells are doing most of the work here, and they are worth reading deliberately:
- Refunds are act-tier but human-triggered only. The provenance condition means an inbound message claiming to be a manager cannot reach the capability at all.
- Creating a supplier is permanently propose-tier. Supplier creation is the entry point for payment fraud; it is one of the few actions where the propose-tier version should be the permanent answer rather than a staging step.
- Sales research reads the open web and its output is marked untrusted, which should mean downstream act-tier permissions are unreachable in any chain containing that output. That mark is the mechanism by which a permission matrix survives prompt injection.
Chaining: the failure the matrix must not miss
A matrix scoped to individual agents misses the composition. Two agents, each correctly permissioned, produce a capability neither was granted:
Sales research reads an external page. The page contains instructions. Its output is passed to support triage, which holds an act-tier refund permission. Neither matrix cell is wrong. The path is.
Three defences, in increasing order of cost:
- Taint marking. Output derived from untrusted input carries a flag, and act-tier cells refuse to execute on tainted input. Cheap, and the single most effective control available.
- Explicit agent-to-agent permissions. Treat "may invoke agent X" as an action in the matrix like any other, rather than something that happens implicitly because both exist in the same runtime.
- Path analysis. Enumerate reachable chains from every untrusted entry point and check whether any terminates in an act-tier cell. Expensive to do by hand and the only thing that finds the three-hop version.
If you do one of these, do the first. Most real chaining incidents are one hop, from a read of external content to an action, and taint marking stops exactly that.
Reviewing and enforcing the matrix
A matrix is a design artefact and decays the moment the estate moves. Three disciplines keep it honest.
Compare declared against observed
The most valuable report in agent governance: actions an agent actually took in the last 30 days against the cells it holds. It surfaces two findings, both useful. Unused permissions should be removed — they are pure blast radius with no benefit. Actions with no matching cell mean either the matrix is out of date or the enforcement is not working, and you need to know which.
Review on change, not only on schedule
Adding a tool, changing a trigger, or widening a data scope changes the matrix whether anyone updates it or not. Tie the review to the configuration change, the way a code review is tied to a commit — a quarterly review of a document that changed in week two is theatre.
Enforce at the point of action
The uncomfortable part. A matrix constrains nothing unless something checks it when the action is attempted — a gateway, a proxy, a policy engine in the tool-call path. Encoding it only in the system prompt is not enforcement: the prompt is advisory, and the attack under discussion is precisely one that changes what the model believes its instructions are.
The honest sequence: build the matrix as a document, run it in monitor mode against real traffic to find out how wrong your assumptions were, then enforce. Enforcing a matrix built from assumptions breaks production on day one and teaches the organisation that agent governance is an obstacle — which costs more than the incident you were preventing.
Turning the matrix into an enforced control
The section above ends on the uncomfortable point: a matrix constrains nothing unless something checks it when the action is attempted. Concretely, what that requires and where Agent Trust Cloud sits:
| Matrix element | Needs | In Agent Trust Cloud |
|---|---|---|
| Tier (read / propose / act) | A check in the call path, not in the prompt | Runtime gateway — every consequential action passes a decision point |
| Scope, rate and value conditions | Per-call evaluation against the object being acted on | Policy engine |
| Provenance conditions | Carrying where the instruction came from through the chain | Prompt injection defence and delegation |
| Escalation — downgrade to propose | A human step that exists and someone watches | Human-in-the-loop approvals |
| Taint marking on untrusted output | A flag that survives being passed between agents | Data loss prevention and retrieval security |
| Declared vs observed report | A record of every action actually taken | Audit ledger |
| Deciding what belongs in each cell | Judgement about consequence | Nothing. This is the work, and it is yours. A tool that proposed your permission model would be guessing at your risk appetite |
The sequencing point from earlier, restated because it is the part that goes wrong: enforce a matrix built from assumptions and you break production on day one, and the organisation concludes that agent governance is an obstacle. Monitor mode exists for that reason — run the matrix against real traffic, see what would have been blocked, correct the cells that were wrong, then enforce. The free Discover plan is enough to find out how wrong the first draft is.
Common questions about agent permission matrix
What is an agent permission matrix?
An agent permission matrix is a table mapping each AI agent against the actions it may take, where every cell records both a permission tier — read, propose or act — and the conditions attached, such as object scope, rate caps, value limits and where the triggering instruction originated.
Why doesn't role-based access control work for AI agents?
RBAC assumes a principal's intent is stable and that a human applies judgement at the moment of action. An agent derives its intent per step from context that may include untrusted input, acts at machine rate, and can gain new capabilities from a configuration change without its identity changing at all.
What are the three agent permission tiers?
Read observes state and changes nothing outside the agent's process. Propose creates an artefact a human must act on before it has effect. Act changes state with no further human step, and should be denied by default with each permission individually justified.
What conditions should a permission matrix cell contain?
Six types cover most cases: object scope, rate cap, value limit, provenance of the triggering instruction, time window, and what happens at the boundary. Provenance is the most frequently omitted and the most important, because it separates acting because an employee asked from acting because received content said to.
How do you stop agents chaining permissions they were not granted?
Mark output derived from untrusted input as tainted and have act-tier permissions refuse to execute on tainted input. Treat invoking another agent as an action requiring its own permission. For high-risk estates, enumerate reachable paths from untrusted entry points and check whether any terminates in an act-tier capability.
How often should an agent permission matrix be reviewed?
On configuration change rather than on a calendar. Adding a tool, changing a trigger or widening a data scope alters the matrix immediately, so the review should be tied to the change the way code review is tied to a commit, supplemented by a periodic declared-versus-observed comparison.