AI agent identity breaks traditional IAM assumptions

At a glance

What this is: This is an analysis of why AI agent identity requires new access patterns, with persona shadowing, delegation chains, and capability tokens emerging as the main control ideas.

Why it matters: It matters because IAM, PAM, and governance teams must decide how to bound, audit, and certify agent actions without forcing AI into controls designed for humans or simple service accounts.

👉 Read WorkOS's analysis of AI agent identity, delegation, and capability tokens

Context

AI agent identity is the problem of proving who or what an agent is, what it may do, and how far its delegated authority extends. Traditional machine-to-machine authentication was built for predictable service-to-service calls, not for software that can choose tools, act across systems, and continue operating across multiple invocations.

That mismatch matters because enterprise identity programmes depend on stable assumptions about scope, accountability, and reviewability. When an agent can work across Jira, Salesforce, Slack, and a production database, the control question shifts from login to delegated action, and the existing IAM model becomes too narrow to contain the blast radius.

Key questions

Q: How should security teams govern AI agents that need access across multiple business tools?

A: Treat each agent as a distinct identity with its own scoped permissions, then bind those permissions to a human delegator and a specific task. Broad shared access across Jira, Salesforce, Slack, and production systems creates poor accountability and too much blast radius. Governance should follow delegation, expiry, and auditability, not just application onboarding.

Q: Why do traditional RBAC models struggle with AI agent access?

A: RBAC struggles because agents do not behave like stable human roles. Their needed permissions can change from run to run, and the right access may depend on the current task, data, or tool chain. That makes static role assignment too coarse and often over-privileged. Task-scoped capability tokens usually fit the behaviour better than durable role membership.

Q: How can organisations keep AI agent actions auditable?

A: Log the full delegation chain, from the delegating user through each agent hop to the final system touched. Auditable records must show who authorised the action, what scope was granted, which tools were used, and when access expired. Without that chain, compliance teams cannot separate legitimate delegation from unsafe automation or investigate misuse quickly.

Q: What should teams do when an AI agent needs to escalate access dynamically?

A: Require explicit policy for escalation, then constrain it to narrowly defined contexts and time windows. Dynamic privilege should never become open-ended standing access just because the agent is useful. Teams should define which actions can self-authorise, which need human approval, and how the extra access is revoked after the task finishes.

Technical breakdown

Persona shadowing and independent agent identity

Persona shadowing gives each AI agent its own identity while linking it to the delegating user. That avoids direct impersonation and preserves accountability when the agent acts on the user’s behalf. In practice, the agent is treated as a distinct subject with a scoped credential set, rather than as an invisible extension of the human. This matters because audit trails, policy enforcement, and incident response all depend on being able to separate the actor from the authoriser. If the agent simply borrows the user’s identity, attribution and revocation become far harder.

Practical implication: Create distinct identities for agents and bind each one to a human delegator, so access can be reviewed and revoked independently.

Delegation chains and capability-based tokens

Delegation chains preserve authority across multiple hops, such as user to Agent A, Agent A to Agent B, and then to a third-party API. Each hop needs verifiable context so downstream systems know the original authority and current scope. Capability-based tokens fit this model because they encode specific rights for a limited time, such as read-only calendar access for 60 minutes. That is a different shape of control from static RBAC, which assumes durable roles rather than task-scoped rights. The technical challenge is keeping the chain auditable without letting it sprawl into uncontrolled privilege inheritance.

Practical implication: Use short-lived capability tokens with explicit delegation context, and validate that every hop preserves the original authorisation chain.

Why RBAC and human login flows fail for agents

Human authentication assumes a person can complete an interactive login flow and that access can be reasoned about in relatively stable sessions. AI agents break both assumptions. They may need persistent sessions, headless authentication, and access to actual application interfaces rather than only backend APIs. They also need to act under changing user requests, which makes predefined role scopes too blunt and dynamic escalation more likely. The result is not just a policy gap but an architectural one: the identity layer must support machine-first authentication and runtime-authorised action, or the agent will either be over-privileged or unable to function.

Practical implication: Move agent authentication out of human login patterns and into headless, time-bound, application-specific credential flows.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

