Enterprise AI permissions do not fail only at launch. They drift after launch.

The support agent gets a temporary CRM write scope for a pilot. The HR assistant inherits a broader document collection during migration. A service account remains active after a workflow is retired. A connector adds a new destructive action under an existing integration. Nobody sees the problem because the original security review was treated as a project milestone, not as a recurring control.

An access review for enterprise AI agents is the recurring process that proves each agent still needs each data source, tool action, delegated scope, memory store, model route, and approval bypass it can use. The review should not ask, “does this app still exist?” It should ask, “is this exact authority still justified by current business use, current evidence, current risk, and a named owner?”

This is where the control-plane work in AI governance architecture, Zero Trust for enterprise AI agents, safe tool registries, policy-as-code, agent audit logs, and the enterprise AI system registry becomes operational. Architecture defines the boundaries. Access reviews keep those boundaries from becoming stale.

The Review In One Paragraph

Review AI access at the entitlement level, not only at the application level. For every agent, record the human populations it serves, its workload identity, service accounts, delegated token scopes, data collections, retrieval indexes, memory stores, tool actions, approval exceptions, and audit obligations. Then require the business owner, data owner, tool owner, security owner, and platform owner to renew, reduce, revoke, or quarantine each entitlement on a risk-based cadence. The output is not a signed spreadsheet. It is an updated policy state, revoked credentials where needed, fresh evidence, and a test proving the agent can no longer use removed authority.

Why Normal Access Reviews Miss AI Risk

Traditional access reviews often inspect users, groups, roles, and applications. That is necessary, but it is too coarse for agentic systems.

An AI agent can combine permissions in ways a normal user interface does not expose. It can retrieve context from one system, reason over it, call a tool in another system, write a summary into a third system, and store a memory that influences later work. The risk is not only “can the app access Salesforce?” The risk is whether a specific agent, acting for a specific user population, in a specific workflow state, may read a specific data class and execute a specific tool action with a specific approval state.

The NIST SP 800-53 Rev. 5 control catalog is still useful because account management, access enforcement, least privilege, separation of duties, audit events, and periodic review remain the backbone. The difference is that AI systems need those controls applied to more actors and more runtime context:

If the review cannot see those dimensions, it cannot detect permission laundering: the agent appears legitimate because one credential is approved, while the combined workflow exceeds what anyone meant to authorize.

The Minimum Entitlement Record

Start with a record small enough to maintain, but precise enough to drive enforcement. Each AI entitlement should answer these questions:

This record should live beside the enterprise AI system registry, not in a disconnected audit folder. Registry state should influence policy. Policy decisions should produce audit events. Audit events should feed the next review.

Recertification Cadence Should Follow Authority

Do not review every agent entitlement on the same schedule. Low-risk read-only access to public documentation does not deserve the same ceremony as an agent that can update customer records, send external email, change IAM groups, approve refunds, or modify production infrastructure.

The cadence is only a default. The stronger rule is event-driven recertification. Review immediately when any of these change:

• the agent moves from pilot to production;
• a tool adds a new action or broader scope;
• a data source changes classification;
• a workflow gains autonomous write authority;
• a model route, RAG index, memory store, or prompt policy materially changes;
• an incident, near miss, prompt injection finding, or exfiltration attempt occurs;
• the business owner, data owner, or tool owner changes;
• the agent stops producing business value but credentials remain active.

NIST SP 800-207 on Zero Trust Architecture is useful framing here because it pushes authorization toward explicit, contextual, continuously evaluated access rather than static network trust. For AI agents, that means the review cadence is not a substitute for runtime enforcement. It is the governance loop that keeps runtime policy current.

ABAC Beats Role Names Alone

Role-based access control is easy to explain and painful to scale. It can still be useful, but AI agent authorization usually needs attributes.

The NIST guide to attribute-based access control is relevant because agent access decisions should consider subject attributes, object attributes, action attributes, and environmental attributes. In practical enterprise AI terms, the policy input should include:

• human user attributes: department, role, region, employment status, auth strength, tenant;
• agent attributes: system ID, workflow ID, risk tier, environment, lifecycle state;
• workload attributes: service account, client ID, credential age, token issuer, token scope;
• resource attributes: data class, source authority, owner, retention class, residency;
• action attributes: read, summarize, draft, write, send, delete, approve, deploy, escalate;
• workflow attributes: ticket state, approval state, exception state, incident mode;
• evidence attributes: last eval gate, last review date, recent deny events, open incidents.

The access review should not merely renew a role. It should renew the attribute contract that policy-as-code evaluates at runtime.

That is the practical link to policy-as-code for enterprise AI agents: the review produces policy inputs, and policy enforcement proves whether those inputs actually constrain behavior.

Delegated Tokens Need A Review Shape

Many enterprise agents will need to act with some form of delegation. The wrong pattern is handing the agent a broad user token or a shared service account and hoping prompt instructions keep it honest.

A better pattern is a token broker that issues short-lived, scoped, session-bound credentials after evaluating human identity, agent identity, workflow state, resource, tool action, approval state, and risk tier. The OAuth 2.0 Token Exchange standard, RFC 8693, is useful background because it formalizes exchanging one security token for another in delegated scenarios. The implementation details vary by identity provider and platform, but the design goal is the same: narrow credentials for narrow work.

Access reviews should inspect delegated authority through this lens:

