You can probably feel this one coming. The identity infrastructure your team relies on was architected two decades ago for humans: people who join, move, and leave on predictable timelines, who log in interactively, hold a role, and act inside a session. Agents do none of these things. They spawn and terminate in minutes. They make autonomous decisions across trust boundaries. They shift context across tasks in ways no role hierarchy can encode.
The infrastructure hasn’t moved. The agent population is doubling. Here is where the mismatch bites.
What is the AI agent identity crisis — and why is it happening now?
Fewer than half of security leaders can identify every active AI agent in their organisation. That is not a tooling gap. It is a category blindness. Most IAM consoles were not designed to surface non-human actors at all, let alone distinguish between a static service account and an autonomous agent that spawns sub-agents.
Start with the category. Non-Human Identity (NHI) is the umbrella term covering AI agents, service accounts, API keys, workload identities, and CI/CD pipeline credentials. It is a heterogeneous bucket, and treating everything in it the same way is the root vulnerability.
The ratios make the scale concrete. Non-human identities already outnumber humans by 80:1 to 144:1 in cloud-native enterprises. Palo Alto Networks reports 109:1 in their 2026 Identity Security Landscape. These are not edge cases. They are the operational reality of any organisation running microservices, SaaS integrations, and automated pipelines.
Now layer in the growth vector. Gartner projects 150,000 AI agents per organisation by 2028, up from perhaps 15 today. That is an 18-to-24-month horizon, not a five-year one. And the harm is already happening: 91% of organisations are already using AI agents, and 80% have experienced unintended agent behaviour.
An AI Agent Identity is the specific subclass of NHI that makes this urgent. Three things set it apart from a service account: it decides what to do at runtime rather than following fixed code paths, it acts on someone else’s behalf, and it can spawn sub-agents. You cannot pre-provision access for something that decides what to do as it goes. (For the broader crisis this identity problem sits inside, see the three-pillar breakdown.)
How do AI agents differ from service accounts and API clients from an identity perspective?
The instinct you probably reach for first is “why can’t we just treat them as service accounts?” That instinct is wrong, and the reasons are structural.
A service account does one predictable thing as itself. Its behaviour is defined in code, its scope is fixed at provisioning time, and its lifecycle is measured in months or years. An AI agent does many unpredictable things on behalf of someone else. Its behaviour is produced at runtime by model inference, its scope must be decided per request, and its lifecycle may span minutes.
The differences run across five dimensions. Behaviour origin: code versus model inference. Agent behaviour changes without a deployment when the system prompt, model version, or conversation context shifts. Scope model: provisioned versus runtime-evaluated. Identity model: acts as self versus acts on behalf of a delegating user. Auditability: deterministic log line versus reasoning trace with user-intent attribution. Lifecycle: months-to-years versus minutes-to-hours.
The Static API Key is where this difference turns into a vulnerability. A long-lived bearer token assumes the credential holder is predictable: same endpoints, same cadence, same scope. Agents are none of those things. The API key model embeds no per-request context, no delegation record, and no mechanism for scoping down mid-task. When your team reaches for static keys to authenticate agents, you inherit all three limitations at once.
What happens in practice is predictable, and it is the same pattern across organisations: shared credentials across agent fleets, over-permissioned roles because runtime needs are unknown at provisioning time, and hardcoded API keys that outlive the agents themselves. Treating agents as service accounts creates the insecure defaults. (This credential sprawl also feeds directly into the cost problem explored in ART002.)
Why do traditional IAM systems collapse when applied to autonomous AI agents?
Traditional IAM was built for human-scale lifecycle events: join, move, leave. Static role assignments, long-lived credentials, interactive authentication, and session-based access. Agents break all three core assumptions. Of the five dimensions where agents differ from service accounts, three produce failure modes in traditional IAM right now.
Static credential leakage is the first. An agent carrying a long-lived API key or OAuth token exposes that credential to every input channel the model processes. Traditional IAM has no mechanism to revoke a credential mid-task based on what the agent is being asked to do. Revocation is an out-of-band, human-driven process, and agents do not wait for humans. The architecture assumes the credential holder stays within a known threat surface; agents expand that surface at runtime with every tool call.
Role assignment collapse is the second. RBAC assumes a human with one job function. An agent shifts context across tasks: in one minute it reads a calendar, in the next it queries a CRM, then it touches a payment API. Encoding this dynamism into static roles produces either a combinatorial explosion of micro-roles or a single over-permissioned agent carrying everything it might need. The role explosion anti-pattern, familiar to IAM architects, becomes untenable at agent scale.
Session-based access at the wrong timescale is the third. Traditional IAM evaluates access at session creation. A token is issued, and for its lifetime (often hours) it is treated as valid. An agent making sub-second decisions across dozens of tool calls needs access evaluated at each call, not at login. A risk signal that arrives 30 seconds into an agent’s task is invisible to a session-based model. Palo Alto Networks’ Unit 42 documented one version of this, Agent Session Smuggling, which exploits stateful agent-to-agent sessions by injecting covert instructions, precisely because the token remained valid when it should not have. (These three failure modes form the diagnostic framework that ART003’s readiness assessment operationalises.)
What is delegated authority for AI agents, and how does it differ from credential sharing?
So the old model breaks in three specific ways. Here is what replaces it, starting with the most fundamental shift: the agent does not need your credentials. It needs a scoped, auditable, time-bound permission derived from them.
Take a concrete case. An agent booking a meeting on your behalf needs calendar write access. It does not need email read access. If you share your full credentials with the agent, two things break: the agent has access to everything you have (violating least privilege), and the audit trail cannot distinguish your actions from the agent’s (breaking accountability).
Delegated authority, implemented through OAuth 2.0 Token Exchange (RFC 8693), solves this. The agent exchanges its own credential for a scoped access token that carries an act (actor) claim identifying the delegating user. The resulting token is cryptographically verifiable, scoped to specific actions, time-bounded, and records the delegation in audit trails. This is the “on-behalf-of” pattern.
It is distinct from both impersonation (the agent pretending to be you, which obscures accountability) and credential sharing (giving the agent your password, which creates an over-privileged, unauditable actor).
But RFC 8693 has a stated limitation. Nested act claims, the prior actors in a delegation chain, are informational only and must not be considered in access control decisions. This means OAuth can represent a three-hop chain (Human, Agent A, Agent B, Service C) but cannot enforce it. Each hop issues a new bearer token. Attenuation, the principle that each hop should have equal or fewer permissions than the one before it, is not built into the standard.
Four active IETF drafts are working on different pieces of this: attenuating tokens, verifiable actor chains, cross-domain chaining, and TLS-session-bound tokens. None are ratified. For now, delegated authority via OAuth token exchange is the minimum viable pattern for single-hop delegation. For multi-hop scenarios, adopt privilege attenuation as a design principle and watch the standards trajectory. (The delegation model you choose is the single largest determinant of platform fit; ART004’s evaluation framework depends on understanding this distinction.)
Why does RBAC fall short for AI agents, and what makes fine-grained authorisation different?
Delegation solves whose authority the agent carries. The next question is how access gets decided at the moment of each tool call.
RBAC asks “what role are you?” That question works for humans with stable job functions. It collapses for an agent that reads a CRM record, updates a billing system, and queries a knowledge base across three trust domains inside a single task. Encoding this as roles produces either a combinatorial explosion or a single over-privileged role.
Fine-Grained Authorisation (FGA) shifts the question to “what resource, action, and context tuple is permitted right now?” The decision is computed at request time, not provisioned at role-assignment time.
The architecture to look at here is Google Zanzibar and the Relationship-Based Access Control (ReBAC) model that came out of it. Permissions derive from relationships in a graph: agent_A acts_for user_X, resource_Y belongs_to tenant_Z, user_X is_member_of tenant_Z. When the agent requests access, the authorisation engine traverses the graph to find whether a permission path exists, rather than checking for a static role assignment.
Layer in Attribute-Based Access Control (ABAC) and you get the full picture. Attributes of the subject (agent identity, delegating user), action (read, write, delete), resource (classification, region, ownership), and environment (risk score, time of day, network context) combine to produce a decision. Put together, these three layers define FGA: ReBAC plus ABAC plus runtime evaluation.
Consider an agent that needs read access to one customer record, in one region, for one action, in one five-minute window. RBAC would require a role defined for that exact combination, or more likely, a broad role that grants access to all customer records everywhere. FGA evaluates the tuple at request time and returns allow or deny. RBAC still has a place for coarse boundaries (this agent fleet may access the EU production environment). But FGA handles the per-request decisions agent autonomy demands. (FGA has direct cost implications: per-request authorisation evaluation adds latency and compute at agent scale, the re-sent cost problem explored in ART002. It is also the identity-architecture pillar’s answer to the permissions dimension of the broader crisis.)
Traditional IAM versus AI-driven IAM: what actually changes?
The transition from traditional to AI-driven IAM is a rearchitecture across four axes, not a feature upgrade to your existing stack.
Credential model: static to dynamic. Traditional IAM issues long-lived credentials at provisioning time. AI-driven IAM issues short-lived, dynamically scoped credentials at task start, bound to the specific agent, user, and intended actions, often with lifetimes measured in minutes. Just-in-Time credential issuance replaces standing credentials.
Access evaluation: session-based to continuous. Traditional IAM evaluates access once and trusts the session until expiry. AI-driven IAM evaluates every request against current risk posture. Continuous Access Evaluation (CAEP) is the engine: real-time signals (device posture change, location anomaly, threat intelligence feed) trigger re-evaluation, and the Shared Signals Framework (SSF) enables near-instant revocation when risk thresholds are crossed.
Authorisation granularity: role to resource-attribute-context. Traditional IAM answers “what role are you?” once. AI-driven IAM answers “what tuple is permitted right now?” for every request, using FGA as the policy engine.
Lifecycle velocity: human-paced to machine-speed. Traditional IAM assumes identities that persist for months, with provisioning driven by HR events and quarterly access reviews. AI-driven IAM assumes identities that may exist for minutes, requiring automated provisioning, rotation, and decommissioning at machine speed.
Microsoft (Entra Agent ID, SSF) and Okta (Identity Security Fabric) are both pushing toward agent-aware IAM from different architectural starting points. They are the platforms you will encounter these concepts through.
The moment you deploy an agent that makes autonomous, chained decisions across trust boundaries, the traditional model is already failing. This is not a comparison exercise. The only question is at what scale the transition becomes non-negotiable, and the data suggests that threshold is lower than most teams assume. (The four-axis comparison gives you the evaluation rubric for ART003’s readiness assessment. The credential-model and lifecycle axes directly inform the platform-evaluation criteria in ART004.)
The five mismatches (identity category, credential model, delegation, authorisation granularity, and access evaluation cadence) share one root cause: IAM was designed for human actors and never redesigned for autonomous ones.
Delegated authority via OAuth token exchange works for single-hop delegation today. It is not enough for the multi-hop world that is arriving. The IETF drafts that will close this gap are in flight. Adopting privilege attenuation as a design principle now positions your architecture to adopt them when they land. The four axes above are how you evaluate whether an IAM investment gets you there: ask whether it shifts the credential model toward JIT, access evaluation toward continuous, authorisation granularity toward resource-attribute-context, and lifecycle toward machine speed. An investment that preserves the old model on any of these axes addresses the symptoms while the architectural mismatch remains.
Frequently Asked Questions
Can’t I just enforce MFA on my AI agents?
No, and attempting it reveals the category error. Multi-factor authentication assumes a human who can receive a push notification, enter a code, or present a biometric. An agent has none of those channels. It authenticates programmatically at machine speed. The correct analogue is not “MFA for agents” but cryptographically attested workload identity: the agent proves what it is, where it runs, and who deployed it, validated at every request, not at a single login event.
How do I know if my organisation already has unidentified AI agents running?
Start with a credential inventory that distinguishes bearer tokens used by humans from those used by automated callers, then audit for patterns: high-frequency, low-latency API calls across unrelated endpoints, tokens active outside business hours making decisions no cron job would make, and credential usage that shifts endpoint patterns week to week. Most organisations running a modern SaaS stack and CI/CD pipeline will find agents they did not formally provision. The SailPoint finding that 80% of organisations have observed unexpected agent behaviour is not theoretical.
What is the difference between an AI agent and a bot?
Bots follow deterministic scripts: if this input, then that output, every time. An AI agent uses a language model to interpret its task at runtime and decide which tools to call, in which order, with what parameters. That non-determinism is the identity-relevant distinction. A bot’s access needs can be predicted at provisioning time. An agent’s cannot, because neither the developer nor the user knows exactly what tool chain the model will assemble until it runs. The agent is making access decisions, not just following them.
Who is accountable when an AI agent makes a bad access decision?
The delegating user carries the accountability, which is why the delegation record matters. Under the OAuth token exchange model, the agent’s access token carries an act claim that cryptographically binds the action to the human who authorised the delegation. If the agent exceeds its scope, the audit trail distinguishes “agent acted within granted permissions but made a poor decision” from “agent accessed something it was never authorised to touch.” The first is an AI safety problem. The second is an identity control failure, and it belongs to the team that provisioned the agent.
Do I need to replace my existing IAM system to support AI agents?
Not all at once, but you do need to layer new capability alongside it. Your current IAM can remain the system of record for human identities and coarse-grained access boundaries. What you add is an authorisation layer that evaluates per-request, per-resource, per-context decisions at agent speed: a policy engine that speaks ReBAC or ABAC, a credential issuance pipeline that produces short-lived tokens bound to specific tasks, and a continuous evaluation feed that can revoke access mid-task when risk signals fire. The architectural commitment is to stop treating agent access as a provisioning-time decision.
Is the AI agent identity crisis only a problem for large enterprises?
No. The NHI-to-human ratios that make headlines (80:1, 144:1) are from cloud-native enterprises, but the underlying mismatch hits any organisation that deploys an agent making autonomous decisions across trust boundaries. A ten-person startup running a customer-support agent that reads a CRM, updates a billing record, and queries a knowledge base has the same architectural problem as a bank running ten thousand agents. The difference is scale: the startup might get away with over-permissioned credentials for six months, while the bank cannot. But the failure mode is identical.
How does agent identity affect SOC 2 or ISO 27001 compliance?
Both frameworks require that access be authorised, reviewed, and revoked on a timely basis, and that the entity taking the action be identifiable in audit logs. When an agent acts under a shared service account credential, you fail on all three: the authorisation is too broad, the review cycle is too slow, and the audit log cannot distinguish the agent from the cron job from the pipeline. An agent-specific identity model, with per-agent credentials and delegated authority recorded in the token, is what turns “we have agents” into “we can demonstrate control over what our agents do.”
What is the first step my team should take to prepare for agent identity?
Run an NHI discovery audit that categorises every non-human credential in your environment by behaviour pattern, not just by type. Separate static service accounts from dynamic callers, map the credential-to-resource access graph, and identify which credentials are shared across multiple workloads or teams. This gives you a baseline of the gap between what you think is running and what is actually running. Until you can count your agents, you cannot govern them. Most teams discover the gap is larger than they expected, and that discovery is what funds the next conversation.
How is agent identity different from Kubernetes workload identity?
Kubernetes workload identity answers “which service account is this pod running under?” and binds a predictable, namespaced identity to a long-running workload. Agent identity must answer “which agent, acting for which user, in which task context, right now?” The Kubernetes model assumes a stable pod with a stable role. An agent may spawn, execute three tool calls across two trust domains, and terminate inside a single minute. Workload identity is a useful foundation (attesting where the agent runs), but it does not solve the delegation, scoping, or continuous evaluation problems that agent autonomy creates.
How do I explain the AI agent identity risk to my board or executive team?
Frame it as an accountability gap, not an identity architecture problem. The board cares about who is responsible when something goes wrong. The question to put to them: “If an AI agent we deployed made a decision that caused a regulatory breach, a data leak, or a financial error, could we prove which agent did it, who authorised it, and why it had access in the first place?” If the answer is no, and for most organisations today it is, the identity controls are not fit for purpose. The Gartner projection of 150,000 agents per organisation by 2028 makes the timeline concrete: this is not a theoretical risk you have five years to address.
