Template

AI Agent Permission Matrix

This matrix documents, tool by tool and action by action, what an AI agent is actually allowed to do: which role can invoke it, whether approval is required first, and any rate or volume limit. Writing this down before an agent goes live is what makes least-privilege access a designed property of the system, not an assumption about it.

In short

Download the CSV, and for every tool or system the agent can call, list each action it might take, the role permitted to trigger it, whether approval is required before execution, who the approver is, and any rate or volume limit. Read-only actions typically need no approval; anything that writes, sends, or spends usually should.

On this page
  1. Who this is for
  2. What's inside
  3. Next step

At a glance

  • One row per tool-and-action pair, not per tool: read access and write access to the same system are different rows with different approval rules.
  • The example rows model a common pattern: read is unrestricted, anything financial requires approval every time, and outbound communication is capped and scoped to internal recipients.
  • A rate/volume limit column bounds the blast radius of a mistake even inside actions the agent is allowed to take unsupervised.

Who this is for

This is for whoever configures or reviews what systems and actions an AI agent can reach: an engineering lead wiring up tool access, a security reviewer signing off before launch, or an operations owner who needs to know what the agent could do if it misbehaved.

Least-privilege access is a design decision, not a default. An agent with broad, unreviewed tool access can misbehave far more expensively than one scoped to exactly what its task requires.

What's inside

One row per tool-and-action pair:

Matrix columns (excerpt)
Tool / SystemActionApproval RequiredApprover
EXAMPLE: Billing systemIssue credit or adjustmentYAP supervisor

The three example rows show a read-only action (no approval), a financial write (approval every time), and a bounded outbound-communication action (rate-limited, no approval). The download adds blank rows for every tool and action your specific agent needs.

Download the permission matrix (CSV)

Should every write action require approval?

Not necessarily, but every write action should be a deliberate decision, not a default. Low-risk, easily reversible writes with a tight rate limit are a reasonable candidate for unsupervised access; anything financial, irreversible, or externally visible usually isn't.

What's a reasonable rate limit?

It depends on the action's blast radius if the agent is wrong — start conservative and widen it once you have evidence the agent behaves as expected.

Does this replace a security review?

No. It's the input a security review works from, not a substitute for one.

Next step

Once the matrix is filled in and reviewed, it becomes the actual specification the agent's tool access is configured against.

Related: pair this with the AI agent acceptance test plan to test the agent stays inside these boundaries, or the system handover checklist once it's live.