AI Access Review Checklist: Who Can Reach What

Access to AI systems accumulates quietly — people move roles, agents gain tools, service accounts persist past their projects. This checklist covers the periodic review, drawn from FISTA Solutions' AI enablement governance work.

What is being reviewed?

Five access surfaces, each with a different failure mode.

Surface	Common failure
Human users	Moved roles, kept access
Service identities	Outlived the project
Agent capability	Grew without re-review
Retrieval scope	Ignores source permissions
Admin and configuration	Too many holders
Log and record access	Broader than the data itself

Human access

Start with the people, because role changes are the most common source of stale access.

• Current user list exported and reviewed by managers
• Departed staff removed and verified
• Role changes reflected in permissions
• Access levels justified against current responsibilities
• Accounts with no activity in the period flagged for removal
• Elevated and administrative access separately justified
• Shared logins identified and eliminated

Service identities

Long-lived, broad, and frequently unowned.

• Every service account has a named owner
• Every service account maps to a current system
• Accounts for retired projects disabled
• Permissions scoped to what the service actually calls
• Credentials rotated on schedule
• Credential use monitored for unexpected sources
• Accounts shared between systems separated

Agent capability

Recertify the list against the documented scope. See agent permission review checklist.

• Each agent's current tool list compared against its approved scope
• Capabilities added since the last review justified
• Unused tools removed
• Limits still appropriate for current volume and value
• Delegation relationships reviewed
• Agent service identities included in the service account review
• Owner confirmed and still in post

Retrieval and data scope

The gap most specific to AI systems.

• Source document permissions reflected in retrieval results
• Permission filtering tested per role, not assumed
• Newly indexed sources checked for restricted content
• Personal and sensitive data categories identified in the corpus
• Access to the corpus itself reviewed separately from the interface
• Embedding stores treated as containing the source content
• Cross-tenant isolation verified where applicable

Logs and records

Logs frequently contain the data they describe.

• Access to interaction logs restricted appropriately
• Log access is not broader than access to the underlying data
• Audit log access is itself logged
• Retention enforced rather than accumulating indefinitely
• Exported log copies tracked and controlled
• Redaction verified on a sample of records
• Analytics and monitoring tool access reviewed

Process

The review only works if removal actually happens.

• Review is scheduled, not triggered by an incident
• Reviewers are managers who know what people do
• Default is removal where justification is not provided
• Removals executed and verified, not just recorded
• Exceptions documented with an owner and an expiry
• Findings tracked to closure
• Review completion recorded with a date

What are the most common failures?

Reviewing human access only. Service accounts with no owner. Retrieval that ignores source permissions. Recording decisions without executing removals. And annual cadence on systems holding customer data.

Who should own this?

Security defines the process; managers review their own people's access; system owners review service identities and agents. A review run entirely by security without manager input approves everything.

How often should it run?

Quarterly for systems handling customer or sensitive data, semi-annually for internal tools, and immediately on departure or role change. Agent capability should also be reviewed on any scope change.

What evidence should it produce?

Dated review records with reviewer names, the list of removals executed, and exception approvals with expiry dates. That is what an auditor asks for and what proves the review happened.

What about access granted for a migration or incident?

Temporary access is the category most likely to become permanent. Grant it with an expiry, and verify removal afterwards rather than trusting the intention.

A standing list of temporary grants, reviewed weekly during any project that needs them, is a small piece of process that prevents a recurring finding. See AI data migration checklist.

What should you do first?

Export the list of service accounts touching your AI systems and find one without a named owner. There is usually at least one, and it is usually over-permissioned.

How FISTA Solutions helps

FISTA Solutions builds and operates production AI systems through AI agents, AI enablement, and forward deployed engineering: access recertified on a schedule with removal as the default, and retrieval permissions tested per role rather than assumed to match the source, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To adapt this checklist to your environment, message FISTA on WhatsApp, or read agent permission review checklist.