An AI access review agent should assemble current identity and entitlement evidence, surface a recommendation, route the decision to an accountable owner and reconcile the applied result. It should not certify access, accept its own recommendation or call a submitted review an entitlement change. Start with one application, group or access package and measure cost per reconciled decision.
An access review has three different facts that often get collapsed:
- a reviewer submitted a decision;
- the review closed and its results became eligible for application;
- the authoritative identity system now reflects the intended access state.
An agent can help join evidence across those facts. It must preserve the boundary between them.
This worksheet scopes one recurring review lane for an identity-governance, IT security or platform owner. It is vendor-neutral at the workflow level. Microsoft Entra supplies one concrete provider example because its current documentation makes the timing and terminal-state traps explicit. Replace those provider fields with the semantics of your own identity system before release.
Start with one review unit
The pilot unit is one review instance for one managed resource: an application, group or access package. Do not start with every identity and entitlement in the company.
A review packet should bind:
- review ID, start time, close time and recurrence;
- resource ID and accountable resource owner;
- identity ID and current employment or workload state;
- assignment path, including direct, group, nested group or synchronized source;
- current entitlement and the policy criteria that permit it;
- snapshot timestamp and data-source versions;
- authorized reviewer ID and reviewer role;
- recommendation, its source fields and its limitations;
- submitted human decision and reason;
- result-application mode, automatic or manual;
- authoritative read-back and its timestamp;
- policy version, operator, recovery owner and evidence retention.
This is deliberately more than an identity row plus a model judgment. The packet must show why this reviewer may decide this entitlement under this policy from this snapshot.
NIST SP 800-53 Rev. 5 AC-2 asks organizations to define allowed account types, assign account managers, specify authorized users, group and role membership and access authorizations, monitor account use, align account management with personnel changes and review accounts at an organization-defined frequency. It permits automated mechanisms, but the organization still supplies the policy, criteria and appropriate authorities.
That is the operating boundary for the agent: automation assembles and routes evidence inside a customer-owned account-management policy. It does not invent the policy or the authority.
Use the evidence packet before the recommendation
The minimum packet can be implemented as a versioned object:
{
"review_id": "review-2026-q4",
"resource": {
"id": "finance-reporting",
"owner_id": "owner-7",
"assignment_path": "direct-assignment"
},
"identity": {
"id": "identity-42",
"status_source": "hr-system",
"status_observed_at": "2026-10-17T00:00:00Z"
},
"entitlement": {
"name": "report-reader",
"current_access": true,
"policy_version": "access-review-v4"
},
"reviewer": {
"id": "owner-7",
"authorized": true
},
"recommendation": {
"value": "deny",
"basis": ["no-observed-use", "employment-status-current"],
"generated_at": "2026-10-17T00:05:00Z"
},
"human_decision": null,
"application": null,
"readback": null,
"recovery_owner": "identity-operations"
}The values are illustrative. The important fields are the assignment path, source times, policy version, authorized reviewer and separation between recommendation, human decision, application and read-back.
Do not place a recommendation above missing evidence. If the system cannot identify the resource owner or entitlement path, the correct terminal is MISSING_EVIDENCE, not a low-confidence approval or denial. A confidence score does not repair an absent authority chain.
The same rule applies to agent identities and service accounts. They need a responsible owner, intended system usage, current privileges and a review policy. NIST lists system and service-style account categories inside account management. It does not imply that a model can approve its own continuing access.

