An AI agent access review checklist is the list of checks a reviewer works through, agent by agent, to confirm every identity, credential, permission and connection is still needed, still owned and still within the agent's role. Anything unused, unowned or wider than the role is removed. The checklist below and a worked sample show how.
Why review agent access separately?
Access reviews were designed for people who join, move and leave. Agents do none of those things visibly. They accumulate permissions as teams add connections for a pilot, a one-off task or a workaround, and nobody removes them because the agent never "leaves". The result is the familiar problem of excessive access, in software form.
Agents also have kinds of access people do not: service accounts, API keys, tokens to other agents, internet access, write access to queues. A review built for human users misses most of these. How to run the review end to end is covered in how to run an access review for AI agents.
When should you use it?
Quarterly for agents at depth 3 or above, and at least every six months for the rest. Also run it at three trigger points: before go-live, as part of the AI agent go-live approval checklist; after any incident; and when an agent's role charter changes.
Finance teams should also run a narrower version on any agent that touches the payment run, as the payment run review checklist suggests.
How do you fill in each check?
Identity confirms the agent has its own identity and does not borrow a person's.
Permissions are compared, one by one, with the role charter. Each permission needs a capability it serves. If you cannot name the capability, remove the permission.
Usage checks whether each permission was used in the review period. Unused permissions are removed unless there is a written reason, such as a quarterly task.
Requests checks how access was granted. Access should come through your normal request route with an approver; see letting an AI agent request access through your access management system.
External reach covers internet access and outbound connections, which carry their own risks; whether an AI agent can access the internet safely explains them.
The checklist
| No. | Check | Evidence | Result |
|---|---|---|---|
| 1 | Agent has its own identity, not a person's | Identity record | |
| 2 | Named accountable owner still in role | HR or org chart check | |
| 3 | Every permission maps to a capability in the role charter | Permission list against charter | |
| 4 | Every permission used in the period, or reason recorded | Usage log extract | |
| 5 | No permission broader than needed (write where read would do) | Permission detail | |
| 6 | All credentials rotated within policy | Credential vault record | |
| 7 | No credentials shared with another agent or person | Vault and config review | |
| 8 | All access granted through the approved request route | Request tickets | |
| 9 | Connections to other agents listed and justified | Connection map | |
| 10 | Internet and outbound access limited to named destinations | Network rules | |
| 11 | Agent cannot change its own permissions | Configuration check | |
| 12 | Removals actioned and confirmed | Change record | |
| 13 | Reviewer is independent of the agent's configuration | Reviewer name |
A worked sample
A hypothetical bank's collections agent, quarterly review.
| No. | Finding | Action |
|---|---|---|
| 1 | Own service identity | None |
| 2 | Owner moved to a new role last month | New owner named: collections operations manager |
| 3 | Write access to customer address field not in charter | Removed |
| 4 | Read access to mortgage system unused for the quarter; was granted for a pilot | Removed |
| 5 | Payment arrangement system: write access needed to draft arrangements; agent only drafts | Reduced to draft-only role |
| 6 | API key last rotated within policy | None |
| 9 | Connection to the complaints agent used for handoffs | Justified, kept |
| 10 | Outbound access to one address-lookup service | Justified, kept |
| 11 | Confirmed: no permission to the access management system | None |
| 13 | Reviewer: IT risk analyst, not involved in configuration | None |
Three removals and an ownership fix in one review is typical for an agent that went through a pilot. Item 3 mattered most: write access to addresses would let the agent send customer letters elsewhere.
Where Pryme fits
In Pryme, each agent acts under its own identity with permissions tied to its certified capabilities, and an agent cannot change its own bounds. The verdict record shows which permissions were used and when, which fills items 3 and 4. See agent governance is a bound, not a model.
Questions people ask
Who should perform the access review?
Someone independent of the agent's configuration, usually from IT risk or the second line. The accountable owner confirms the business need for each permission.
What if removing access breaks the agent?
Then the permission was serving a capability that is not in the charter, or the charter is incomplete. Either update the charter through change control or accept the narrower agent.
Should test environments be reviewed too?
Yes, if the agent's test identity can reach real data or production systems. Test credentials are a common route to production access.