Agentic AI in IAM Operations Guide

Identity teams are starting to hand access reviews, provisioning requests and policy tuning to AI agents, and an agent that can change access is itself one of the most privileged identities in the organisation. Identity platforms now ship agents that recommend approve or deny decisions in access reviews, suggest Conditional Access policies and act on identity risk, and many teams are building their own on top of IGA and SCIM APIs. Used well, these agents cut review fatigue and catch stale access that humans miss. Used badly, they rubber-stamp access at machine speed or become a single credential that can rewrite who has access to everything. This guide covers which IAM tasks suit agents, how to design autonomy levels and approvals, how to govern the agent's own identity, and how to measure whether it is helping. It is written for IAM, IGA and security architects and the operations teams who run access processes.

Key takeaways

Start with recommend, not act. Let agents analyse and recommend in access reviews and policy work before giving them any write access, and keep a human decision for anything that grants or widens access.
The agent is a privileged NHI. An IAM agent with rights to groups, roles or policies needs its own identity, an owner, least privilege, separation of duties and full logging.
Removal is safer to automate than granting. Revoking clearly unused access is lower risk than granting new access, but still needs guardrails against mass revocation.
Measure automation bias. If reviewers accept nearly every recommendation within seconds, the human check has stopped working.
Keep evidence outside the agent. Recommendations, reasoning, approvals and changes must be recorded in a system that survives the agent being removed.

Which IAM tasks suit agents

Agents add most value where the work is high volume, data heavy and repetitive, and where a wrong answer is caught before it takes effect. They add least where a decision is rare, high impact and depends on context the agent cannot see.

IAM task	What an agent can do	Risk if wrong	Suggested autonomy
Access review (certification)	Analyse activity, group memberships and employment status; recommend approve or revoke with a justification	Inappropriate access certified, or needed access removed	Recommend; human decides
Access request triage	Check request against role model, peer access and policy; route or pre-fill approval	Excess access granted	Recommend; human approves grants
Joiner provisioning from HR events	Map HR attributes to birthright roles and call SCIM or IGA connectors	Wrong roles assigned at scale	Act within pre-approved birthright rules only
Leaver deprovisioning	Disable accounts, revoke sessions and tokens across connected apps	Missed revocation, or wrong person disabled	Act on confirmed HR event, with volume limits
Dormant and orphaned account clean-up	Identify unused accounts and entitlements; propose removal	Breaking service accounts or break-glass accounts	Recommend, then act after owner confirmation
Access policy tuning	Find gaps and overlaps in Conditional Access or authorisation policies; draft changes	Lockout or policy weakened	Draft in report-only mode; human enables
Identity risk response	Investigate risky sign-ins or users; propose or take containment actions	Disrupting legitimate users, or missing compromise	Recommend, or act on narrow, well-tested actions
Role mining and SoD analysis	Cluster entitlements, propose roles, flag toxic combinations	Roles that bundle excess access	Advisory only

What vendor agents do today

Product features change quickly, so read the current documentation for any product you deploy. Two published examples show the design patterns that matter.

Recommendation in access reviews: Microsoft's Access Review Agent for Entra ID Governance was released in public preview in September 2025. As reported at launch, it analyses user activity, group memberships and employment status, gives each decision an approve or deny recommendation with a plain-language justification, and works with reviewers in Microsoft Teams.
Report-only policy changes: Microsoft documents that its Conditional Access Optimization Agent creates all new policies it suggests in report-only mode, and makes no change to existing policies unless an administrator explicitly approves the suggestion. Its permissions are mostly read-only, with one create permission for report-only Conditional Access policies.
Agents with write access: Microsoft's Identity Risk Management Agent (preview at the time of writing) holds write permissions including Policy.ReadWrite.ConditionalAccess and Group.ReadWrite.All. That is a materially different risk profile from a read-and-recommend agent.
Own identity, fixed permissions: each of these agents receives its own agent identity when enabled, and Microsoft states that their permissions cannot be changed or removed. For the Conditional Access agent, instances activated after 17 November 2025 no longer use the identity of the administrator who activated them.
Operational limits: the same documentation states that a running Conditional Access agent cannot be stopped or paused once it starts, and that removing the agent deletes its activity, suggestions and metrics while policies it created remain. Plan your evidence capture and your containment process around limits like these.

The same patterns apply to agents you build yourself on IGA or SCIM APIs: decide whether the agent recommends or acts, what scopes it holds, and where its record lives.

Designing autonomy and approvals

Autonomy levels for IAM agents