Keep recommendations advisory
Recommendations can order the review queue. They cannot become the accountable decision without a customer policy explicitly assigning that authority.
Microsoft's current access-review instructions let an assigned reviewer approve, deny or choose Don't know. A Don't know decision maintains access and is written to audit logs. A reviewer can change a decision before the review ends, and when there are multiple reviewers the last submitted response is recorded.
The same documentation says system-generated recommendations are based on sign-in activity. A reviewer still submits acceptance. That creates a clear implementation rule:
The agent may produce and explain a recommendation. Only the configured reviewer or policy produces the decision.
Usage is one evidence source, not the whole authorization. A user may need rarely used emergency access. A workload may run only at quarter-end. A contractor may show recent use after the work ended. A dormant direct assignment and a dormant nested-group assignment also have different removal paths.
The reviewer surface should show:
- current access and assignment path;
- identity and resource owner;
- policy criteria and review deadline;
- evidence sources with timestamps;
- the recommendation and its basis;
- approve, deny and hold or don't-know actions;
- the effect that will occur after submission;
- whether application is automatic, manual or unsupported for this path.
Do not hide a provider default behind the model. Microsoft's access-review FAQ says an administrator can configure what happens when a reviewer misses the deadline, including approve, deny or take recommendations. That is a policy field. Record it before the review starts, expose it to the owner and report when it acted.
Treat the review as a snapshot
Evidence freshness is part of the decision. Microsoft says an access-review instance captures access at the start of the review. Changes to assignments, group membership or reviewer configuration during the review are not reflected until a later recurring instance.
The agent should therefore retain snapshot_at and compare high-risk fields before the owner acts:
- Did employment or workload status change?
- Did the resource owner change?
- Did the assignment path change?
- Did the entitlement policy change?
- Was the access already removed or expanded elsewhere?
- Did a different reviewer submit a later decision?
Do not silently rewrite the original packet. Mark the original snapshot as superseded and route a refreshed packet or owner handoff. That preserves why a decision was made while preventing stale evidence from masquerading as current state.
For privileged access, set a shorter freshness budget and require the policy owner to define it. NIST AC-2 calls for additional scrutiny around administrative privileges by accountable organizational personnel. The resource should not prescribe a universal number of hours or days because review cadence and evidence freshness belong to the organization's risk and account-management policy.
Separate decision, application and read-back
A submitted denial is not revoked access. Microsoft's documentation says a denied user is not removed from an access package immediately. The result is applied after the review closes. Auto-apply and manual apply are separate configurations.
Some paths may not be directly manageable by the review system. Microsoft names synchronized on-premises groups, nested-group relationships, missing users, mail-enabled groups and applications assigned through group relationships as examples where a denied result may not remove access as expected.
The workflow needs distinct terminals:
| Terminal | Meaning | Next owner action |
|---|---|---|
MISSING_EVIDENCE | Required identity, resource, path, policy or reviewer evidence is absent | Evidence owner repairs packet |
BLOCKED | Reviewer or policy lacks authority, or the submitted decision is invalid | Identity-governance owner resolves authority |
OWNER_HANDOFF | Ownership changed or conflicts with the review snapshot | Current owner receives a refreshed packet |
OWNER_REVIEW | Packet and recommendation are ready, but no human decision exists | Authorized reviewer decides |
HOLD | Reviewer chose don't know or needs more evidence | Named evidence or risk owner responds |
DECIDED_PENDING_CLOSE | Approve or deny was submitted while the review remains open | Observe close or changed decision |
PENDING_APPLY | Review closed but result is not yet applied | Provider or manual-application owner acts |
UNCERTAIN | Application was requested but authoritative read-back is missing | Reconcile before retry |
DIVERGENT | Authoritative access disagrees with the expected state | Incident or exception owner investigates |
RECONCILED | Applied state matches the accountable decision | Retain receipt and close this record |
These are workflow terminals, not risk grades. RECONCILED says the provider state matches the decision. It does not certify that the decision was legally required, perfectly informed or safe forever.

