# Access Review Assistant: An AI Agent for Least-Privilege Reviews

The Access Review Assistant is an AI agent that prepares least-privilege access reviews for the people and agent identities using a customer data platform (CDP). Security owners work from its output at propose level (L2): each grant, its last use and a keep-or-remove proposal. It has no ability to grant, revoke, merge or deploy, and it cannot approve its own scope.

The agent follows the [AI agent rails](https://privycdp.org/ai/rails) method and covers human accounts and machine identities in one list. The [compliance, privacy and security playbook](https://privycdp.org/ai/rails/functions/compliance-privacy-security) shows where it fits.

## Rail at a glance

The Access Review Assistant's rail gives it read-only access to identity data and no route to any write function. Changes happen in the identity system, under the security owner's own credential.

| Field | Value |
|---|---|
| Job | Prepare access reviews and propose removal of unused scopes for people and agents. |
| Trigger | A scheduled review cycle. |
| Data scope | Roles, agent identities, scope grants and scope usage logs. |
| Tool scope | Read: identity records, scope grants, usage logs; propose: a revocation and review list; execute: none, with no tool that can grant, revoke, merge or deploy. |
| Output contract | Each grant, last use, owner, and a keep-or-remove proposal with a reason. |
| Gate | The security owner decides every change. |
| Limits | Read-only access to identity data, and a budget per run. |
| Ledger | Review cycle, proposals, decisions, decider. |
| Evaluation | Seeded dormant and excessive grants. |
| Owner and kill switch | Security lead; an [Orchestrator](https://privycdp.org/ai/rails/orchestrator-agent) pause returns the review to manual work. |

## What it does and who uses it

The Access Review Assistant prepares the list a security owner would otherwise build by hand from several consoles. NIST SP 800-53 control AC-6(7) describes the practice: review privileges periodically, and change or remove those that no longer have a justification [2](#source-2).

These illustrative rows show the output, with grants listed by role or agent.

| Grant | Last use | Owner | Proposal | Reason |
|---|---|---|---|---|
| Marketing analyst role: audience export | Not in the 180-day log window | Head of marketing operations | Remove | Scope unused across the window; read access stays. |
| [Segment Drafter](https://privycdp.org/ai/rails/agents/segment-drafter): extra profile read | Never | Head of marketing operations | Remove | Not used since it was granted. |
| Emergency admin account | Over a year ago | Security lead | Keep, flag | Break-glass account, tagged exempt. |
| CRM connector token: full access | Last week | Platform lead | Review | In use, but wider than the calls logged. |

Native tools may already cover part of this. When checked on 1 November 2026, Microsoft Entra access reviews could recommend Deny for users with no sign-in in 30 days, fixing that date when the review begins [3](#source-3). AWS IAM Access Analyzer reports unused roles, access keys and permissions [4](#source-4). If your estate sits in one such system, start there. The assistant earns its place when people and agents span several systems.

## Why this level

The Access Review Assistant stays at propose level (L2) because a wrong change hurts in either direction. A wrong revocation can lock a team out or stop a pipeline, and undoing it may take longer than the outage allows. A wrong grant widens the blast radius for whoever later holds that credential.

The Rule of Two [1](#source-1) closes the question. Identity records and usage logs are sensitive, and they contain strings set elsewhere, such as token names and service descriptions, which count as untrusted. With both properties present, no state-changing tool is allowed. A write tool here would also be a prize: a hijacked session could give itself access or remove the security team's.

This rail never moves up. The agent's own scopes are excluded from its output by rule and reviewed by the security lead.

## Three ways it fails, and the control for each

Access reviews fail on the gap between what logs show and what the business needs.

| Failure | What it looks like | Control |
|---|---|---|
| Unused read as unneeded | Break-glass, year-end and disaster-recovery access look idle, and removal waits for the day they are needed. | Exempt tags set by the security owner. Each row shows the log window, and access older than the logs reads "no data", not "unused". |
| Blind spots in the inventory | OAuth tokens, connector accounts and local database roles sit outside the identity system, so the review looks complete. | Each review lists the sources it covered and the connectors it could not read. The [Salesloft Drift token theft](https://privycdp.org/ai/7-things-ai-agents-should-never-do-with-customer-data) shows why tokens belong in scope. |
| Review by habit | A tired owner accepts the whole list, or keeps everything to avoid complaints. | Privileged grants need a decision per grant, not bulk approval. Seeded excessive grants sit in each cycle, and results are summarised by rail and role. |

Usage logs show what individuals do at work, so keep this rail away from performance questions. Annex III point 4(b) of the EU AI Act lists monitoring and evaluating workers' performance and behaviour among high-risk uses [5](#source-5). Report last use per grant, never rank people by activity, and take advice before using these logs for anything else.

## How to evaluate it

An access review agent is doing well when real excess goes away and little has to be given back. Run seeded grants through each cycle, and track what owners decide.

- **Catch rate on seeded grants,** including dormant agent identities as well as human accounts.
- **Unused scopes removed,** counted after the owner's decision, not when proposed.
- **Review completion time,** from cycle start to the last decision.
- **Re-grant rate.** Scopes requested back soon after removal mark proposals that missed a real need.
- **Coverage,** the share of known connectors and token stores read in the cycle.

## Where it runs

Identity data maps who can reach what, which makes it valuable to an attacker even without customer records. Prefer a private model, and let anything external see it only with masking and contract cover; the [boundary architecture patterns](https://privycdp.org/ai/ai-agents-on-customer-data-inside-your-boundary) describe the gateway. [PrivyCDP](https://privycdp.org/cdp) sets limits on data access for its AI-assisted features, while this assistant remains a pattern for your security team to define.

## Related

- [AI agents for compliance, privacy and security teams](https://privycdp.org/ai/rails/functions/compliance-privacy-security): the security side of the function.
- [Policy Drift Checker](https://privycdp.org/ai/rails/agents/policy-drift-checker): tests whether agents keep to the scopes on their cards.
- [Connector Change Reviewer](https://privycdp.org/ai/rails/agents/connector-change-reviewer): catches wider scopes before they merge.
- [Rail card template](https://privycdp.org/tools/agent-rail-card): the tool scope field gives this review its baseline.


Related agents sit in the [AI agent rails hub](https://privycdp.org/ai/rails). Every agent identity needs a written scope to review against, and the [rail card template](https://privycdp.org/tools/agent-rail-card) provides one.

Rail level: L2 · Risk: medium · Function: compliance privacy security

By Art Kukharenko
Published: 2026-11-02
Updated: 2026-11-02

## FAQ

### Can an AI agent approve or revoke access?

No. It prepares the list and proposes removals, and the security owner decides each change in the identity system. It holds no tool that could grant or revoke, so a hijacked session cannot alter access.

### Should AI agents be included in access reviews?

Yes. An agent identity holds scopes and tokens just as a person does, and its needs change when a rail changes. Review each one against its current job, and give it a named owner.

### Does an access review count as monitoring staff?

It can drift that way, since usage logs record what people do. Limit the output to last use per grant, avoid activity rankings, and take advice on how your jurisdiction treats these logs.

## Sources

1. Meta, Agents Rule of Two, for sessions reading identity data: https://ai.meta.com/blog/practical-ai-agent-security/
2. NIST SP 800-53 Rev. 5, AC-6(7), reprint: https://csf.tools/reference/nist-sp-800-53/r5/ac/ac-6/ac-6-7/
3. Microsoft, review recommendations for Entra access reviews: https://learn.microsoft.com/en-us/entra/id-governance/review-recommendations-access-reviews
4. AWS, IAM Access Analyzer findings: https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html
5. EU AI Act Annex III: https://artificialintelligenceact.eu/annex/3/

This article is general information, not legal advice.

## Further reading

- [AI Agent Permission Matrix: Who May Read, Propose and Execute](https://privycdp.org/tools/agent-permission-matrix)
- [AI Agents for Compliance, Privacy and Security Teams: The Playbook on Rails](https://privycdp.org/ai/rails/functions/compliance-privacy-security)
- [DSAR Assembler: An AI Agent That Prepares Access Request Packs](https://privycdp.org/ai/rails/agents/dsar-assembler)
- [Evidence Packer: An AI Agent That Assembles Audit Evidence](https://privycdp.org/ai/rails/agents/evidence-packer)
- [AI Agent Rails: An Operating Model for Running Agents on Customer Data](https://privycdp.org/ai/rails)