Identity governance: AI-assisted access reviews & least privilege

Access accumulates: people change roles, projects end, service accounts and cloud roles are granted "just in case". Periodic access reviews exist to undo this, but reviewers face thousands of line items they do not understand and click "approve all". AI compares each identity with its peers, usage and policy, ranks what is unusual or toxic, recommends approve or revoke with a short reason, and proposes cleaner roles. The aim is fewer rubber-stamped campaigns and a measurable drop in standing privilege.

Problem & value

• Today: quarterly or annual recertification campaigns by manager or application owner, spreadsheets for ERP/legacy systems, role models built in workshops that decay within a year. Joiner-mover-leaver processes add access but rarely remove it ("privilege creep"). Non-human identities (service accounts, API keys, workload identities, increasingly AI agents) are often unowned.
• AI value: (1) reviewers see a risk-ranked list with a justification instead of a flat list; (2) low-risk, high-confidence items can be auto-certified or batched; (3) data-driven role mining replaces workshops; (4) unused permissions are found from usage logs and removed; (5) SoD conflicts are detected before approval, not at audit.
• Evidence: auditors (ISO 27001, SOX, DORA, NIS2 supervisors) ask for proof of regular, effective access reviews. Vendors report large reductions in review effort, but published figures are marketing claims; measure your own baseline.

Variants

• SMB: Microsoft 365 / Entra reviews of groups, Teams and guest users, with inactivity scoping; a handful of SaaS apps. Often no role mining needed.
• Enterprise / regulated (banking, insurance, public sector): full IGA suite with SAP/ERP SoD, privileged-access integration and board-level attestation.
• Cloud engineering teams: CIEM-style right-sizing of AWS/Azure/GCP roles from usage data.
• Non-human and agent identities: ownership, rotation and scope review of service principals, tokens and AI-agent credentials (see SEC-013).
• Public sector: works-council and data-protection-officer involvement; recertification of citizen-data system access.

How it works

1. HR source + connectors (AD/Entra, SaaS, ERP, DB, cloud IAM)
2. identity & entitlement graph (who has what, via which group/role)
3. usage enrichment (last use, unused permissions, sign-in logs)
4. analytics: peer-group outliers, role mining, SoD/toxic rules, risk scoring
5. recommendation per item (approve / revoke / review) + LLM-written justification
6. campaign: reviewer decision (human)
7. provisioning/de-provisioning via connector or ticket
8. evidence store, feedback to models

• Peer-group analytics: clustering and association rules on identity-entitlement matrices (also graph methods) find entitlements held by few peers in the same department or job code; Entra's machine-learning recommendation, for example, uses user-to-group affiliation derived from the reporting structure and depends on a correct manager attribute [1].
• Role mining: bottom-up clustering of entitlements into candidate roles, then human curation by role owners; top-down roles from job codes. Output is a proposal, never an automatic re-assignment.
• Usage signals: inactive accounts, unused permissions and last-sign-in dates drive revocation suggestions.
• LLM layer: summarises why an item is flagged and answers reviewers' questions; newer "review agents" combine a deterministic scoring mechanism with an LLM-written justification [2]. Keep decisions deterministic and explainable; use the LLM for language only.
• Human-in-the-loop: reviewer (manager/app owner) signs the decision; high-risk and SoD items never auto-approve; revocation of critical access is staged and reversible.

Data preparation

Identity governance needs clean identity data, and this is the largest part of the project. Sources: HR master data (department, manager, job code, joiner/mover/leaver dates), Active Directory/Entra, ERP and application role tables, cloud IAM, and sign-in or usage logs. Typical gaps: HR data is outdated or lacks manager and job codes, entitlement names are cryptic technical strings with no business description, orphaned and shared accounts, no owner per application, and results of past reviews exist only in e-mail or Excel.

Preparation steps: 1. Inventory applications and name an owner per entitlement catalogue (PREP-001, PREP-004). 2. Export entitlements from ERP and SaaS systems (PREP-005) and normalise Excel-based role lists (PREP-011). 3. Fix the HR to account link, so every account maps to a person or an owned service account. 4. Write plain-language descriptions of critical entitlements (PREP-012, PREP-015). 5. Collect past decisions as labels for outlier models (PREP-020). 6. Pseudonymise exports for external tools (PREP-022).