The access review should catch every place a broad credential escaped the broker pattern.

SCIM And The Identity Lifecycle Matter

Agent permissions also drift when human identity changes are not propagated cleanly.

The SCIM protocol, RFC 7644, is not an AI standard; it is a provisioning standard. That is precisely why it matters. AI systems should consume the same identity lifecycle signals as the rest of the enterprise: user creation, deactivation, group changes, department moves, manager changes, and application assignments.

For agents, identity lifecycle controls need two extra checks:

This is where access review and decommissioning meet. A retired AI workflow should not leave behind a service account with useful scopes, an index full of restricted documents, and a memory store nobody owns.

The Evidence Packet

An access review should not rely on memory or confidence. It should have evidence.

For each high-risk entitlement, require a compact evidence packet:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

entitlement_id: ent-crm-refund-agent-update-case-status
system_id: ai-support-resolution-agent
agent_id: support-resolution-prod
environment: production
human_population: support_tier_2_emea
workload_identity: wi-support-resolution-prod
delegation_mode: brokered_user_context
resource: crm.case
allowed_actions:
  - read_case
  - draft_response
  - update_case_status
data_classes:
  - customer_confidential
tool_risk_tier: tier_3_bounded_write
business_justification: "Close duplicate support cases after policy and ownership checks."
required_approval: "human approval for customer-visible resolution notes"
last_eval_gate: evalgate-2026-08-29-support-resolution
last_policy_test: policytest-2026-09-10-crm-scope
last_audit_sample: trace-sample-2026-09-w36
incident_status: no_open_incidents
review_decision: renew_with_reduced_scope
scope_change:
  removed:
    - reopen_case
next_review: 2026-12-14
revocation_test: revtest-2026-09-14-reopen-case-denied
owners:
  business: support_operations
  data: customer_data_owner
  tool: crm_platform_owner
  security: application_security
  platform: ai_platform_team

The important part is not the YAML. It is the evidence link between business justification, runtime authority, test results, and owner decision.

Review Decisions Must Change Runtime State

There are only four useful outcomes from an AI access review:

Anything else is a note, not a control.

This is why reviews should write back into the system registry, policy engine, identity provider, token broker, tool registry, retrieval gateway, and audit configuration. If the review result lives only in a PDF, the agent runtime will keep doing whatever the old policy allowed.

Revocation Is A Test, Not A Ticket

The review is not complete until removal is verified.

For AI agents, revocation has more places to fail than in ordinary applications:

The OWASP AI Agent Security Cheat Sheet is a good practical reminder that least privilege, tool authorization, human oversight, monitoring, and adversarial testing belong in the agent architecture itself. An access review should therefore produce security tests, not only reviewer attestations.

Review The Denials Too

Useful access reviews inspect what was allowed and what was denied.

Denied events reveal attempted privilege escalation, prompt injection attempts, user confusion, missing business capabilities, broken policies, and stale ownership. A system with no deny events is not automatically safe. It may mean the policy is too permissive, logging is incomplete, or the agent never reaches the boundary because the model has learned to avoid asking.

Sample the last review period for:

• repeated attempts to call tools outside the agent’s tier;
• retrieval denies for restricted data classes;
• approval requests outside the usual workflow state;
• unexpected tenant, region, or department crossings;
• unusually broad token requests;
• user attempts to route around the agent’s intended process;
• actions denied during incident mode;
• denials that later became manual workarounds.

This is one reason agent audit logs should be structured. If the logs cannot reconstruct actor, agent, policy input, action, resource, decision, and evidence, the next access review becomes guesswork.

Ownership Model

AI access review fails when every team thinks another team owns the hard decision. Use split ownership:

One person can hold multiple roles in a small organization, but the questions should remain separate. “The product owner approved it” is not the same as “the data owner renewed restricted retrieval” or “security verified revocation.”

Practical Rollout

Start with the agents that can cause business effects. Read-only assistants matter, but write authority, external communication, privileged retrieval, and approval bypasses deserve attention first.

A workable first 60 days:

1. Export the AI system registry, tool registry, service accounts, delegated OAuth grants, retrieval indexes, memory stores, and production agents.
2. Create an entitlement record for every Tier 2, Tier 3, and Tier 4 permission.
3. Mark unknown owner, unknown justification, shared credential, no expiry, and no audit trace as review blockers.
4. Run the first review on one high-value workflow and one high-risk workflow.
5. Convert reviewer decisions into policy changes, credential changes, and registry updates.
6. Run revocation tests for every reduced or removed permission.
7. Add event-driven review triggers to release gates and incident response.
8. Put access review status into deployment readiness: expired high-risk entitlement means no production authority increase.

After that, automate the boring parts. Pull identity data from the identity provider, provisioning system, tool registry, policy engine, and audit logs. Let reviewers focus on judgment: whether the authority still makes sense.

The Design Rule

Do not ask whether an enterprise AI agent is “approved.” Ask whether each authority it still holds is current, owned, justified, evidenced, scoped, and revocable.

That sounds slower than a one-time launch review. In practice it is faster, because stale permissions stop accumulating. Teams can expand useful agents with less drama when every scope has an owner, expiry, evidence packet, and revocation test. The alternative is discovering six months later that the pilot agent became a production actor with yesterday’s business justification and last quarter’s credentials.

Access reviews are not paperwork for AI governance. They are the maintenance loop for agent authority.