AI agent authentication still depends on legacy IAM assumptions

At a glance

What this is: The article argues that AI agent authentication is still being handled through legacy IAM patterns that add governance overhead without fully solving delegation and access control.

Why it matters: This matters because identity teams now have to govern AI agents as non-human identities without assuming human-style approval, lifecycle, or review models will fit their runtime behaviour.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read WorkOS's analysis of Okta for AI agent security and WorkOS alternatives

Context

AI agent authentication is the problem of proving what an agent is, what it is allowed to access, and how that access is governed once it starts acting across multiple systems. The article frames that problem through an IAM lens, but the real challenge is that existing enterprise identity models were built for predictable delegation and slower control loops.

For security and IAM teams, the question is not whether agents can authenticate. It is whether the current control plane can govern agent-to-app delegation, audit access chains, and sustain least privilege when the identity is non-human and the runtime behaviour is more dynamic than a human session.

Key questions

Q: How should security teams govern AI agents that access multiple applications?

A: Treat each agent as a non-human identity with a defined owner, lifecycle state, and revocation path. Then map every downstream application, token exchange, and consent hop so delegated access can be audited end to end. If the application ecosystem cannot support consistent delegation context, keep the agent out of production workflows until it can.

Q: Why do AI agents complicate traditional IAM governance models?

A: Because IAM governance usually assumes access is granted to a known subject, then reviewed on a human or schedule-driven cadence. AI agents can initiate actions, chain access across systems, and change runtime behaviour faster than those review cycles can keep up. That makes delegation lineage and token scope more important than simple account ownership.

Q: What breaks when agent access is bolted onto existing IAM stacks?

A: The biggest failure is assuming the existing control plane can absorb new delegation patterns without redesign. If token scope, consent propagation, or downstream application support is inconsistent, the agent can inherit more access than intended and carry it farther than the original approval covered. Governance becomes fragmented across tools and owners.

Q: Should organisations use a dedicated AI agent identity model or extend current NHI controls?

A: Extend current NHI controls first, but only if they include ownership, scope, lifecycle, and revocation discipline. The mistake is treating AI agents as just another service account when they may combine permissions dynamically at runtime. A dedicated model is warranted when delegation chains span multiple applications and control ownership is unclear.

Technical breakdown

Cross App Access and delegated agent identity

Cross App Access extends OAuth-style delegation so an AI agent can act across multiple applications with auditable consent and token exchange. In practice, this creates a trust chain where the agent presents one identity but may carry delegated authority from a user into downstream systems. That is useful for traceability, but it also makes application participation mandatory, which slows adoption and creates interoperability gaps. The architectural issue is not authentication alone. It is whether downstream services can consistently interpret delegated intent, scope, and audit context across different control planes.

Practical implication: verify which applications actually support the delegation model before you design policy around it.

Identity security posture management for non-human identities

Identity security posture management for NHIs tries to discover service accounts, API keys, tokens, certificates, and agent identities, then map their permissions and misconfigurations. This is a governance layer, not an execution layer, so it can reveal risk but cannot by itself change runtime behaviour. The value is highest when the organisation needs inventory, permission analysis, and policy enforcement across many machine identities. The limitation is that posture tools often inherit the same complexity as the IAM stack they sit on top of, which can slow response and obscure the actual control owner.

Practical implication: use posture data to find unmanaged agent access, then tie each identity to a clear owner and remediation path.

OAuth, OIDC, and token chaining for AI agents

AI agent authentication in this model still rests on familiar protocols such as OAuth 2.0 and OIDC, but with added token chaining so an agent can combine its own identity with delegated user permissions. That means the security boundary shifts from login to authorisation context and token lifecycle. If token exchange, consent state, or audience scoping is weak, the agent can carry more privilege than intended into downstream systems. The architecture is powerful, but it amplifies any mistake in token handling because a single mis-scoped grant can span multiple apps.

Practical implication: inspect token audiences, consent propagation, and downstream scope inheritance before putting agents into production.

Threat narrative

Attacker objective: The objective is to turn one delegated identity into multi-application access that bypasses the normal scrutiny applied to each separate system.

1. Entry begins when a malicious actor or compromised workflow gains valid access to an agent credential, delegated token, or weakly scoped app integration.
2. Escalation occurs when that credential is chained across downstream services, letting the actor move from one application boundary into broader delegated access.
3. Impact follows when the agent or stolen token is used to read, modify, or exfiltrate data across multiple connected systems with little friction.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 being forced into control planes that were designed for slower, user-centric delegation. The article assumes that enterprise IAM can absorb agent access by extending OAuth and governance tooling, but that only works when the actor behaves like a predictable requestor. Once the agent can initiate, combine, and propagate access across applications, the underlying governance model starts to bend. Practitioners should treat this as a sign that identity architecture, not just product selection, needs re-evaluation.

