IAM maturity models miss the identity shift AI agents create

At a glance

What this is: This guide frames IAM maturity as a four-level progression and argues that better lifecycle, access, and governance practices are needed to move from fragmented controls to optimized identity operations.

Why it matters: It matters because IAM teams must now judge the same maturity patterns across human users, NHIs, and emerging AI-driven actors, where weak lifecycle and access governance quickly become security and compliance problems.

By the numbers:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.
• Only 13% of security leaders feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.

👉 Read Zluri's guide to IAM maturity models for 2026

Context

IAM maturity models are useful only when they reflect how identities actually behave in production, and that is where most programmes still fall short. The article describes a staged model for access management and lifecycle control, but the bigger issue for IAM teams is that maturity often advances on paper faster than governance improves in practice.

For human IAM, that gap shows up as inconsistent access reviews, weak provisioning discipline, and incomplete deprovisioning. For NHIs and AI-driven systems, the same gap becomes more dangerous because access can scale faster, persist longer, and be harder to explain or certify after the fact.

Key questions

Q: How should teams assess IAM maturity when NHIs and AI systems are in scope?

A: They should assess maturity by actor type, because human IAM, service accounts, and AI-driven identities fail in different ways. The useful question is whether lifecycle, access, and governance controls can keep pace with the identity’s actual behaviour. If a process works only for stable human users, it is not mature enough for machine or AI identities.

Q: Why do IAM maturity models break down in environments with lots of service accounts?

A: They break down when maturity is measured by policy presence instead of entitlement closure. Service accounts often persist after the work they support has changed, and manual offboarding leaves old credentials and permissions in place. That creates review blind spots, orphaned access, and a false sense of control even when the programme looks well governed.

Q: What do security teams get wrong about access management maturity?

A: They often confuse structured process with effective control. A programme can have RBAC, ABAC, and reviews yet still fail if privileges cannot be reduced quickly or if exceptions are never closed. Real maturity shows up in revocation speed, current entitlement scope, and whether the control actually changes access outcomes.

Q: What is the difference between defined IAM processes and managed IAM processes?

A: Defined IAM processes are documented and repeatable, but still largely reactive. Managed IAM processes anticipate risk, enforce controls more consistently, and use monitoring or analytics to detect drift before it becomes a breach or compliance issue. The difference is not just process maturity, but whether the programme can prevent identity problems instead of responding after the fact.

Technical breakdown

Identity lifecycle management maturity and why manual provisioning fails

Identity lifecycle management, or ILM, is the process of creating, changing, and removing identity records as roles and systems change. In immature environments, provisioning is manual or script-driven, which increases error rates, slows onboarding, and leaves orphaned access behind when people or systems move on. As programmes mature, lifecycle logic becomes centralized and more API-driven, so identity data can be synchronised across systems instead of handled as a series of disconnected tickets. That shift reduces drift, but only if removal and change processes are governed with the same discipline as initial onboarding.

Practical implication: treat provisioning and deprovisioning as one control surface, not separate administrative tasks.

Access management maturity from ad hoc roles to least privilege

Access management maturity is the difference between granting access case by case and enforcing a controlled access model with reviewable policies. Early-stage programmes rely on fragmented decisions and periodic certification, while higher maturity introduces RBAC, ABAC, PAM, and eventually least privilege with tighter scope and duration. The article reflects a common progression, but the technical reality is that least privilege is only meaningful when entitlements are measurable, revocable, and aligned to a current task or role. Without that, access governance becomes a reporting exercise rather than a control.

Practical implication: measure whether access can actually be reduced or revoked in time, not just whether it is documented.

Governance, review cadence, and the limits of maturity scoring

Governance is the layer that turns identity controls into an auditable programme. It depends on policy, reporting, and review cadence, but maturity scores can hide whether those controls are operating at the pace of real identity change. A process may look mature because it has policy and dashboards, yet still fail to catch privilege creep, delayed offboarding, or inconsistent enforcement across business units. That is why governance must be tested against live identity events, not scored only against documentation. The practical issue is less about having a model and more about whether the model can keep up with the rate of change.

Practical implication: validate governance against real joiner, mover, and leaver events, not just maturity self-assessments.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

IAM maturity models are useful, but they often overstate control readiness when lifecycle execution remains manual. The article’s four-level framing shows the familiar path from ad hoc to optimized, yet most organisations still struggle to make provisioning, modification, and removal work consistently across all identity types. That means maturity scoring can look better than actual operational control. Practitioners should treat lifecycle execution, not policy presence, as the real maturity test.

