Security leaders

The Identity Crisis at the Heart of Agentic AI

The end of the application as authorization policy — and what must take its place

A

AI agents dissolve the "person + app" model — they call APIs directly, spawn other agents, and already outnumber human identities in many environments.

B

IAM must absorb work the application used to hide — authorization logic becomes explicit: delegation chains, runtime constraints, and a four-layer stack for humans and agents.

C

The human/agent boundary has to be enforced, not detected — structurally different credential types and verifiable delegation chains beat after-the-fact behavioral monitoring.

For four decades, Identity and Access Management rested on a stable foundation: a human being authenticated to an application, and the application mediated all access to downstream resources. The application was, in a real sense, the authorization policy made visible — menus grayed out for unauthorized users, workflows enforcing operational order, forms validating inputs. The human was the trust anchor; the application was the gatekeeper; and IAM’s job was to manage the binding between them.

That foundation is cracking. Not because identity has become less important, but because two of its three pillars have fundamentally changed. The application layer is dissolving — AI agents now interact directly with APIs and data stores, bypassing the UI entirely — and the set of principals requiring identity has exploded far beyond human beings. Non-human identities (NHIs) — service accounts, bots, API keys, and increasingly autonomous AI agents — already outnumber human identities by 45 to 100 to one in many enterprise environments. The question is no longer how to manage human access to applications. It is how to manage a hierarchy of human and non-human principals, operating at machine speed, across organizational boundaries, with no application layer to serve as a natural control point.12

The Application Was Doing More Work Than Anyone Noticed

The loss of the application layer is only partially about user experience. Architecturally, the application was performing enormous amounts of authorization work that was never explicitly modeled as such. It scoped what operations a user could invoke. It enforced sequencing — you couldn’t skip steps in a workflow. It constrained the blast radius of any single authenticated session to what could be accomplished through its UI. When agents replace applications by calling APIs directly, all of that implicit authorization must be re-expressed explicitly — as runtime action constraints on the agent’s identity, as token scopes, as CIBA-style human approval gates for high-risk operations. The work doesn’t disappear; it becomes visible for the first time, and the IAM infrastructure must absorb it.3

Agents Introduce Delegation Chains, Not Single-Hop Authentication

The traditional auth flow was one hop: user authenticates, gets a token, accesses a resource. Agentic architectures create delegation chains. A human authorizes an orchestrator agent; the orchestrator spawns sub-agents; sub-agents invoke tools; tools call external APIs. Each link is a distinct principal requiring its own identity. Each adds a point where authority can be over-granted, misconfigured, or orphaned long after the task completes.4

Side-by-side comparison: a traditional single-hop auth flow on the left (user → app → data store) versus an agentic delegation-based flow on the right, where an orchestrator agent spawns multiple sub-agents and tools, each with its own identity and each calling downstream APIs and resources.

Managing this requires moving from flat credential management to principal hierarchy modeling — expressing not just “who is this entity” but “who authorized this entity, under what constraints, and for how long.” The IETF is already drafting OAuth 2.0 extensions to support this, introducing actor_token parameters that cryptographically document the delegation chain inside the token itself. The protocol plumbing is being extended, not replaced — but the semantic richness required is an order of magnitude beyond what OAuth was originally designed to carry.5

A Four-Layer Architecture Is Emerging

A coherent response to these pressures is taking shape across the industry, built on four complementary layers that each address a different aspect of the problem.

The emerging four-layer IAM architecture for human and agent principals: Directories (LDAP/AD) for onboarding and type classification at the base, Workload PKI (SPIFFE/SPIRE) for cryptographic identity above it, Verifiable Credentials carrying delegation chains next, and DIDs plus Universal Resolver for cross-organizational verification at the top. Human and agent principals flow through all four layers via structurally distinct credential types.

LDAP/Active Directory retains its role, but narrowed to what it does well: onboarding and type classification. The critical discipline is structural separation — agents and humans must occupy distinct organizational units with different object schemas, different lifecycle owners, and different issuing processes. This is the architectural analog of different countries issuing different passports: not just a namespace partition, but an assertion about provenance and governance process. A human credential requires an HR workflow and biometric capture to issue; an agent credential requires a developer provisioning event. The moment these processes share infrastructure, the human/NHI distinction becomes unenforceable downstream.6

PKI — specifically SPIFFE/SPIRE for workload identity — provides agents with cryptographic identities that encode what a workload is rather than who a person is. Short-lived certificates (the industry is converging on 47-day maximum lifespans) enforce rotation and limit the blast radius of compromise. Crucially, the CA hierarchy for agents is physically separate from the CA hierarchy for humans, meaning a relying party can inspect the issuing chain and immediately determine principal class — agent credentials cannot be mistaken for human credentials at the cryptographic layer.7

Verifiable Credentials (VCs) carry the delegation semantics that PKI cannot express natively. A VC issued to an agent can encode the full principal chain — “this agent was delegated by human X, authorized by organizational credential Y, with scope Z, expiring at T” — as a cryptographically signed, self-proving document. Unlike LDAP, which requires a live directory query and trusts the directory server, a VC is verifiable by any party that can resolve the issuer’s public key. Unlike a JWT, it carries rich provenance claims rather than just scope assertions. Chained VCs make delegation trees auditable end-to-end without requiring a shared directory or pre-established federation agreement between organizations.8

