AI in Identity Governance Guide: Access Recommendations, Outlier Detection and Their Limits

Identity governance platforms now attach machine learning recommendations and outlier scores to almost every access decision, and reviewers increasingly accept them without knowing what they are based on. These features can cut certification fatigue and surface risky access that manual reviews miss, but they learn from the access you already have, so they can just as easily confirm historical over-provisioning. This guide explains how peer-based recommendations, outlier detection and AI review agents work, what signals they use, where they fail, and how to configure, test and measure them so that they strengthen rather than replace human judgement. It is written for identity governance owners, IAM architects and auditors who are switching these features on or relying on their output.

Key takeaways

• Peers are the baseline. Most IGA recommendations compare an identity's access with a peer group defined by shared entitlements or reporting lines, so they detect what is unusual, not what is wrong.
• History can launder over-provisioning. If a whole team holds excessive access, peer analysis will recommend keeping it, so recommendations need a clean role model and least privilege policy alongside them.
• Non-human identities fall outside the model. Service accounts, workload identities and AI agents have no manager, department or meaningful peer group, so they need rule-based review, not peer scoring.
• The reviewer still owns the decision. Vendor documentation describes recommendations as guidance; audit evidence must show reviewers examined them, not just clicked accept.
• Measure the model, not just the campaign. Track acceptance rate, override rate, revocations from outliers and re-grant rates to see whether the features improve outcomes.

What AI does in identity governance

AI features in identity governance and administration (IGA) cluster into four functions. Each answers a different question, and each needs different controls.

Role mining is a related use of the same clustering techniques, aimed at designing roles rather than reviewing them. See the Role Mining and Role Design Guide. For where these features sit in programme maturity, see the Identity Governance Maturity Model.

How peer-based recommendations work

Peer analysis rests on a simple assumption: people who do similar work hold similar access. The platform builds peer groups, then measures how common each entitlement is within the group.

• Peer groups from entitlements: the model links identities that share many entitlements and groups densely connected identities together. This adapts to how work is really organised but inherits whatever access already exists.
• Peer groups from the org chart: the model measures distance between users in the reporting structure. It relies on accurate manager data from HR.
• Coverage thresholds: an entitlement held by most of the peer group is marked as expected; one that is rare or unique is flagged for review.
• Activity signals: last sign-in or last application activity adds evidence of whether access is used at all.
• Lifecycle signals: disabled accounts, leave dates and recent mover events indicate access that should change regardless of peers. See the Joiner-Mover-Leaver Guide.

Outlier detection inverts the question. Instead of scoring each entitlement, it scores each identity by how far its overall access differs from its nearest peers, then ranks identities so reviewers can start with the most unusual.

How two platforms document these features

Two platforms with detailed public documentation illustrate the mechanics; they are listed alphabetically, and neither the order nor the selection is a ranking or endorsement. Other IGA platforms also offer AI and machine learning features for recommendations and outlier detection, so apply the same questions to whichever platform you run. The details below come from each vendor's documentation as of November 2026 and change often, so confirm them against current documentation before configuring.

Microsoft Entra ID Governance

• Inactive user recommendation: a user who has not signed in to the tenant in the last 30 days is marked inactive and receives a Deny recommendation; application assignment reviews use the user's last activity in the application. The sign-in date is evaluated once, when the review starts.
• User-to-group affiliation: a machine learning recommendation that computes each user's average distance from other group members in the reporting structure. Users a statistically significant distance away are flagged as low affiliation with a Deny recommendation. Users need a manager attribute, and groups of more than 600 users are outside its scope.
• Configuration: the review creator turns these on as decision helpers when creating the review; reviewers then see the recommendation and last sign-in date.
• Access Review Agent (Preview): scans active reviews and produces an approve or deny recommendation with a justification, scored deterministically from inactivity, user-to-group affiliation, the accountEnabled and employeeLeaveDateTime properties, mover workflows in the past 30 days, previous review decisions and access request history. Reviewers interact through Microsoft Teams, and the reviewer makes the final decision. Setup uses the Identity Governance Administrator, Lifecycle Workflows Administrator and Security Copilot Contributor roles, and the documentation notes that a started run cannot be stopped or paused.
• Availability: user-to-group affiliation and inactive user reviews require a Microsoft Entra ID Governance licence; the Access Review Agent requires Microsoft Entra ID Governance or Microsoft Entra Suite plus Security Copilot with at least one security compute unit.

SailPoint Identity Security Cloud

• Peer groups: a machine learning model maps identity-to-identity similarity based on shared entitlements and groups densely connected identities into peer groups, refreshed as data changes.
• Certification recommendations: a check icon means more than 70% of the peer group holds the access; a thumbs-down icon means the access is unique or held by 70% or fewer of peers; no icon means the identity has no meaningful peer group. The documentation states that recommendations are provided only as guidance.
• Request recommendations: up to 15 suggested items per user; access common across the organisation is generally not suggested unless the user is a joiner (45 days after creation by default), and rare or non-requestable access is excluded.
• Identity Outliers: identities whose access differs markedly from peers receive a 0 to 100 score, with factors such as Peer Access Similarity, Standalone Entitlements, Rare Access (entitlements held by under 1% of identities), Roles with a Single Entitlement, Entitlement Count and Access Profile and Role Uniqueness. Actions include Ignore, Unignore, Certify (a pre-filled campaign of up to 1,000 outliers) and CSV export.
• Configuration: certification recommendations are on by default; they are toggled per campaign with "Include Recommendations in your campaign" or globally with "Enable Certification Recommendations".
• Availability: recommendations require Access Recommendations and outliers require Access Insights (plus Certifications to launch campaigns); the documentation lists the AWS me-central-1 region as outside availability.