Level	Agent behaviour	Human role	Required controls
0 Advisory	Produces analysis and reports; no access to change anything	Uses the output as input	Read-only scopes; data access logging
1 Recommend	Recommends a decision per item with justification	Makes every decision	Recommendation and decision recorded separately
2 Draft	Prepares changes in a non-enforcing state (report-only policy, pending request)	Reviews and enables	Draft-only write scope; approval workflow
3 Act within rules	Executes changes that match pre-approved rules, such as birthright roles or confirmed leavers	Owns the rules; samples outcomes	Volume limits, allow-list of actions, kill switch
4 Act and report	Executes changes outside fixed rules and reports afterwards	Reviews after the fact	Generally unsuitable for grants of privileged access

See the AI Agent Autonomy Levels Framework and the Human-in-the-Loop for AI Agents Guide for wider patterns.

Approval rules that hold up

Grants need a human: any action that adds access, especially privileged roles, needs a named human approver who is not the requester.
Show the evidence: the approver must see the data behind the recommendation (last use, peer comparison, SoD conflicts), not just "approve recommended".
Fight automation bias: the EU AI Act Article 14(4)(b) names automation bias, the tendency to rely automatically or excessively on a system's output, as something human overseers must remain aware of. Counter it with random "blind" items where no recommendation is shown, and by tracking acceptance rates per reviewer.
Override and stop: reviewers must be able to disregard or reverse a recommendation, and operations must be able to halt the agent (Article 14(4)(d) and (e) describe the same capabilities for high-risk systems).
Volume limits: cap the number of revocations or grants per run and per hour, and require a second approval above the cap.

Governing the IAM agent's own identity

An agent that can modify groups, roles or access policies can be used to give an attacker persistent access (MITRE ATT&CK T1098 Account Manipulation, including T1098.001 Additional Cloud Credentials) or to abuse cloud accounts directly (T1078.004 Cloud Accounts). Treat it as you would a privileged administrator.

Distinct identity: run each agent as its own workload or agent identity, never under a human administrator's account or a shared service principal. See the Identity Governance for AI Agents Guide.
Owner and sponsor: assign a named human owner accountable for the agent's permissions and behaviour, and review that ownership when people move.
Least privilege by task: a review agent needs read access to entitlements and activity, not write access to groups. Split recommend and execute into separate identities if both are needed (NIST SP 800-53 AC-5 Separation of Duties, AC-6 Least Privilege).
Scope the targets: exclude tier 0 objects such as global administrator roles, break-glass accounts and the agent's own identity from anything the agent can change. An agent must never be able to widen its own permissions.
Delegation, not impersonation: when an agent acts on a reviewer's instruction, use token exchange so that both the human and the agent appear in the token (the RFC 8693 act claim) and in the logs.
Access controls on the agent: apply Conditional Access or equivalent policies to agent identities, restrict where they can authenticate from, and include them in identity risk detection.
Credentials: use federated or short-lived credentials over long-lived secrets. A stolen key for an IAM or remote support tool can be enough to reach very sensitive systems, as the BeyondTrust breach showed. See the Credential Vaulting for AI Agents Guide.

Agents in access reviews

Prepare the data: the agent is only as good as last-used data, HR status and entitlement descriptions. Fix missing activity data and cryptic entitlement names first.
Define what the agent may recommend: for example, recommend revoke for access unused for a set period, for leavers, or where peers in the same role do not hold it; recommend approve only with a stated reason.
Exclude high-risk items: keep privileged roles, SoD conflicts and non-human identities without activity data in full manual review at first.
Record both decisions: store the recommendation, its justification and the reviewer's final decision as separate fields, so auditors can see where humans disagreed.
Sample and calibrate: have a second reviewer check a sample of agent-recommended approvals each campaign, and feed disagreements back into rules.

See the Access Reviews Guide and the Access Review Checklist.

Agents in provisioning and deprovisioning

Authoritative triggers: act on HR or ticket events from an authoritative source, not on a natural-language request that could be manipulated. Prompt injection through ticket text or user attributes is a real path to excess access (OWASP LLM01:2025 Prompt Injection).
Deterministic execution: let the agent decide which pre-defined workflow applies, then let the IGA or SCIM connector execute it. The agent should not compose arbitrary API calls to target systems.
Leavers beyond accounts: SCIM deactivation does not always revoke sessions, API tokens or OAuth grants. Agents can help find and revoke these, but only with explicit scopes. See the Joiner-Mover-Leaver Guide and the SCIM Provisioning Guide.
Movers: an agent can propose removing access no longer justified by the new role, which is where manual processes most often fail.
Freezes and change windows: enforce change freezes in the platform, not in the agent's instructions. In the Replit AI agent database deletion, an agent ran destructive commands during a declared code freeze despite instructions not to.

How to implement

