Access Recertification Agents for Periodic User Reviews
An access recertification agent should assemble evidence packets and route keep-or-revoke decisions, not remove entitlements on its own.
Direct Answer
Recertification is a review packet, not an auto-revoke job.
Access recertification agents help identity, application-owner, and audit teams complete periodic user access reviews by gathering current entitlements, usage signals, and role context into a keep-or-revoke packet. The agent should prepare the decision and route it. It should not disable accounts, drop group memberships, or change privileged roles unless a named owner has already approved that action and the identity platform can apply it.
That distinction matters because a recertification campaign looks like a checkbox exercise until someone has to explain a leftover privileged role, an unused finance application assignment, or a guest who still sits in a business-critical group. The operating problem is not writing another reminder email. It is making each line item inspectable: what access exists, why it was granted, whether it is still used, who can decide, and what happens if the reviewer does nothing.
Our bias is to treat the campaign as a workflow with a snapshot, a reviewer, an apply step, and a repair path. Identity platforms can already send review notices. The agent is useful only when it reduces reconstruction work without hiding the decision.
Old Pattern
Most campaigns export a roster and hope managers remember the job.
The familiar recertification cycle starts late. Identity governance exports group members, application assignments, or privileged roles into a spreadsheet. Managers receive a list with little context. Application owners get a larger list. Audit asks for evidence that the review happened. People approve rows they cannot explain so the campaign can close.
That pattern creates three costs. Reviewers reopen HR, the ticketing system, the identity platform, and last-login reports to reconstruct each line. Rubber-stamp approvals leave standing access that later shows up as an audit finding. Missed reviews either stall the campaign or silently follow a default decision nobody can later defend.
A roster is not evidence
A user name and an entitlement label do not tell the reviewer whether the access still matches the current role, manager, contractor status, or business need.
A reminder is not a decision record
Email completion rates do not show what the reviewer saw, which fields were stale, or why keep was chosen over revoke.
A closed campaign is not a control
If denied access was never applied, or nested-group membership left the user in place, the campaign closed while the entitlement remained live.
Packet Shape
Give every entitlement line six fields the reviewer can act on.
The first useful agent version does not try to own the identity platform. It prepares one packet per review line, in the same language the application owner or manager already uses. Keep the packet small enough to finish in a sitting and specific enough that audit can replay the decision later.
Entitlement
Name the account, group, application assignment, access package, or privileged role in the language of the system of record, and include the exact object identifier.
Current identity context
Show the worker type, manager, department, employment status, contractor end date, and whether this is a human, guest, shared, or service account.
Grant basis
Record how the access arrived: approved request, role template, nested group, exception list, break-glass process, or unknown origin.
Usage and freshness
Attach last-used, last-authenticated, or last-ticket evidence with timestamps. Mark the line stale when the identity snapshot, HR record, or usage source is older than the campaign window.
Recommended action
Propose keep, revoke, expire, or escalate, with a short rule: unused beyond policy, role change, contractor end date, segregation-of-duties conflict, or missing owner.
Apply and repair note
State who applies a revoke, whether the identity platform can execute it, what nested or synced groups will block the change, and how to restore access if the revoke was wrong.
Example
A finance ERP campaign needs a different packet than a privileged-role campaign.
Consider a quarterly recertification for a finance ERP. Application owners review who can post journals, approve vendors, or export customer payment files. The agent should read the identity assignment, the last successful login or transaction, the related access-request ticket if one exists, and the current HR role. A keep recommendation is reasonable when the user is still in the finance posting role and used the system inside the review window. A revoke recommendation is reasonable when the user moved to FP&A, the contractor end date passed, or the assignment exists only through a nested group nobody can explain.
A privileged-role campaign is narrower and stricter. The packet should show the exact role, standing versus time-bound assignment, last elevation, ticket that justified the grant, and whether a guest or shared account is involved. The agent can draft a revoke or convert-to-just-in-time recommendation. A human owner still has to approve any change that removes Global Administrator, privileged ERP access, or production break-glass rights.
This is a different workflow from access-request intake. Request agents help a joiner get into a system. Recertification agents help an owner decide whether standing access should remain. The earlier helpdesk notes at https://solzero.com/blog/it-helpdesk-agents-for-access-requests cover the inbound request. This campaign is the later control that catches privilege that outlived the original need.
Implementation
Sequence the campaign as read, classify, draft, route, then apply.
Start with one application or one privileged-role set that already has a named owner and a defined review cadence. Do not begin with every group in the directory. The first value is a packet the owner can finish without rebuilding the case by hand.
The permission inventory at https://solzero.com/blog/tool-permission-inventory-before-agent-launch still applies. Recertification tools should begin as read and draft. Routing can come next. Apply stays behind approval, especially for privileged roles, payment systems, production infrastructure, and any revoke that the identity platform cannot reverse cleanly.
Read the campaign snapshot
Freeze the review set at campaign start: users, entitlements, reviewers, and source timestamps. Identity platforms often review a snapshot rather than a live moving roster, so later HR or group changes belong in the next instance unless policy says otherwise.
Classify each line
Separate standard application access, privileged roles, guest access, service accounts, exception lists, and nested-group membership. Each class needs a different reviewer and a different stop rule.
Draft the keep-or-revoke packet
Write the six fields in the owner's existing review format. Prefer source links and identifiers over a narrative summary.
Route to the accountable owner
Managers can confirm business need for ordinary application access. Application owners confirm system entitlements. Privileged-role owners confirm standing admin access. Audit receives the completed packet, not a new research assignment.
Apply only after an explicit decision
Keep apply in the identity platform or ticketing system. The agent may create the revoke task after approval. It should not infer approval from silence unless the campaign policy already defines that default and records it on the packet.
Controls
Write the campaign rules before connecting revoke tools.
Current agent frameworks can pause a run, store the pending action, and resume after a human decision. That is useful for a revoke tool. It is not a substitute for campaign policy. The approval-packet pattern at https://solzero.com/blog/approval-packets-for-human-in-the-loop-agents is the review surface; the recertification campaign still has to say what a missed deadline means.
Identity platforms already expose some of these rules. Microsoft Entra access reviews, for example, capture a snapshot when an instance starts, apply reviewer decisions at the scheduled end date, and can auto-apply a configured default when a reviewer misses the deadline. Those behaviors are operating facts. The agent should surface them, not hide them inside a generated recommendation.
Snapshot versus live roster
Tell reviewers whether the packet reflects campaign-start membership or later changes. A role change that happens mid-window should either create an exception line or wait for the next instance.
Default decision on silence
Decide in writing whether unanswered lines keep access, revoke access, follow the platform recommendation, or escalate. Do not let an agent invent a default during the last day of the campaign.
Apply failures
Treat synced on-premises groups, nested group membership, mail-enabled groups, and application assignments that inherit from another group as blocked apply cases. Route those lines to identity engineering instead of reporting the campaign as complete.
Privileged and irreversible actions
Require named approval before any revoke that affects privileged roles, shared accounts, break-glass access, or systems that post money, change customer records, or alter production controls.
Scoreboard
Measure leftover access, not reminder volume.
A recertification agent is working when owners finish campaigns with fewer reconstructed cases and when denied access actually disappears from the system of record. Useful measures include lines decided from the packet without extra research, reviewer edits to the recommended action, stale-source hits, apply failures, leftover privileged entitlements after the end date, and time from decision to revoke.
Do not treat campaign completion percentage as the win by itself. A 100 percent complete review with unchanged privileged access is a reporting success and a control failure.
The SolZero take is that access recertification is one of the better early identity-governance agents because the workflow already has owners, a cadence, and an audit consumer. The first version should make each keep-or-revoke decision cheaper to finish and easier to replay. If you want a workflow review for a campaign that already slows down every quarter, the operating sequence is at https://solzero.com/#how-it-works.
FAQ
Two questions operators ask before the first campaign.
Should the agent revoke unused access automatically?
Not in the first version. Unused is a signal, not a decision. Service accounts, break-glass roles, and seasonal finance access can look unused and still be required. Let the agent recommend revoke, require a named owner, then apply through the identity platform.
Is this the same as automating access requests?
No. Access requests grant new access. Recertification asks whether standing access should remain. Combining both jobs in one agent usually blurs the approval class: a grant needs a business justification, and a revoke needs an apply-and-repair path.
Further reading