# AI permission matrix

Connect each identity to specific operations on defined resources. Explicit permissions make it easier to verify that an automation can perform only authorised work.

Revision: 2026-09-24

## When to use it

Before connecting data or tools to an assistant, giving a supplier access or extending automation to a new team.

## Expected output

An identity–resource–operation matrix with justification, approver, negative tests and a revocation procedure.

## 1. List identities and resources

Distinguish people, service accounts and identities used by workflows. Keep secrets out of this worksheet; record only references to their managed storage.

### Identity and owner

Describe who or what acts, in which environment and which person is accountable for the access.

________________

### Resources and data boundaries

Specify folders, tables, customers or teams; avoid broad descriptions such as “the entire CRM”.

________________

### Access purpose and duration

Connect access to a necessary task and record when it must be reviewed or removed.

________________

> Illustrative example, replace with your own: Illustrative example: a pilot service account reads approved support procedures only. It cannot access finance folders, personal drafts or other departments’ documents.

## 2. Specify operations

Treat reading, editing, deleting and sending as separate capabilities. Instructions written to the model do not replace controls in the connected system.

### Allowed operations

List actions, fields and actual limits; record where the service or integration enforces them.

________________

### Prohibited operations

Give concrete requests that must fail even when a user asks for them.

________________

### Additional approvals

Identify who may approve an individual action and how approval is tied to the exact content.

________________

> Illustrative example, replace with your own: Illustrative example: an assistant creates a draft ticket note but cannot close tickets or send messages. Sending uses a separate approved action.

## 3. Test and revoke

Test prohibited behaviour, including requests embedded in material the system reads. Plan removal of access before release, rather than after an incident.

### Allowed and denied tests

Record cases that should succeed and fail, the test identity and evidence of each outcome.

________________

### Reviews and changes

Specify who checks new permissions, role changes and accounts that are no longer used.

________________

### Revocation and operational response

Record who disables access, how workflows are stopped and how invalid credentials are confirmed.

________________

> Illustrative example, replace with your own: Illustrative example: reading an approved support procedure must succeed, while reading a finance document must fail. Then revoke the pilot identity and verify that reading the previously permitted support procedure is also denied.

## Pitfalls to avoid

- Sharing an administrator’s personal account with an automation.

- Confusing model instructions with an authorisation boundary.

- Removing a user while leaving project identities and keys active.

Stolen Orbit — https://stolenorbit.com/en/templates/ai-permission-matrix/