The limits: where AI recommendations mislead

The deeper problem is that a recommendation engine can only say "this is unusual"; it cannot say "this violates policy" unless policy is encoded somewhere. An organisation that has never defined who should hold what will get recommendations that faithfully reproduce who does hold what.

Where identity fits: non-human identities and AI agents

Peer and org-chart models are built for workforce users. Service accounts, workload identities, API keys and AI agents have no manager, no department and often no sign-in event in the interactive sense, so they either receive no recommendation or a misleading one. Microsoft's user-to-group affiliation, for example, needs users with a manager attribute.

• Use ownership instead of peers: every non-human identity needs a named human owner who certifies its access. See How to Run an Access Review for Service Accounts.
• Use usage evidence instead of sign-ins: compare granted permissions with permissions exercised in cloud and application logs over a fixed window.
• Govern AI agents as identities: agents need their own identity, scoped permissions and recertification. See Agent Identity Recertification.
• Treat AI review agents as privileged: an agent that reads every access review and lifecycle record holds sensitive data and influences access decisions; review its role assignments and who can configure it like any other governance administrator.

How to roll out AI features safely

1. Baseline first: record current campaign metrics (revocation rate, completion time, items per reviewer) so you can measure change.
2. Fix the inputs: check HR manager and department completeness, application activity feeds and entitlement descriptions. Recommendations built on gaps will be wrong.
3. Shadow mode: run one campaign cycle with recommendations visible only to the governance team, then compare them with reviewer decisions and with what a sample of entitlement owners says is correct.
4. Pilot with trained reviewers: enable recommendations for a limited set of applications and reviewers who understand what the signals mean.
5. Keep privileged and SoD reviews separate: do not let peer scoring drive decisions on admin rights or conflicting entitlements.
6. Use outliers to target, not to decide: launch focused certifications from outlier lists and require owner evidence for anything kept.
7. Roll back cleanly: because these features are toggles per review or campaign, document how to disable them and restore manual-only reviews if quality falls.
8. Document for audit: record which features were on, their configuration and their version for each campaign.

Decision guidance

• Small organisations: with few users per team, peer groups are thin. Inactivity and lifecycle signals deliver most of the value; outlier scoring adds little.
• Large organisations: peer analysis and outlier ranking pay off most where thousands of users share roles, provided HR data is clean.
• Regulated environments: keep human decisions explicit and logged; auditors will ask whether reviewers relied on AI and how its accuracy was checked. Map the model risk process to the NIST AI RMF Guide.
• AI review agents: start with agents that recommend and explain, never ones that apply decisions, and treat their output as one input to the reviewer.

Detection and measurement

• Recommendation acceptance rate: share of items where reviewers followed the recommendation. Near 100% with very short review time suggests automation bias.
• Revocations from recommendations and outliers: access removed because of a Deny recommendation or an outlier campaign, per cycle.
• Re-grant rate: revoked access requested back within 30 days. A high rate means recommendations are removing needed access.
• No-peer-group share: percentage of identities with no meaningful peer group; these need owner-based review.
• HR attribute completeness: percentage of workforce identities with a valid manager and department.
• Outlier closure time: median days from an identity appearing as an outlier to a certified or remediated state.

Log reviewer decisions with the recommendation shown at the time, so that decisions can be reconstructed during audits and incident investigations. See the Access Reviews Guide.

Framework mapping

Common failure patterns

• Turning on recommendations to speed up a late campaign: reviewers under deadline accept every recommendation, and the campaign closes with no real review.
• Trusting "keep" recommendations on admin access: privileged rights held by a whole platform team look normal to the peer model and are never challenged.
• Ignoring outliers until they disappear: the Ignore action hides an identity until its entitlements change significantly, which can mean indefinitely.
• Running peer analysis over service accounts: non-human identities receive no or misleading recommendations and are approved by default.
• No record of what the AI recommended: auditors cannot tell whether a decision was human judgement or acceptance of a model output.
• Garbage HR data: missing managers silently degrade affiliation scores and peer groups, and nobody measures it.

Practitioner checklist

• Inventory every AI or machine learning feature enabled in your IGA platform and record its configuration per campaign.
• Measure HR manager and department completeness before enabling org-chart or peer recommendations.
• Run one shadow cycle and compare recommendations with owner-validated decisions.
• Keep privileged access and segregation of duties reviews outside peer-based recommendations.
• Route non-human identities and AI agents to owner-based reviews with usage evidence.
• Use outlier lists to launch targeted certifications and require evidence for any access kept.
• Review the roles and permissions of any AI review agent as governance administrator access.
• Track acceptance, re-grant and no-peer-group rates each cycle.
• Store the recommendation shown alongside each reviewer decision for audit.
• Document how to disable each feature and revert to manual review.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• NIST: AI Risk Management Framework
• Microsoft Learn: Review recommendations for access reviews
• Microsoft Learn: Explore the Access Review Agent in Microsoft Entra
• SailPoint: Access Recommendations
• SailPoint: Identity Outliers

Related NHI Mgmt Group resources: Identity Governance Maturity Model · Access Reviews Guide · Role Mining and Role Design Guide · IGA Buyer's Guide