Decentralized Identifiers (DIDs) and the DIF Universal Resolver complete the picture for cross-organizational trust. A DID — structured as did:method:identifier — is a globally unique identifier that resolves to a DID Document containing the entity’s public keys and authentication methods, with no CA required. The Universal Resolver functions as DNS does for email: a single resolution endpoint that routes to any of 45+ method-specific drivers, enabling any party to verify any DID regardless of which ledger or infrastructure anchors it. For cross-organizational agent interactions, this eliminates the need for shared CA roots or bilateral federation agreements — the VC carries the trust, the resolver provides the key material, and the ledger is simply a tamper-evident key registry.910

The Human/NHI Distinction Must Be Enforced, Not Detected

Two in five SaaS platforms currently cannot distinguish human from non-human identities at all. The standard response — behavioral monitoring and anomaly detection — is necessary but insufficient on its own. Behavioral signals operate after the fact, tolerate false negatives, and require a trained baseline to be meaningful. The more robust approach is making the credential type structurally unobtainable by the wrong principal class, so detection is never needed.6

Side-by-side comparison: "Detection After the Fact" on the left, showing a mixed pool of human and agent identities that can only be sorted out by behavioral monitoring downstream, versus "Enforced Credential Separation" on the right, showing human and agent credentials routed to structurally distinct authentication paths from issuance onward, with cross-flows blocked at the credential layer.

For humans, FIDO2/passkey authentication provides the cryptographic floor: the private key never leaves the hardware authenticator, and the User Presence gesture proves a physical entity acted. For agents, hardware-bound attestation via TPM or secure enclave proves that specific, unmodified code is executing on authorized infrastructure — a different property than biological liveness, but equally non-fakeable remotely.11

The challenge is that liveness detection as a human/NHI discriminator is under genuine pressure. Robotic actuators can trigger physical gesture requirements; generative AI has made real-time synthetic faces trivially producible at scale. The security guarantee is shifting from “definitively proves a human was present” toward “proves whoever controls this hardware performed an action, supported by behavioral and signal-provenance signals.” That probabilistic framing — uncomfortable for compliance frameworks built on binary identity assurance — is increasingly the honest description of what modern authentication can deliver.12

The Convergence Ahead

The trajectory points toward a unified DID-based credential format for both humans and agents, with the human/agent type distinction preserved as a first-class claim in the credential schema rather than as an artifact of directory structure. HR’s role evolves from running a directory to functioning as a governance oracle — the authorizing institution that issues the bootstrapping VC that establishes a human’s identity, after which the DID and its credential chain are self-sustaining. The EU’s eIDAS 2.0 framework, building national digital identity wallets on W3C VC/DID foundations, is the live experiment in this model at state scale.

The deeper shift is philosophical. Identity and Access Management was designed to answer a simple question: is this person allowed to use this application? The emerging question is more complex: is this principal — human or agent, operating in a delegation chain of unknown depth, potentially across organizational boundaries — authorized to perform this specific action, and is there a human decision somewhere in that chain that can be held accountable? Answering that question requires the full four-layer stack. It also requires accepting that the clean perimeter IAM was built to defend no longer exists — and designing for audit, traceability, and probabilistic trust rather than for the illusion of a definitive boundary.

Footnotes

  1. The End of Traditional SaaS: How AI Agents Are Redefining Business Applications — AI agents eliminate the need for a rigid application stack by directly querying and updating databases.

  2. 2026 NHI Reality Report: 5 Critical Identity Risks — Why non-human identities outnumber humans in enterprise systems, and what to do about it.

  3. Authorize an AI Agent to Perform Tasks on Your Behalf — Identity for AI — Ping Identity’s tutorial series on agent authorization patterns including CIBA-style human approval.

  4. AI Agent Identity: The Foundation of Trust for Autonomous Agents — Why autonomous agents need distinct, verifiable digital identities and how delegation chains work.

  5. OAuth 2.0 Extension for AI Agents Acting on Behalf of Users (IETF draft) — Draft protocol extension adding actor_token parameters to document delegation chains inside OAuth tokens.

  6. How to Distinguish Between Human and Non-Human Identities — Human and non-human identities require structurally different authentication and governance approaches. 2

  7. Agentic AI Needs Stronger Digital Certificates — Why certificate lifespans are shrinking to 47 days as a governance feature for workload identities.

  8. Aries RFC 0104: Chained Credentials — Cryptographically signed delegation chains enable offline verification and powerful privilege delegation.

  9. Universal Resolver — resolve practically any DID — A single utility for resolving Decentralized Identifiers across 45+ DID method drivers.

  10. Decentralized Identifiers (DIDs) v1.1 — W3C — The W3C specification for Decentralized Identifiers, DID Documents, and DID resolution.

  11. What Is FIDO2? — Microsoft Security — Passkeys and FIDO2 sign-in credentials created using public key cryptography with hardware-bound private keys.

  12. What Is Liveness Detection? — Daon — Multi-signal approaches to confirming human presence in an era of synthetic identity.