AI Agent Access Review Checklist: Audit Grants, Identities, and Expiring Permissions Before They Go Stale

Permissions drift. An agent gets a grant for one job, then the job changes, the tools change, and the owner changes — but the grant stays exactly as it was issued. A scope that was correct on the day it was granted can be wrong now, and nothing in a typical stack announces the moment it goes stale. The AI agent access review checklist is the recurring pass that catches that drift: inventory the identities, verify the grants, shrink what has crept, and prove the audit chain still holds, before an incident or a reviewer finds the gap for you.

Practitioners on Hacker News have put the underlying question plainly: who can use which agent, and what can each agent access? A review is how you keep a current, defensible answer to that question. It is not a one-time cleanup. Identities are issued, grants expire, agents are decommissioned, and hard gates get re-tested — the review is the cadence that keeps all of that true at once, instead of true only on the day you set it up.

The AI agent access review checklist¶

1. Inventory every identity. Format each agent identity as agent:[OWNER]/[NAME], and record it in the identity registry with the identity, the owner, the date issued, and its status. Anonymous, shared, or unregistered actors are rejected at the dispatch path — never warned about. If an entry in the registry has no owner, it is not a minor paperwork gap: an ownerless identity means nobody is accountable for what that actor does, and nobody will notice when its grants should have been revoked.
2. Verify every grant record is complete. Every grant records six things: capability, scope, issuing owner, date issued, expiry date, and the identity it is issued to. Walk the grant store and check each record field by field. A record missing a field is not a grant you can defend — you cannot say who authorized it, what it covers, or when it ends. Incomplete records get completed or revoked during the review, not carried forward on trust.
3. Hunt down permanent grants. Permanent grants are prohibited. Every grant expires, and auto-grant is prohibited: every grant requires an explicit issuance decision. If the review finds a grant with no expiry, revoke it and reissue it bounded, with a real expiry date, and record that change as an audit row. A permanent grant is a standing credential that outlives the task, the plan, and usually the person who issued it.
4. Run a least-privilege shrink pass. Shrink each grant to the minimum capability and scope the agent has demonstrated it needs. List capabilities the way your agents actually invoke them — tool names, API calls, cron jobs — not the way an architecture diagram describes them. Grants that cover tools the agent never calls are pure attack surface. When in doubt, shrink: a grant that turns out too narrow produces a recorded block you can fix; a grant that was too broad produces an incident you cannot undo.
5. Re-test the hard gates. The hard-gated actions always require a recorded human approval, with no auto-grant path, ever: moving money, accepting contracts or terms of service, external outreach, accessing or transmitting credentials or secrets, changing agent permissions or grants, and any action with legal consequences. The approver must be a human, and the acting agent can never approve its own action. During the review, attempt a hard-gated action in a test and confirm it cannot complete without that recorded approval — a gate you have not tried to bypass is a gate you are assuming works.
6. Confirm decommissioned identities stay dead. When an agent is retired, its identity is revoked — and a revoked identity is never reissued to a different agent. Check the registry for decommissioned identities, then check the grant store for any live grant still issued to one. A live grant pointing at a dead identity means the access outlived the agent, and whoever or whatever picks up that identity string next inherits it silently.
7. Verify the hash-linked audit chain. Every request, approval, block, and outcome writes an audit row, and each row's hash chains to the previous one: the row hash is the lowercase hex SHA-256 digest of the canonical JSON of the row with the hash field removed, concatenated with the previous row's hash. Sequence numbers increment by exactly one per row, and the first row uses GENESIS as its previous hash. Recompute every row in sequence order. Any mismatch fails the entire chain visibly — a bad row is never skipped silently. If verification has not run since the last review, you do not currently know your log is intact; you only know nobody has checked.
8. Check every block carries its unblock checklist. When required evidence is missing — identity, grant, approval, budget headroom, or terms record — the action is blocked, never degraded to a warning. Every block persists with the exact reason, and tells the owner, in plain language, exactly which piece of evidence would unblock it. Blocked actions are never retried automatically: a retry requires new evidence, not a timer. During the review, read a sample of recent blocks. If an owner could not act on one from the block message alone, the block is a maze, not a control.
9. Name the review owner and set the next date. A review with no named owner and no next date was a one-off audit, not a control. The review itself is recorded as an audit row: who ran it, what it found, what changed. Policy review is quarterly in the Studio Edition's adoption guidance, or sooner if a red-team exercise finds a gap the policies did not cover — use that same trigger for access reviews. The next date goes on the record before this review closes.

What breaks when you skip the review¶

Skip the pass and the failures accumulate quietly. Scope goes stale: agents keep access to data classes, tools, and storage they needed for a job that ended. Privilege creeps upward, because grants are added under deadline pressure and almost never removed without a scheduled reason to remove them. Decommissioned identities linger with live grants attached. Hard gates that were real when they were built get quietly routed around by a new integration nobody tiered. And the audit chain — the evidence all of this happened correctly — drifts unverified, so the first time anyone recomputes it is during an incident review, which is the worst possible moment to discover a broken link.

None of these failures announce themselves. The system keeps working, which is exactly the problem: an over-permissioned agent is indistinguishable from a correctly permissioned one until the day it does something it should never have been able to do. The review is cheap precisely because it runs when nothing is wrong.

Put this into practice¶

The AI agent access review checklist is the recurring pass. The Governed Agent Mesh Playbook — Studio Edition (https://ghostcorpnet.gumroad.com/l/hdigmr) gives you the controls it checks against: the identity policy and grant issuance policy written ready to adopt, the audit-row schema and hash-chain verification steps, the risk-tier worksheet, and the 14-day rollout that installs identity, grants, audit, spend limits, and approval gates in order. Install the controls once, then run this review on a cadence — that is what keeps them true.