AI agent identity is exposing an assumption collapse in IAM, not just a new control gap. Traditional identity design assumes an actor’s access can be named, bounded, and reviewed before the session unfolds. That assumption fails when the actor can choose tools, chain delegation, and continue acting across multiple systems with non-deterministic intent. The implication is that agent governance cannot be an extension of human access review cadence alone.

Persona shadowing is a useful concept because it separates accountability from impersonation. The agent acts on behalf of a user, but the identity subject must remain distinct if logs, revocation, and policy enforcement are going to mean anything. This maps cleanly to OWASP-NHI thinking and zero trust principles, where the subject of access is never assumed to be the same as the delegator. Practitioners should treat agent identity as its own governed subject, not as a disguised user session.

Capability tokens describe the right control shape for agent work because they shrink blast radius to the task, not the role. Static roles are poor matches for software that needs different rights on different runs, in different tools, and under different user requests. Time-bound, unforgeable, task-scoped tokens align better with agent behaviour and make overreach easier to detect. The practitioner takeaway is that access design must follow task scope, not organisational role structure.

Delegation chains are now an audit problem as much as an authorisation problem. Once Agent A can spawn Agent B and both can touch external systems, every link becomes part of the trust boundary. That makes end-to-end context preservation essential for accountability and forensics. NIST CSF and ZTA thinking both apply here: if the chain cannot be reconstructed, the control model has already failed.

Capability token sprawl: This article points to a new failure mode where agents accumulate many short-lived rights across tools faster than teams can rationally recertify them. The governance problem is not just privilege size, but privilege churn across execution contexts. That means lifecycle, revocation, and traceability must be designed for machine speed, not human review tempo.

From our research:

• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot reliably account for non-human credential exposure during investigations.
• For a broader view of lifecycle controls, read Ultimate Guide to NHIs , 2025 Outlook and Predictions for how NHI governance is changing.

What this signals

Capability token sprawl: AI agent programmes will fail if teams let short-lived permissions accumulate without a lifecycle model that can track delegation, expiry, and revocation at machine speed. The practical signal is not agent volume alone, but whether access records stay intelligible after repeated tool hops and sub-agent handoffs.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, the broader identity lesson is clear: machine access becomes dangerous when it is easy to distribute and hard to reclaim. Agent governance should therefore be tied to secret hygiene, delegation logs, and time-bound entitlements, not treated as a separate AI-only project.

For practitioners

• Separate agent identity from human identity Issue each agent its own credential set and bind it to the delegating user so logs, revocation, and policy decisions stay attributable.
• Adopt task-scoped capability tokens Replace broad standing access with short-lived rights that encode a single purpose, a narrow target system, and a clear expiry.
• Instrument delegation-chain logging end to end Record every hop from user to agent to sub-agent to external service so investigators can reconstruct who authorised what, where, and when.
• Rework access review for machine-paced behaviour Review agent entitlements as living delegation records, not static user-like accounts, and require automated expiry checks before reapproval.

Key takeaways

• AI agent identity breaks the assumptions behind traditional human login flows and static machine-to-machine access models.
• The control problem is accountability across delegation chains, not just authentication at the first hop.
• Practitioners should design for separate agent identities, task-scoped tokens, and revocation that keeps pace with machine execution.

Key terms

• Persona Shadowing: A pattern where an AI agent acts under its own identity while remaining linked to a human delegator. This preserves attribution, revocation, and auditability. It is more defensible than direct impersonation because the agent is governed as a separate subject with scoped authority.
• Delegation Chain: The sequence of authority passed from a human to one or more agents and then to downstream services. Each hop must preserve context, scope, and expiry so the original authority can be traced. In agentic systems, broken chains create both security blind spots and compliance gaps.
• Capability Token: A short-lived credential that grants a narrow, explicit right for a single task or action. Unlike a broad role, it encodes what the agent may do, for how long, and often where. This makes it better suited to unpredictable agent work and easier to revoke when the task ends.

Deepen your knowledge

AI agent identity, delegation chains, and capability tokens are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agent-driven systems, it is a practical place to start.

This post draws on content published by WorkOS: Identity for AI: Who Are Your Agents and What Can They Do? Read the original.