Cross App Access exposes a delegation problem, not just an authentication problem. The important question is not whether an agent can present a token, but whether the receiving application can verify the delegation context, consent lineage, and downstream scope without introducing brittle coordination dependencies. That is especially relevant in mixed SaaS environments where not every app will implement the same protocol at the same pace. The implication is that policy consistency becomes a federation problem, not a single-platform feature.

Agent identity should be governed as a non-human identity with explicit lifecycle ownership. The article treats agents as first-class identities, which is directionally correct, but most organisations still lack disciplined lifecycle controls for machine credentials. That gap is visible in the broader market: only 20% of organisations have formal offboarding and API key revocation processes, according to our Ultimate Guide to NHIs. The practitioner conclusion is simple: if the agent can be provisioned quickly, it must also be traceable, owned, and revocable just as quickly.

Identity fabric language hides the fact that operational complexity is still the real barrier to secure adoption. Folding AI agents into a broader identity stack may improve visibility, but it does not remove the administrative burden of policy design, token governance, and application participation. For teams already overloaded with human IAM and NHI sprawl, the additional control surface can slow deployment and weaken accountability. Security leaders should expect agent identity governance to become a programme, not a feature.

Runtime delegation is the named concept teams should be tracking. That is the point where an agent’s access is no longer a simple login event but a chain of transitive permissions across systems, sessions, and tokens. Once delegation becomes runtime behaviour, the control question shifts from who logged in to how far the access chain can travel before it loses governance context. Practitioners should design for that boundary explicitly.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• To see how this gap plays out in real incidents, review 52 NHI Breaches Analysis for patterns in exposed credentials and delayed containment.

What this signals

Delegation lineage will become a core governance metric for agentic systems. If an AI agent can move across applications through chained tokens and consent, then security teams need a way to answer who authorised the chain, where scope expanded, and which control actually owns revocation. That is a different operating model from static app registration.

The broader market signal is that agent identity is not replacing NHI governance, it is stretching it. Teams that already struggle with service-account inventory, ownership, and offboarding will feel the same pressure with agents, only at higher speed and with more delegated context. For practitioners, the immediate task is to align identity architecture with runtime behaviour before the agent estate outgrows the control model.

Runtime delegation debt: When an agent’s usable access depends on multiple systems agreeing to trust the same token chain, every unsupported integration becomes an ungoverned edge. That creates hidden risk in mixed SaaS environments where a single control plane cannot guarantee consistent enforcement across the whole path.

For practitioners

• Map agent delegation chains end to end Document every application, token exchange, and consent hop an AI agent can traverse. Require an owner for each link in the chain so delegated access is not treated as an abstract platform capability.
• Inventory AI agents as managed non-human identities Assign each agent a named business owner, lifecycle state, and revocation path. Treat agent credentials, tokens, and service permissions as governed NHI assets, not application internals.
• Validate protocol participation before policy rollout Check which downstream applications actually support the delegation model before enforcing controls that depend on it. A policy that assumes universal support will fail where integrations are partial or inconsistent.
• Separate posture visibility from runtime authorisation Use discovery and permission analysis to find excess access, but do not confuse that with enforcement. Tie findings to concrete revocation and scope-reduction workflows.

Key takeaways

• AI agent authentication is an identity governance problem as much as a protocol problem.
• Delegation chains and token scope determine whether agent access stays bounded or spreads across systems.
• Ownership, lifecycle control, and revocation discipline are now mandatory for agent identities, not optional maturity work.

Key terms

• AI Agent Identity: An AI agent identity is the credentialed representation of software that can act on behalf of a user or system across tools and services. Unlike a simple workload account, it may combine delegation context, token scope, and runtime decision-making, which makes ownership and revocation more important than static authentication alone.
• Cross App Access: Cross App Access is a delegated access pattern that lets one application or agent reach multiple downstream services under a shared authorisation context. Its security value depends on consistent protocol support, clear consent lineage, and reliable auditability across every participating application.
• Delegation Chain: A delegation chain is the sequence of tokens, consents, and trust decisions that lets one identity act through another system. In agentic environments, the chain can widen quickly, so practitioners need to know where authority starts, where it expands, and where revocation actually takes effect.
• Non-Human Identity: A non-human identity is any machine credential used by software, workloads, integrations, or agents to authenticate and access systems. It is governed through ownership, scope, lifecycle, and monitoring, but it often fails when teams treat it like an incidental technical artifact instead of an identity with operational accountability.

Deepen your knowledge

AI agent identity governance and delegation chains are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending IAM into autonomous workloads or agent-enabled SaaS, it is worth exploring.

This post draws on content published by WorkOS: Okta for AI Agent Security: Features, Pricing, and WorkOS Alternatives. Read the original.