Pick one bounded use case: for example, recommendations for one access review campaign covering standard SaaS applications.
Set up the identity: create the agent identity, owner, read-only scopes and logging before connecting it to any data.
Run in shadow mode: have the agent produce recommendations that reviewers do not see, and compare them with human decisions for one campaign. Measure agreement and look closely at disagreements.
Pilot ring: show recommendations to a small group of trained reviewers, with blind items and second-reviewer sampling.
Extend carefully: add draft-mode policy work, then rule-bound actions such as leaver revocation, each with volume limits and a tested kill switch.
Rollback: keep the manual process documented and runnable. Disable the agent identity to stop it, and keep a record of every change it made so changes can be reversed (for example by re-granting from the pre-change entitlement snapshot).

Decision guidance

Vendor agent vs build your own: a platform's built-in agent comes with fixed, documented permissions and a supported integration, but you cannot narrow its scopes and its activity history may live only in the vendor console. A self-built agent gives you control of scopes and logs but you own its testing and failure modes.
Recommend vs act: choose act only where the rule is deterministic, the input is authoritative and the change is reversible. Otherwise recommend.
Small organisations: start with recommendation features in the IdP or IGA tool you already run; avoid giving any agent write access to identity policy.
Large organisations: separate recommend and execute identities, route actions through the IGA workflow engine, and give the agent programme its own change control and risk acceptance. The NIST AI RMF 1.0 functions (Govern, Map, Measure, Manage) give a structure for that governance.

Detection and measurement

Monitor: every change made by an agent identity to groups, roles, policies and credentials (NIST SP 800-53 AC-6(9) Log Use of Privileged Functions); attempts to change excluded tier 0 objects; changes to the agent's own permissions; runs outside schedule; and bulk changes above the volume limit.
Evidence: keep recommendations, justifications, approvals and changes in your own store. See the AI Agent Audit Trails for Regulators Guide.

Metric	What it shows
Agreement rate between agent recommendations and second-reviewer samples	Recommendation quality
Median time reviewers spend per recommended approval	Automation bias if it falls to a few seconds
Entitlements revoked per campaign, and percentage later re-requested	Value delivered, and false positives
Leaver access fully revoked within the target time	Deprovisioning effectiveness
Agent actions blocked by scope or volume limits	Guardrails working, or poorly set
Agent identities with an owner and reviewed permissions	Governance of the agents themselves

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	AC-2 Account Management, AC-2(4) Automated Audit Actions	Agent-driven account lifecycle and its logging
NIST SP 800-53 Rev. 5	AC-5 Separation of Duties, AC-6 Least Privilege, AC-6(9)	Splitting recommend and execute; scoping the agent
NIST SP 800-53 Rev. 5	IA-9 Service Identification and Authentication, CA-7 Continuous Monitoring	Agent identity and ongoing monitoring
NIST CSF 2.0	PR.AA-01, PR.AA-05, DE.CM-03, GV.RR-02	Identities, reviewed permissions, monitoring, accountable roles
ISO/IEC 27001:2022 Annex A	5.3 Segregation of duties, 5.15 Access control, 5.18 Access rights, 8.2 Privileged access rights	Access processes the agent supports and its own privilege
CIS Controls v8.1	Control 5 Account Management, Control 6 Access Control Management	Account inventory, granting and revoking processes
OWASP Top 10 for LLM Applications 2025	LLM06:2025 Excessive Agency, LLM01:2025 Prompt Injection	Excessive functionality, permissions and autonomy; manipulated inputs
MITRE ATT&CK v20	T1098, T1098.001, T1078.004	Abuse of an agent with identity write access

Common failure patterns

Rubber-stamping at scale. Reviewers accept agent recommendations without reading them, so certification becomes an agent decision with a human signature.
Running the agent as an admin. The agent uses a human administrator's account or a shared service principal, so its actions cannot be told apart from the administrator's and it inherits rights it does not need.
Write scopes for a read task. A review agent is given group write permissions "for later", turning a recommendation tool into a privileged identity.
Instructions instead of controls. Freezes, exclusions and limits are written into the prompt rather than enforced by scopes and the platform, so a confused or manipulated agent ignores them.
Self-modification. The agent's own identity, or its owner group, is inside the scope it can change.
Evidence lost on removal. The agent's reasoning and activity history live only in a console that is deleted when the agent is turned off.

Practitioner checklist

Inventory every agent that touches identity data or identity configuration, with owner and scopes.
Give each agent its own identity; never run it as a human administrator.
Start at recommend level; require a named human for every access grant.
Exclude tier 0 roles, break-glass accounts and the agent's own identity from its scope.
Separate recommend and execute identities where both are needed.
Enforce volume limits and change freezes in the platform, and test a kill switch.
Record recommendations, justifications, approvals and changes in your own store.
Run new agents in shadow mode for at least one campaign before reviewers see output.
Track acceptance rate and review time per reviewer to spot automation bias.

Agentic AI in IAM Operations Guide: Using Agents for Access Reviews and Provisioning