Tools: directory exports with PowerShell or scripts, IGA connectors, Python. Expect 50 percent or more of total effort in data preparation; see GUIDE-003.

Implementation paths

Which path for whom

• SMB — Path A: use the access-review and lifecycle features of the identity platform already licensed (e.g. Microsoft Entra), since a standalone IGA suite is rarely needed.
• Enterprise — Path A: mature IGA products with AI role mining and recommendations exist; the volume of integrations favours a product over a build.
• Public sector — Path B: own workflow on a sovereign EU cloud with API analytics when IGA suites do not meet procurement or hosting rules.
• Developer — Path B: cloud-IAM analyzers plus an LLM for summaries fit teams right-sizing cloud roles and service accounts.

Path A — Buy (recommended)

• IGA suites: SailPoint (Identity Security Cloud, AI-driven recommendations and role insights), Saviynt, One Identity, Omada (Denmark, EU), IBM Security Verify Governance, Microsoft Entra ID Governance (access reviews, entitlement management, lifecycle workflows). EU/German options include Omada and Evolveum midPoint (Slovakia, open core); also consider matrix-style German/EU integrators.
• Identity-security graph / data-security platforms: Veza (access graph across apps, data and non-human identities), plus CIEM features in cloud-security platforms (Wiz, Orca, Palo Alto Prisma Cloud, Microsoft Defender for Cloud).
• Choose A when: more than ~500 identities across several systems or any audit duty. Check: EU data residency, connector coverage for your ERP/legacy systems, explainability of recommendations, API for evidence export, DPA and sub-processors.

Path B — Build on cloud APIs

• Data layer: export entitlements via Microsoft Graph, SCIM and cloud APIs (AWS IAM Access Analyzer unused-access findings, Azure/Entra, GCP IAM Recommender) into a warehouse.
• Analytics: peer-group scoring in Python/SQL; LLM (EU-region hosted Claude/GPT/Gemini or Mistral) only for justification text and reviewer Q&A, with pseudonymised identities where possible.
• Choose B when: you have a small set of systems, a data team, and an IGA product that lacks AI features.

Path C — Self-host (open source)

• Identity core: Evolveum midPoint (IGA with role mining and certification), Keycloak for IAM, Open Policy Agent for policy-as-code SoD rules.
• Analytics: scikit-learn/pandas clustering, Neo4j or Apache AGE for the entitlement graph, optional small open-weight LLM (Qwen, Llama, Mistral class) for justifications; CPU is sufficient for analytics, HW1-HW2 for the LLM.
• Effort: connector development is the main cost, not compute.

Path D — Custom training

Rarely required. Supervised models trained on past certification decisions (approve vs revoke) can improve ranking, but beware of learning rubber-stamp bias; use only after cleaning labels and with fairness and drift checks.

State of the art (2026)

• IGA vendors have added AI recommendations, role-mining engines and natural-language reviewer assistants; Microsoft added ML-based recommendations in access reviews in 2023 and later an agent that suggests decisions with justification [1][2].
• The frontier is non-human and agentic identities: inventory, ownership, short-lived credentials and just-in-time access for service accounts and AI agents, linked to AI-SPM (SEC-013).
• Zero standing privilege and just-in-time elevation reduce the review burden: less standing access means fewer items to certify.
• Limits: recommendations are only as good as HR and directory data (wrong managers, stale job codes give wrong peer groups); peer analysis penalises legitimate unique roles and rewards uniformly over-privileged teams; auto-certification can mask systemic over-provisioning; LLM justifications can be fluent but wrong, so show the underlying signals. Role mining on already messy access encodes the mess.

Shared resources & combinations

• Entitlement graph and usage logs shared with SEC-005 (UEBA: runtime anomalies versus preventive review) and SEC-001 (triage can request access revocation).
• Evidence feeds SEC-009 (ISO 27001 / NIS2 / DORA compliance automation); data classification from SEC-017 prioritises review of access to sensitive data; AI-agent identities overlap with SEC-013 and SEC-022.
• Same LLM/agent infrastructure as other SEC and AGENT use cases; analytics are classical ML and need little hardware.

