Agentic AI Identity Isn't NHI: A 2026 Maturity Model

The instinct to treat an AI agent as "just another NHI" is understandable. Both are non-human. Both need credentials, scopes, and lifecycle management. But the resemblance stops at the surface. A traditional service account or API key performs a narrow, predictable task, and its scope is fixed at design time by a human engineer. If a payment-processing service account starts calling an HR API, that is unambiguously an incident, because the account's behavior space was defined once and never changes on its own.

An agentic system does not work that way. It is handed an intent, decomposes that intent into steps at runtime, calls whichever tools or APIs it judges appropriate for the task in front of it, and produces an outcome that was never enumerated in advance. It authorizes and re-authorizes itself continuously as it works, often acting on behalf of a specific human principal without that human confirming each individual step. That is the core distinction: traditional NHI has a scope, agentic AI has a mandate, and a mandate can be satisfied in ways nobody wrote down.

The scale backing this shift is not speculative. Analyst research already put non-human identities at 25 to 50 times the headcount of human users in many enterprise environments before agentic AI entered the picture, and Gartner has projected that 40% of enterprise applications will embed task-specific AI agents by the end of 2026, up from under 5% in 2025. That trajectory is why groups like OWASP's GenAI Security Project have published a dedicated Agentic AI Threats & Mitigations taxonomy and a Top 10 for Agentic Applications, separate from their existing LLM guidance, and why CISA and its Five Eyes partners issued a joint advisory in May 2026 specifically on careful adoption of agentic AI services. Regulators and standards bodies are treating this as a new category because the failure modes are new. For background on the baseline discipline this builds on, our non-human identity security guide covers service accounts, API keys, and workload identities in depth; this piece picks up where that one ends.

The most useful framework to date for reasoning about this problem comes from CSO Online's coverage of a six-stage maturity model built around KuppingerCole's 2026 research into non-human identity management, extended specifically for agentic systems. We have adapted the stage boundaries here for an organizational, governance-level lens rather than a pure technical audit checklist, because the question that matters to security architecture and identity teams is less "does this pass a compliance scan" and more "what does our organization actually do differently at each stage, and what breaks if we skip one."

The six stages, in order, are:

Despite how much agentic AI has been discussed in the last year, most enterprise programs are somewhere between stage 0 and stage 2, not because teams are careless but because agent adoption typically starts as a series of disconnected pilots. A sales engineering team wires an agent into a CRM. A DevOps team gives an agent write access to a ticketing system to auto-triage alerts. Each pilot solves a real problem, and each one creates an identity that nobody outside the team that built it is tracking.

Stage 0 is the default state of an organization that has not deliberately looked for agents. It is not a moral failing, it is what happens when agent creation is as easy as calling an API with a system prompt, and no policy requires registration before deployment. The risk compounds because shadow agents frequently inherit broad permissions from whatever human or service credential was easiest to reuse at build time, which means the blast radius of an unmanaged agent is often wider than the blast radius of an unmanaged service account.

Stage 1 (inventoried) is usually reached reactively, after a security review, an incident, or a vendor risk assessment forces the question of "what agents do we actually have running." Getting to stage 1 is necessary but insufficient. An inventory without governance tells you what exists, not what any of it is allowed to do, which is why organizations frequently sit at stage 1 for months while treating the inventory itself as the deliverable.

Stage 2 (individually attributable) is where the identity team starts actively participating instead of just cataloging. The critical operational change here is eliminating shared credentials between agents, and between agents and the humans who built them. An agent that authenticates using a developer's personal token or a shared service account credential cannot be individually audited, which means every governance control layered on top of it, monitoring, access review, incident attribution, is compromised at the root. Teams get stuck at stage 2 when lifecycle rules exist on paper (a provisioning ticket, a deprovisioning checklist) but are applied inconsistently, so some agents get cleaned up when a project ends and others quietly keep running with live credentials for months.

Stage 3 is where an agent identity program becomes defensible in an audit, and it is worth being specific about why. The defining requirement is an explicit on-behalf-of model: every agent action is traceable to a named human principal who authorized the agent to act, not to an abstract service identity that could theoretically have been triggered by anyone. Paired with that is the elimination of long-lived credentials in favor of short-lived, context-bound tokens that expire on a timescale matched to the task rather than to IT convenience, a complete audit trail that lands in the SIEM rather than in an application-specific log nobody reviews, and the operational capability to revoke an agent's access within seconds, not the next maintenance window.

