Stolen Orbit
ENIT
Let’s talk
FREE TEMPLATE · FILL IN, DOWNLOAD, REUSE

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.

By Stolen OrbitRevision

When to use it and what to produce

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

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

Fill in the fields below and download your document. The website does not send or save answers: closing the page may lose them. Examples are illustrative and should be replaced with your process data.

Download the complete blank template (.md)

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.

See a worked example

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

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

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

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

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.

See a worked example

Illustrative example: an assistant creates a draft ticket note but cannot close tickets or send messages. Sending uses a separate approved action.

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

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

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

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.

See a worked example

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.

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

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

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

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.

Take the next step together.

Use this document to start a discussion about scope, evaluation and project ownership.

Review the text before sending. Only your email is needed alongside the message; other details are optional.