Identity lifecycle management is where IAM maturity either becomes real or remains performative. Manual account creation, partial automation, and delayed removal are not just efficiency problems. They create the conditions for stale access, review failure, and inconsistent entitlement state across users and systems. When lifecycle governance is weak, every downstream control inherits that weakness. Practitioners should evaluate whether lifecycle events are resolved at system speed, not human queue speed.

Governance drift: IAM programmes can have formal policy and still fail because the policy is not enforced consistently across access, lifecycle, and review workflows. The article describes governance as reporting and oversight, but governance is only meaningful when it changes entitlement outcomes. A mature-seeming programme can still leave dormant access in place, especially when changes, removals, and exception handling are fragmented. The implication is that maturity must be measured by control closure, not documentation volume.

Access management maturity is not complete until least privilege is operational, measurable, and reversible. The article’s progression from RBAC and ABAC toward least privilege reflects the right direction, but too many programmes stop at policy-level intent. If entitlements cannot be reduced quickly, scoped tightly, and reviewed in context, then the programme is still living in a mid-maturity state. Practitioners should focus on revocation speed, entitlement scope, and exception handling as proof points.

The same maturity logic now needs to be applied across humans, NHIs, and AI-driven identities without assuming they behave the same way. Human access reviews, service account rotation, and AI system governance all sit inside the same identity discipline, but each actor type changes the pace and failure mode of control. The broader field needs maturity models that stop treating identity as a single category. Practitioners should map controls by actor type before assuming one maturity model fits all.

From our research:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, according to the Ultimate Guide to NHIs, which shows how slowly identity remediation still moves in practice.
• NHI Lifecycle Management Guide is the next step for teams that need to turn lifecycle governance into repeatable operational controls.

What this signals

Governance maturity will increasingly be judged by identity type, not by a single enterprise-wide score. Human access, service account governance, and autonomous system controls are converging inside the same programme, but they fail on different clocks. Teams should expect more pressure to prove that lifecycle closures, revocations, and reviews are working at the pace of each actor type rather than at the pace of policy reporting.

Lifecycle debt is the practical measure that will expose overstated maturity. When offboarding, privilege reduction, and entitlement cleanup trail behind system changes, maturity dashboards become misleading. Programmes that still rely on human queue times for machine identities will struggle to defend their control model as infrastructure becomes more dynamic.

With 92% of organisations exposing NHIs to third parties, according to the Ultimate Guide to NHIs, lifecycle governance is no longer a back-office process. It is a boundary control that will determine how much trust extends beyond the enterprise perimeter.

For practitioners

• Map maturity levels to actor type Separate human IAM, service account governance, and AI-driven identity control into different maturity baselines so you do not measure them with the same operational assumptions. Use actor-specific lifecycle and access criteria when assessing whether a process is fragmented, defined, managed, or optimized.
• Test lifecycle closure against real events Run joiner, mover, and leaver checks against live provisioning and deprovisioning records, including API keys, service accounts, and delegated admin access. If removal still depends on tickets, the control is not operationally mature.
• Prove least privilege with revocation evidence Require evidence that access can be reduced, scoped, or revoked quickly for each identity class. Document whether access reviews result in actual entitlement change, not just sign-off activity, and track the time between decision and enforcement.
• Tie governance reporting to control outcomes Replace maturity dashboards that count policies and attestations with reporting that shows closed exceptions, removed orphaned access, and reduced privilege spread. Governance should reflect whether the environment is safer, not merely more documented.

Key takeaways

• IAM maturity is only meaningful when lifecycle and access controls work at operational speed.
• Manual provisioning, delayed removal, and weak exception closure are the clearest signs that maturity is overstated.
• Identity programmes now need actor-specific maturity criteria for humans, NHIs, and AI-driven systems.

Key terms

• Identity Lifecycle Management: Identity lifecycle management is the discipline of creating, changing, and removing identity records as people, systems, or agents move through their operational life. In mature programmes, it is treated as a control process, not an administrative task, because delays or errors in lifecycle handling create orphaned access and audit gaps.
• Access Management Maturity: Access management maturity describes how consistently an organisation can grant, restrict, review, and revoke access across identity types. Higher maturity means decisions are policy-driven, measurable, and reversible, not just documented. For NHIs and AI-driven identities, maturity also depends on whether access can be aligned to task scope and execution speed.
• Governance Drift: Governance drift is the gap between written identity policy and the actual access outcomes that occur in production. It appears when reviews, exceptions, and removals do not keep pace with changing roles or system behaviour. In practice, drift is one of the clearest signs that a maturity model is being reported, not enforced.

Deepen your knowledge

IAM maturity model assessment and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are modernising identity controls across human, machine, and AI-driven actors, it is worth exploring.

This post draws on content published by Zluri: Access Management Identity & Access Management Maturity Model - A Guide For 2026. Read the original.