These four requirements sound like implementation details, but they are the difference between an organization that can answer "what did this agent do and who authorized it" during an incident, and one that cannot. Below stage 3, that question does not have a reliable answer, which is the practical reason CSO Online's framework and the broader analyst consensus treat it as the line between ungoverned and governed agent programs.

This is also the stage where the specific authorization mechanics matter, and where the protocols diverge sharply in how they implement delegation, credential lifetime, and revocation. Auth0, Microsoft Entra Agent ID, and Okta XAA (Cross App Access) all target this exact governance floor, but they get there through materially different technical approaches to token issuance, scoping, and the on-behalf-of relationship itself. Rather than duplicate that analysis here, see the protocol-level comparison of Auth0, Entra Agent ID, and Okta XAA for the technical authorization-protocol comparison. What matters at the governance level is simpler: pick a mechanism that actually satisfies all four stage 3 requirements, and verify it does, rather than assuming a vendor's agent-identity feature checks every box by name alone.

Stage 4 moves the organization from "we can reconstruct what an agent did after the fact" to "we actively constrain what an agent can do while it is doing it." Action boundaries become policy-enforced rather than credential-enforced alone, meaning an agent can be individually attributable and running short-lived credentials (stage 3) while still being free to take any action those credentials technically permit. Stage 4 adds the layer that limits that further: explicit boundaries on what categories of action an agent may take without additional review, a design requirement that actions be reversible wherever feasible, and active evaluation of behavioral metrics, how often an agent's requests get denied, how its request patterns shift over time, rather than only capturing that data for a future investigation.

Stage 5 is where the program stops depending entirely on a human noticing a problem. Anomaly detection is tied directly to automated response: a deviation from an agent's established behavior pattern triggers an automatic pause or credential revocation, with a human reviewing after the fact rather than being the trigger itself. The other structural requirement at this stage is named ownership, every agent has a specific accountable human, not a team or a role, which closes the accountability gap that tends to reopen the moment an organization scales past a handful of agents.

Tooling vendors are building toward different points on this curve rather than a single endpoint. SailPoint's public framing of agent identity security centers on four pillars, discovering agents as first-class identity citizens, policy-driven and risk-based access decisions, explainable and auditable accountability across the human-machine boundary, and automated lifecycle management at scale, which maps most directly onto helping organizations move from stage 2 into stages 3 and 4. Strata.io's agent fabric concept takes a different angle, positioning an orchestration layer that discovers agents dynamically, organizes them by policy, and links runtime behavior back to a verifiable identity in the organization's existing identity provider, aimed at the sprawl problem that shows up acutely between stage 1 and stage 3 when agent count outpaces manual governance. Microsoft's Entra Agent ID is a third example, a first-party identity construct for agents inside the Microsoft ecosystem that is relevant to how an organization actually implements the delegation model stage 3 requires. None of these are a substitute for the governance decisions above, and none of them do the job alone; they are infrastructure that makes a given stage achievable once an organization has decided that is the stage it needs to reach. Our comparison of HashiCorp Vault, SailPoint, and Saviynt covers how these platforms differ on machine identity versus human identity more broadly, which is useful context before evaluating any of them specifically for agent identity.

Maturity models are only useful if an organization can place itself on one honestly, and the honest answer is usually lower than the stage a team's internal narrative suggests. A few direct questions surface the real answer faster than a formal audit.

The failure modes are specific enough per stage that naming them helps teams recognize when they are stuck rather than progressing.

Standards and regulatory attention are catching up faster than they did for earlier NHI categories. NIST launched an AI Agent Standards Initiative in February 2026, and the joint CISA and Five Eyes advisory on agentic AI adoption from May 2026 signals that this is being treated as its own risk category at the policy level, not folded into general AI governance guidance. Expect identity vendors to keep building agent-specific tooling that assumes organizations need to move through these stages rather than jump straight to stage 5, since the gap between where most programs sit today (stage 0 to 2) and the governance floor (stage 3) is still the most common place agent rollouts stall before they ever reach production.

The practical trajectory for security architecture teams is to stop asking whether an existing NHI program can be stretched to cover agentic AI, and start asking which stage a given agent deployment needs to reach before it goes into production, and whether the tooling and process exist to get it there and keep it there. Programs that treat agent identity as a variant of service account management will keep discovering, usually during an incident, that they never actually answered who authorized this agent to do what it just did. For the credential and workload-identity foundations that stage 2 and 3 requirements build on, particularly around eliminating long-lived secrets, our guide to workload identity federation covers the CI/CD pattern that a lot of agent credential design is now converging toward.