Review every entitlement against two questions: which approved capability needs it, and did the agent use it? An access review for AI agents lists each agent identity's entitlements, group memberships and temporary grants, matches them to the capability matrix and to usage logs, and removes whatever cannot be justified. The sponsor certifies each line; the identity team removes the rest.
What is an agent access review, and who owns it?
Access reviews are a standing control for staff accounts: managers confirm their people still need what they have. Agents need the same review, with two differences. Their needs are written down, in the capability matrix, so the review can be exact. And their usage is fully logged, so you can see whether an entitlement was ever used.
The identity and access management team owns the review cycle. Each agent's sponsor, usually its process owner, certifies its access. Data owners certify access to sensitive data. Risk sets how often each tier is reviewed, with the highest-risk agents reviewed most often.
What are the steps?
- Agent, depth 1: builds the population: every agent identity from the access management system, matched to the inventory.
- Agent, depth 1: lists each identity's access: direct entitlements, group memberships, shared drives, mailboxes, temporary grants, and network or internet access.
- Agent, depth 1: matches access to capabilities. Each line is linked to the approved capability it serves, or marked as unlinked.
- Agent, depth 1: adds usage: when each entitlement was last used during the period, from logs.
- Agent, depth 2: drafts recommendations: remove unlinked access, remove unused access, remove expired temporary grants, and flag identities whose sponsor has left or whose certificate has lapsed.
- Person, sponsor: certifies each line, keeping, removing or querying, with a reason for anything kept that was unlinked or unused.
- Person, data owner: certifies sensitive data access separately.
- Person, identity team: removes access as decided and confirms removal.
- Person, identity team: escalates lines nobody certified by the deadline, which are removed by default.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Population | Lists agent identities | 1 | Nothing |
| Access list | Gathers every entitlement and grant | 1 | Nothing |
| Match | Links access to capabilities | 1 | Nothing |
| Usage | Adds last-used dates | 1 | Nothing |
| Recommend | Drafts keep or remove per line | 2 | Nothing |
| Certify | Nothing | none | Sponsor's decision per line |
| Sensitive data | Nothing | none | Data owner's decision |
| Remove | Nothing | none | Executing removals |
| Escalate | Nothing | none | Default removal |
Which decisions does a named person keep?
Keeping unlinked or unused access. Sometimes an entitlement is needed rarely, such as a quarter-end report. The sponsor may keep it with a reason. The default is removal.
Sensitive data. The sponsor knows what the agent does; the data owner knows what the data is. Both must agree.
Removal by default. If nobody certifies, the identity team removes access. Agents with no answering sponsor should lose access, not keep it.
Whether a finding is bigger than access. An agent holding access far beyond its role may be a sign of an unapproved change, which goes to the process owner and risk, not only to the identity team.
The checklist items are set out in the AI agent access review checklist.
What should the review look at closely?
Temporary grants. Access requested for a task and never expired. Each request should show its expiry; see how to let an AI agent request access through your access management system.
Group memberships. An agent added to a team group inherits everything the group can reach, often far beyond its capabilities.
Internet and outbound access. An agent that can browse or call external services can bring in untrusted content and send data out. Review whether each agent needs it, as discussed in can an AI agent access the internet safely?
Refusals at the sources bound. Repeated refusals for the same data suggest either a missing entitlement or an agent being pushed to reach data it should not. The review is the right place to decide which.
What record does the review produce?
The review pack with population and access lists; the usage data; the recommendations; a decision and reason per line, signed by the sponsor or data owner; removal confirmations; and escalations. Keep the pack for each cycle, so the next review can compare and auditors can test that removals happened.
What should you measure?
- Lines removed per cycle, which should fall as access is right-sized.
- Unlinked access found, which shows how often access is added outside the capability matrix.
- Lines kept against recommendation, with reasons.
- Removals completed on time.
- Identities with no active sponsor. The target is none.
Where does it usually go wrong?
Agents are left out of the staff review. The review tool lists people only, and agent identities never appear.
Sponsors approve everything. Without usage data and capability links, certification is a click. Show both on each line.
Removal breaks a process. Access thought unused turns out to be monthly. Look at a long enough usage window, and remove in stages for critical agents.
Shared identities. Several agents use one identity, so nobody can say which needs what. Split them before the review.
Where Pryme fits
In Pryme, each agent's capabilities and sources are defined per capability, so the review can compare access in your systems against what the platform permits each capability to use. Every refusal names its bound. More in agent governance is a bound, not a model.
Questions people ask
How often should agent access be reviewed?
At least as often as privileged staff access, and more often for high-tier agents. Also review after a role change, a new connector or an incident, rather than waiting for the cycle.
Can the agent certify its own access?
No. It can gather data and draft recommendations. Certification is a statement of need by an accountable person, and an agent vouching for its own access defeats the purpose.
Should unused access always be removed?
By default, yes. Keep it only with a reason, such as a periodic task, and a note to check it next cycle. Unused access is risk with no return.