Enterprise security rests on one assumption: a credential names a known, bounded, attributable actor. You issue a token believing you know what it will do. Agentic AI has knocked that assumption down.
AI agent identity answers three questions: which actor, acting for whom, within what scope. As IDC's Yih Khai Wong puts it, "a credential assumes the token holder is a known, bounded actor. An agentic system breaks that assumption." EMA/Cequence Security's survey of 202 enterprise technologists found 65% have seen an agent act outside its intended scope, while only 32.7% provision agents with least privilege.
This guide maps five arcs: the broken assumption, the enforcement gap, the missing delegation primitive, the identity-plane blast radius, and the standards gap. By the end you'll name the failure and route to its fix.
In This Series
- What AI Agent Identity Is and Why the Bounded-Actor Assumption Breaks: the definitional foundation.
- Runtime Authorisation and Why Identity-First Agent Security Falls Short: the analytical centre.
- The Missing Delegation Primitive and the Case for Ephemeral Agent Credentials: the credential model.
- Agent Identity Blast Radius, Blueprint Risk and the Entra versus SPIFFE Decision: the identity plane.
- NIST IR 8587, the Agent Scope Gap and Assessing IAM Readiness: the governance layer.
What is AI agent identity, and why does the bounded-actor assumption break?
AI agent identity is the set of claims that answers three questions: which actor, acting for whom, and within what scope. It breaks the bounded-actor assumption, the premise that a credential names a known, bounded, attributable actor whose behaviour can be scoped ahead of time. Agents are non-deterministic, two runs of the same prompt can produce different tool calls, and churn at machine scale, so one credential can no longer be pre-scoped to predictable behaviour.
Agents sit inside non-human identity (NHI) but exceed it in three ways: non-determinism, delegation, and tool-calling. The definition resolves into four parts: principal, delegator, scope, and lifecycle. Prompt injection lets a valid identity perform an invalid action, and a single request can fan out across many contexts. Read the full definition in what AI agent identity actually is, then move on to why identity-first controls leave the authorisation gap open and the credential model a bounded actor assumed.
What is the authorisation trap, and why do identity-first controls fall short?
The authorisation trap is the gap between proving who an agent is and permitting what it may do mid-task. Identity-first security authenticates a durable principal and binds broad permissions to it, but authorisation must be evaluated per action against live context. Agents carry a layered identity surface, static, dynamic, tool, and agent-to-agent, yet tooling sees only the static layer. The UK AISI incident showed agents acting outside authorised scope with approvals in place, the consent-fatigue failure mode.
Authentication answers "who"; authorisation has to answer "what, now, for this task." Zero Trust demands per-action verification at the tool boundary. This is why identity-first controls fall short, which follows from what a bounded actor was supposed to be and points toward where delegated authority must attenuate and why the standards body left agents out of scope.
Why is the delegation primitive missing, and why do agents need ephemeral credentials?
OAuth 2.0 expresses a client acting for a user with coarse scopes, but it can't tell you which agent instance acts for which user at which hop. Delegated authority must attenuate as it passes between agents: it narrows, never widens, and classic grants don't enforce that. The remedy is ephemeral, task-scoped, proof-of-possession credentials that shrink the exposure window, replacing the static API keys and long-lived tokens that impersonate users and outlive the task.
The emerging fills, the Identity Assertion JWT Authorization Grant, Transaction Tokens, and Rich Authorization Requests, point one way: authority only narrows as it moves. Exposure is duration × scope × reachability, not a single number. You'll find the full case in the missing delegation primitive, which grows out of the bounded actor a credential used to name and connects to runtime signals that catch impersonation and how identity-plane compromise turns a credential into blast radius.
What is the blast radius of an identity-plane compromise, and how do Entra and SPIFFE differ?
Blast radius is what one compromised agent identity can reach: inherited blueprints, cross-tenant access, and delegation chains. Microsoft Entra Agent ID embeds agents as directory objects whose blueprint-level grants fan out to dependent identities, widening that radius. SPIFFE and SPIRE instead issue attestation-based, portable workload identities. Your choice trades platform integration against interoperability, and the Midnight Blizzard breach shows why the radius matters.
Entra's object model is a template system: a blueprint, a blueprint principal, and the agent identity as the instance. Change the blueprint once and it propagates to all of them, sometimes across tenants. CrowdStrike, Arcjet, and Postman mark the race over where enforcement lives. That is the blast radius of an identity-plane compromise; the thread runs from the delegation chains a compromised blueprint can inherit through to what the standards still do not cover.
What does NIST IR 8587 cover, where is the agent scope gap, and how ready is your IAM?
NIST IR 8587, co-issued with CISA in September 2026, hardens token forgery and theft but explicitly places AI agent actions out of scope. The agencies acknowledge the gap and are developing guidance. That leaves the agent-specific authorisation problem unstandardised. Your readiness turns on four questions: defined owner, declared intent, bounded scope, and managed lifecycle, plus an inventory and immutable audit logging, anchored to NIST SP 800-207 Zero Trust and SP 800-53 controls.
IR 8587 hardens what happens after authentication, which matters because the token is the substrate agents abuse. Its silence on agent actions is the standards gap, made concrete by agents acting outside scope, the drift runtime authorisation catches. Read the standards gap and IAM readiness for the governance layer; it rests on the credential model readiness turns on and sits alongside the vendor race over enforcement boundaries.
Resource Hub: AI Agent Identity Deep Dives
The broken assumption and the enforcement gap
- What AI Agent Identity Is and Why the Bounded-Actor Assumption Breaks: why the bounded-actor premise fails.
- Runtime Authorisation and Why Identity-First Agent Security Falls Short: the authorisation trap and the UK AISI proof.
The credential and identity-plane mechanics
- The Missing Delegation Primitive and the Case for Ephemeral Agent Credentials: why OAuth can't express agent delegation.
- Agent Identity Blast Radius, Blueprint Risk and the Entra versus SPIFFE Decision: what a compromise inherits.
Standards and readiness
- NIST IR 8587, the Agent Scope Gap and Assessing IAM Readiness: the scope gap and how to assess your IAM.
Reading order: understanding, mechanics, readiness.
Conclusion
The through-line is the same: the boundary is moving below the agent, and the contest is over who owns the policy enforcement point.
If your question is what identity even means for an agent, start with what AI agent identity actually is. If your controls already authenticate agents and still see drift, start with why identity-first controls fall short. Then work through the missing delegation primitive, the blast radius of an identity-plane compromise, and the standards gap and IAM readiness.
Frequently Asked Questions
How do I know if an AI agent has acted outside its intended scope?
You usually find out after the fact. Static identity controls authenticate the agent at the start and then trust the session, so a valid identity performing an invalid action leaves no in-flight block. The reliable signal is immutable audit logging tied to declared intent: any tool call or cross-agent hop that falls outside that declaration is your scope breach. EMA found 65% of enterprise technologists have already seen one.
Is prompt injection just a prompt engineering problem?
No. Prompt injection is an authorisation problem wearing a prompt's clothing. When an injected instruction reaches the agent, it executes under a valid, authenticated identity, so filters and guardrails see a legitimate action. You cannot prompt your way out of it. The fix is per-action authorisation at the tool boundary, where every call is evaluated against runtime context rather than the agent's baseline permissions.
Can't I just use short-lived API keys instead of ephemeral credentials?
No. A short-lived API key is still a bearer token with a shorter clock. It is not bound to a task and does not prove possession, so anyone who lifts it can use it until it expires. Ephemeral agent credentials are task-scoped and proof-of-possession, meaning a stolen value is useless outside the specific task it was minted for.
What is proof-of-possession, and why does it matter for agent credentials?
Proof-of-possession means the holder must prove it controls a private key before the credential is accepted, rather than simply presenting it. It matters because bearer tokens fail the moment they leak: whoever holds the token becomes the agent. A proof-of-possession credential is useless to a thief without the key, which is why ephemeral agent credentials pair the two properties together.
Do I need to replace OAuth to secure AI agents?
No. OAuth stays, but it needs new delegation primitives on top. Classic OAuth expresses a client acting for a user with coarse scopes, not which agent instance acts for which user at which hop. The emerging fills, the Identity Assertion JWT Authorization Grant, Transaction Tokens, and Rich Authorization Requests, extend OAuth so delegated authority attenuates rather than widens as it moves.
What is the consent-fatigue failure mode?
Consent fatigue is when approval prompts arrive at such volume that reviewers rubber-stamp them, so consent exists on paper but carries no real scrutiny. The UK AISI incident exposed it: autonomous agents acted outside authorised scope even though approvals were in place. Volume of approval is not the same as quality of oversight, and identity-first tooling cannot tell the difference.
Why can't I just extend my existing IAM policies to cover agents?
Because IAM policies bind permissions to durable, predictable principals, and agents are neither. An agent is non-deterministic, delegates across hops, and calls tools mid-task, so a static policy cannot express the runtime context each action depends on. Authorisation must be evaluated per action and per task, which is a model IAM was not built to run.
What should an AI agent inventory actually capture?
At minimum: a defined owner, declared intent, bounded scope, and lifecycle state, plus the delegation chain the agent depends on. The inventory is the precondition for every governance question that follows, because you cannot bound, audit, or retire an agent you have not named. Treat it as the first readiness checkpoint, not a spreadsheet afterthought.
What happens if an agent's credential is stolen?
It depends entirely on the credential model. With a static key or long-lived token, the thief inherits the full identity and its permissions, including any cross-tenant access the blueprint grants. With ephemeral, task-scoped, proof-of-possession credentials, the stolen value expires quickly and cannot be replayed, so the exposure window collapses instead of the blast radius expanding.
How does agent-to-agent identity differ from agent-to-tool identity?
Agent-to-tool identity proves one agent may call one tool with a specific scope. Agent-to-agent identity has to carry the delegation chain: which agent is acting, for which user, and on whose authority it passed the task along. That chain is where attenuation matters most, because each hop must narrow authority rather than hand the next agent a wider grant.
How do I audit a non-deterministic agent?
You log every action against a stable agent identity and reconstruct the delegation chain after the fact. You cannot pre-scope behaviour you cannot predict, so the audit trail becomes the control. Immutable logging of each tool call, each hop, and each scope decision lets you prove what happened and trace any breach back to its origin.
Is Zero Trust enough on its own for AI agents?
Zero Trust points the right way, with its demand for per-action verification, but most implementations verify the principal once at session start and then trust the session. Agents break that habit because a valid identity can perform an invalid action. Zero Trust becomes sufficient only when verification moves to the tool boundary and runs for every action, not every login.