AI agent identity lifecycle — what your IAM program needs in 2026

AI agents — autonomous systems that act on behalf of human users to complete tasks — are now a real production workload. Anthropic Claude agents, OpenAI Operators, Microsoft Copilot agents, and a growing population of in-house agentic systems are operating against your identity infrastructure today, in many cases borrowing service-account credentials or running under the context of the human user who launched them.

Neither pattern is durable. AI agents have identity properties that look different from both service accounts and human users, and most IAM platforms have not caught up with the operating-model implications. This piece covers what we recommend on engagements where AI agents are part of the workload.

Why agents are not service accounts

Service accounts are persistent, centrally managed, and bound to a specific application. The identity is the application's identity, period. Agents are different in several ways:

• They are spawned per session, not per application. A Claude agent launched at 9am to handle a customer support ticket is a different agent from the one launched at 9:15am. They share an underlying model but the operational identity is per-session.
• They act on behalf of a specific human. The agent's authorization is delegated from a user, not granted directly to the agent. The audit trail needs to capture that delegation.
• They have time-bounded scope. An agent should not have standing access. The access should expire when the task completes or after a short timeout — whichever comes first.
• They can be challenged. When an agent encounters a high-risk action (financial transaction, identity change, data export), it should fall back to the human for explicit approval rather than auto-completing.

A service account that takes the agent role gets none of these properties. The audit trail conflates every agent action with the application's baseline access. The blast radius of a compromised credential is unbounded. None of this is acceptable for regulated workloads.

Why agents are not human users either

If service accounts are too coarse-grained, the alternative — running agents directly under the human user's identity context — has different problems:

• The audit trail is wrong. Every agent action looks like a human action. When an investigator asks "did the user actually do this?" there is no clean way to answer.
• MFA and step-up break. When the agent encounters a risk signal, the IDP wants to challenge the user. Most agent runtimes cannot pass that challenge through cleanly.
• Conditional Access policies misfire. An agent running on a server in us-east-1 looks like a user signing in from us-east-1 — except the user is in San Francisco. CA policies trip on the location mismatch.

The right pattern is delegation: the agent runs under its own identity, with explicit delegation from the user, scoped to the specific task and time window.

The operating-model pattern

What we recommend on engagements where AI agents are part of the workload:

1. Per-agent-session identity. Each agent invocation gets a short-lived identity (typically a JWT with a 15-60 minute TTL). The identity is bound to the user who delegated the task and to the specific scope.

2. Scoped delegation, not full impersonation. The agent gets a token that authorizes a specific subset of the user's permissions — not the full set. OAuth-style scoped delegation is the right primitive. Agent tokens should not be drop-in replacements for the user's session token.

3. Step-up to the human for high-risk paths. The agent can complete low-risk tasks autonomously. For high-risk actions (financial transactions, identity changes, data exports beyond a threshold) the agent must hand back to the user for explicit approval. The IDP's step-up mechanism should be the primitive — not custom code.

4. Per-action audit trail. Every action the agent takes is logged with three identifiers: the agent session ID, the user who delegated, and the specific scope authorized. The audit trail can answer "what did this agent do" and "what did this user authorize" as distinct questions.

5. Explicit revocation. When the user wants to revoke agent authorization, the IDP token revocation is the primitive. The agent gets immediately rejected on next call. No background polling, no cleanup job, no waiting for the token TTL.

Platform-specific notes

Microsoft Entra: The Verified Permissions / Cedar policy direction and the agentic identity primitives shipped in 2025 align with this pattern. Conditional Access can be scoped to agent-bearing claims.

Okta: Okta has shipped agent-identity primitives in 2026. The Okta Auth API now supports per-agent-session tokens with explicit delegation claims. The pattern is nascent but workable.

Auth0: Auth0 Actions support generating per-agent tokens with custom claims; the pattern requires more bespoke engineering than the Microsoft or Okta patterns but is achievable.

HashiCorp Vault: For agent secrets — credentials the agent uses to access downstream services — Vault's dynamic secret engines are the canonical primitive. Per-session credentials with short TTLs.

The bottom line

AI agents need their own identity primitives. Borrowing service-account credentials is the path of least resistance and the path to the worst audit findings. Engineering per-session identity, scoped delegation, and per-action audit trail is the right answer. The platforms have not fully caught up — but the patterns are clear enough to engineer against today.