Test the terminal model
The dependency-free reference classifier for this worksheet passed twenty-one synthetic cases. Eighteen exercise the route contract: missing review and assignment evidence, unauthorized reviewer, policy refusal, ownership conflict, reviewer change, advisory recommendation, don't-know, invalid decision, approve and deny before close, manual application, missing read-back, divergence and reconciled approval or denial. Three exercise the cost model, including a zero denominator.
The test result is 21/21. It proves the reference functions match the contract. It does not prove an identity provider integration, entitlement accuracy, reviewer quality, control compliance or customer outcome.
The core transition is small:
if (requiredEvidenceMissing) return "MISSING_EVIDENCE";
if (!reviewerAuthorized || !policyAllowsReview) return "BLOCKED";
if (ownerStateChanged) return "OWNER_HANDOFF";
if (!humanDecisionSubmitted) return "OWNER_REVIEW";
if (decision === "dont_know") return "HOLD";
if (!reviewClosed) return "DECIDED_PENDING_CLOSE";
if (!resultApplied) return "PENDING_APPLY";
if (!readbackObserved) return "UNCERTAIN";
if (authoritativeAccess !== expectedAccess) return "DIVERGENT";
return "RECONCILED";The implementation should bind every transition to a review ID, identity ID, resource ID, entitlement path, policy version, reviewer, decision timestamp and source version. Re-evaluate when any of them changes.
Do not blindly repeat an uncertain denial or removal. First read the authoritative assignment graph. A timeout can hide a completed change, and the same identity may retain access through another group or role.
Fill the cost worksheet
Measure cost per reconciled entitlement decision, not per identity row processed or recommendation generated.
Use your own monthly inputs:
| Cost input | Enter value | What belongs here |
|---|---|---|
| Identity or governance platform | Enter value | Incremental license and usage cost for the review lane |
| Evidence maintenance | Enter value | Owner maps, entitlement catalog and source repair |
| Integration operations | Enter value | Connector, queue, monitoring and incident cost |
| Amortized setup | Enter value | Initial build divided by chosen months |
| Reviewer time | Enter minutes, count and loaded rate | Time spent on normal owner decisions |
| Exception time | Enter minutes, count and loaded rate | Missing owner, don't-know and policy conflicts |
| Reconciliation time | Enter minutes, count and loaded rate | Manual apply, uncertainty and divergence work |
| Reconciled decisions | Enter value | Terminal decisions whose authoritative state matches |
Calculate:
monthly total = platform
+ evidence maintenance
+ integration operations
+ amortized setup
+ reviewer labor
+ exception labor
+ reconciliation labor
cost per reconciled decision = monthly total / reconciled decisionsDo not divide by recommendations or review rows. A workflow that produces 500 recommendations but leaves 50 unresolved or divergent has not delivered 500 accepted outcomes.
Synthetic arithmetic check
The retained test fixture is synthetic and exists only to prove the formula:
- platform: $600;
- evidence maintenance: $300;
- integration operations: $450;
- setup: $4,800 amortized across six months, or $800 monthly;
- 500 normal reviews at four minutes and $90 per hour, or $3,000;
- 30 exceptions at twenty minutes and $120 per hour, or $1,200;
- 50 reconciliations at five minutes and $84 per hour, or $350;
- 450 reconciled decisions.
The synthetic monthly total is $6,700. Dividing by 450 produces $14.89 per reconciled decision. These are not market prices, client results, savings or a forecast. Replace every value and compare the result with the current human process before funding the build.
Release the first review lane
Use a bounded rollout:
- Select one application, group or access package with a named business owner.
- Record the current account policy, reviewer roles, cadence, missed-reviewer default and application mode.
- Map direct, group, nested and synchronized entitlement paths.
- Freeze a review snapshot and retain source timestamps.
- Run the agent in evidence-only mode and compare packets with the current review process.
- Enable advisory recommendations with visible evidence, never silent acceptance.
- Require the authorized owner to submit approve, deny or hold.
- Observe review close separately from result application.
- Read back the authoritative entitlement graph and classify the terminal.
- Route unmanaged paths, uncertainty and divergence to named operators.
- Join reviewer time, exception time, reconciliation time and platform cost.
- Release only if the packet is current, the owner can refuse, every applied result has read-back and recovery has been tested.
The first canary should include both approve and deny outcomes, a don't-know case, one ownership change and one entitlement path that cannot be applied automatically. A workflow tested only on direct approvals has not exercised the expensive states.
The employee onboarding agent worksheet covers the joiner event. This resource covers recurring entitlement review after access already exists. Keep the two records linked, but do not assume a correct onboarding package proves current access remains justified.
AI access review agent FAQ
Can an AI agent approve an access review?
Use the agent to collect evidence and provide an advisory recommendation. The organization's account policy must name the authorized reviewer or automated authority. The reference workflow keeps human decision submission separate from the recommendation.
Does a denied access review remove access immediately?
Not necessarily. Microsoft Entra documents that denial is applied after the review closes, and some assignment paths cannot be removed directly. Observe provider application and authoritative read-back before calling access revoked.
What should happen when the reviewer chooses don't know?
Route the record to HOLD with a named evidence or risk owner. In Microsoft Entra's current behavior, Don't know maintains access and is written to the audit log.
Should an access review agent use sign-in activity?
Yes, as one timestamped evidence field. Do not let inactivity decide alone. Emergency roles, seasonal work, nested assignment paths and stale source data can make a usage-only recommendation wrong.
How should access review automation be measured?
Measure reconciled decisions, exception rate, reviewer time, application lag, uncertainty, divergence and cost per reconciled decision. Recommendation volume and rows processed are activity measures, not accepted outcomes.