Effort, cost & KPIs

• Path A: 3-12 months for an IGA programme (connectors and data quality dominate); Entra-only review setup can be done in weeks. Pricing is typically per identity per year.
• Path B/C: 3-6 months for a focused scope (cloud roles plus 3-5 apps).
• KPIs: campaign completion rate and time, share of items revoked, rubber-stamp rate (approve-all behaviour), orphaned and inactive accounts, unused-permission ratio, SoD violations open, standing privileged accounts, non-human identities with owner, audit findings.

People & change

Management sponsors the project, the information security officer and IT drive it. HR must supply reliable master data and be involved from the start; application owners and department leads become the reviewers and need to understand the AI recommendations. The DPO checks the legal basis, because identities and usage logs are personal data; a DPIA is likely when permission-usage logs are analysed per person, and an AVV (Art. 28 GDPR) is needed with the vendor.

Works council: yes. Usage and sign-in logs are suited to monitor behaviour, so §87(1) no. 6 BetrVG applies (BAG: objective suitability suffices); §90(1) no. 3 requires early information, and §80(3) allows an AI expert. Agree in a works agreement that outputs serve least privilege and audit, not performance evaluation. Public sector: staff council.

AI literacy (Art. 4 AI Act): support reviewers with training on reading risk scores, why "approve all" is not acceptable and that scores are only advice. Pilot with one application and one department, comparing AI recommendations to reviewers' manual decisions. Typical concerns are fear of losing access and of surveillance; address them with transparent criteria and an appeal route. Humans always decide on revocation; the AI only ranks and explains. See GUIDE-004, GUIDE-006 and GUIDE-008.

Risks, regulation & compliance

• EU AI Act: typically minimal risk; the system manages IT access, not employment decisions. It can approach Annex III (employment, monitoring of workers) if scores are used to evaluate or discipline employees; keep outputs scoped to access decisions [3]. Art. 4 AI literacy applies to reviewers.
• GDPR: entitlements, usage and sign-in logs are employee personal data; need a legal basis (legitimate interest/Art. 88 and national law such as section 26 BDSG), purpose limitation (no performance monitoring), DPIA where usage analytics are profiling, works-council agreement in Germany, minimisation and short log retention [4]. Art. 22 is unlikely to apply if a human decides, but document that.
• Security/finance rules: ISO/IEC 27001 Annex A access control and review, NIS2 (access control and identity management, Art. 21), DORA ICT access management for financial entities, SOX/ITGC, MaRisk in DE finance (BAIT largely superseded by DORA) [5][6].
• Risks and mitigations: bad data (fix HR source first), automatic over-revocation outage (staged revocation, break-glass), reviewer fatigue (risk-ranked batches), model bias toward majority patterns (SoD rules stay deterministic), LLM data leakage (EU region, pseudonymise, no training on prompts).

Getting started

1. Inventory systems and identities; fix HR source data (manager, department, job code) and assign owners to every application and service account.
2. Run a pilot access review in Entra ID Governance or your IGA for guests, privileged groups and one business-critical app, using inactivity and recommendation scoping.
3. Define SoD and toxic-combination rules for finance/ERP and admin roles as policy-as-code.
4. Mine roles for one department, validate with role owners, then roll out.
5. Add cloud right-sizing (unused-permission findings) and non-human identity ownership; track the KPIs monthly.

Sources

1. Microsoft Learn — Entra ID access reviews, machine-learning recommendations — https://learn.microsoft.com/en-us/entra/id-governance/review-recommendations-access-reviews
2. Petri — Microsoft Entra ID Gets AI-Powered Tool to Streamline Access Decisions — https://petri.com/microsoft-entra-id-access-review-agent/
3. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
4. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
5. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj
6. Regulation (EU) 2022/2554 (DORA) — https://eur-lex.europa.eu/eli/reg/2022/2554/oj
7. Microsoft 365 for IT Pros — Entra ID Access Reviews Get Machine Learning Recommendations — https://office365itpros.com/2023/07/21/entra-id-access-review-ai/
8. Evolveum midPoint — https://github.com/Evolveum/midpoint