By NHI Mgmt Group Editorial TeamBased on WorkOS: “Okta for AI Agent Security: Features, Pricing, and WorkOS Alternatives” (November 3, 2025)

TL;DR: AI agents are being folded into enterprise identity control planes through protocols like XAA, but the article argues that enterprise complexity, preview status, and coordination overhead still limit practical adoption, according to WorkOS. The deeper issue is that agent identity is being treated like a normal delegated session when runtime autonomy and cross-app access change the governance model.


At a glance

What this is: This comparison argues that AI agent authentication still depends on legacy IAM assumptions, especially when delegation, cross-app access, and auditability are pushed through human-era control planes.

Why it matters: It matters because IAM, PAM, and NHI programmes have to decide whether to adapt existing identity controls for agentic access or treat agent identity as a distinct governance problem.


Context

AI agent identity is the problem of how software systems that act on behalf of users are authenticated, authorised, and audited across multiple services. The article argues that legacy IAM assumptions still dominate this space, even as agents increasingly need delegated access that crosses application boundaries.

That matters because the control model for a human session does not map cleanly to an agentic workflow. Once an agent needs to chain tokens, carry delegated consent, and move across systems, identity governance becomes a runtime question rather than a provisioning exercise.


Key questions

Q: What fails when AI agents are governed like normal user sessions?

A: The control model fails when it assumes one person, one login, and one bounded session. AI agents can chain permissions across systems, so the real risk is delegated authority expanding beyond the original approval context. Identity teams need controls that follow the workflow, not just the initial authentication event.

Q: Why does cross-app delegation increase AI agent security risk?

A: Because each additional service in the chain becomes another place where scope can widen, consent can be misunderstood, or revocation can lag. Cross-app delegation is risky when teams can no longer prove exactly what the agent is allowed to do at each hop. That is an identity governance problem, not just an API integration issue.

Q: What are the signs that an organisation has weak governance over AI agents and machine identities?

A: Weak governance shows up when teams cannot say how often AI systems make changes, when policies for AI agents are missing, or when access decisions are based on convenience rather than need. Another warning sign is heavy reliance on static credentials despite autonomous systems. Those conditions usually indicate limited visibility, weak accountability, and poor control over machine-driven access.

Q: Should organisations use human IAM patterns for agentic AI systems?

A: Only as a starting reference, not as the operating model. Human IAM assumes a stable person, a durable session, and clear intent, while agents can act, delegate, and change scope dynamically. Teams need agent-specific identity, continuous verification, and finer-grained authorisation if they want control to survive autonomy.


Technical breakdown

Why delegated access breaks human session assumptions

Legacy IAM assumes a user authenticates into a session, then uses bounded permissions until that session ends. AI agents change that model because they may initiate actions across several downstream services while carrying delegated authority from a user, application, or service account. OAuth and OIDC still matter, but they are no longer enough by themselves when the same identity can trigger multi-step, cross-app activity. The governance problem becomes how consent, scope, and revocation behave when the actor is software acting dynamically rather than a person following a fixed path.

Practical implication: treat delegated agent access as a distinct governance pattern, not as a normal extension of human SSO.

What token chaining means for audit and control

Token chaining describes a sequence where one identity assertion is exchanged for another as an agent moves between services. That can preserve continuity, but it also makes audit trails harder to interpret because the effective authority may be assembled from several steps rather than one static credential. XAA-style delegation aims to make that chain visible, yet it also depends on every participating application supporting the same protocol and policy logic. In practice, visibility and enforceability rise or fall together. If downstream systems cannot understand the same delegation semantics, the control plane fragments.

Practical implication: map where delegated authority changes form so you can see where audit evidence will break apart.

Why identity security posture management now includes AI agents

Identity security posture management extends governance into non-human identities by discovering accounts, permissions, and misconfigurations across service accounts, API keys, and AI agents. That is a useful shift because agent risk often appears first as excess privilege, stale scope, or unclear ownership. But posture management only works if the organisation can classify which identities are agents, what they are allowed to do, and how those permissions are revoked when the workflow changes. Without that classification, posture tooling becomes inventory without accountability.

Practical implication: keep agent inventory, privilege scope, and ownership in the same governance workflow.


Threat narrative

Attacker objective: The objective is to convert a legitimate delegated identity into broad cross-system access with enough scope to perform high-impact actions.

  1. Entry occurs when an AI agent receives delegated access through human approval, a service account, or a token exchange into downstream systems.
  2. Escalation follows when the agent accumulates cross-app scope, allowing it to act beyond the narrow task that originally justified access.
  3. Impact emerges when the combined delegation chain gives the agent enough authority to read, modify, or trigger actions across multiple enterprise systems.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Legacy IAM for AI agents is an assumption problem before it is a tooling problem. Human-era IAM assumes a stable subject, a predictable session, and a bounded path of delegated use. AI agents break that mental model because they can move across applications, combine permissions at runtime, and complete work without a person watching each step. The implication is that identity control for agents must be designed around runtime behaviour, not around static user-session logic.

Delegation chains are the governance surface, not just the authentication event. When an agent exchanges tokens across services, the meaningful question is not whether login succeeded but where authority can travel and how far it can compound. That shifts the centre of gravity from login assurance to delegation integrity, scope control, and revocation visibility. Practitioners should treat cross-app propagation as the primary identity risk.

Named concept: identity delegation drift. Agent authority drifts when the permissions carried through a task no longer match the original approval context, especially across multiple applications. That drift is subtle because each hop can look legitimate in isolation while the chain as a whole becomes over-broad. Identity teams need to see drift as a structural governance failure, not a simple misconfiguration.

Enterprise bureaucracy is now part of the security trade-off for agent identity. Heavy governance stacks can improve control depth, but they also raise the cost of adoption and slow the feedback loop that modern SaaS teams need. The field is splitting between environments that can absorb enterprise identity overhead and environments that need lighter-weight, production-ready delegation patterns. Practitioners should align control depth with operating model, not with vendor category.

Agent identity will be governed as NHI first, then specialized for agentic behaviour. The foundational controls are still inventory, ownership, privilege scope, and revocation, which are classic NHI concerns. What changes is the runtime nature of use, where the identity may act, chain, and terminate within a workflow rather than persist as a stable account. Teams should expect agent governance to sit on an NHI base layer with agent-specific policy on top.

From our research library:

What this signals

Identity delegation drift: the governance break is not the login event but the way authority changes form as an agent moves across applications. Once delegated scope can be recombined at runtime, classic session governance stops telling the whole story.

The practical boundary now sits at issuance and propagation, not at authentication alone. Teams that cannot explain where an agent gained, carried, and shed authority will struggle to prove least privilege in production.


For practitioners

  • Define agent identities as governed non-human identities Create a distinct inventory for AI agents, with ownership, purpose, approved systems, and revocation authority recorded alongside service accounts and API keys.
  • Bound delegated scope by task and downstream system Limit what an agent can do after token exchange so cross-app permissions cannot silently expand beyond the original use case.
  • Track delegation chains in audit logs Log each identity handoff, token exchange, and consent event so reviewers can reconstruct where authority changed form.
  • Separate preview capabilities from production policy Do not base production governance on features that are still early access or developer preview when the identity path carries real enterprise risk.

Key takeaways

  • AI agent authentication still inherits human-era IAM assumptions, which leaves delegated authority and cross-app access harder to govern than ordinary sessions.
  • The control problem is not limited to login success. It is about whether scope, consent, and revocation remain intelligible after an agent starts chaining access across systems.
  • IAM teams should treat agent identity as governed NHI with explicit delegation controls, or they will keep certifying the wrong layer of risk.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationThe article centres on how AI agents authenticate and carry delegated authority across services.
NHI-05 — Overprivileged NHIThe article repeatedly highlights excess scope and broad downstream access for agents.
NHI-09 — NHI ReuseToken chaining and repeated delegation across apps create identity reuse risks for agents.
Recommendation — Apply NHI-04 to validate how agent credentials are issued, exchanged, and constrained across systems. Use NHI-05 to cap agent permissions at the smallest task-scoped access set possible. Audit where one agent identity is reused across multiple workflows and separate those trust boundaries.
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseThe article’s core concern is whether agent privileges can expand beyond their intended role.
Recommendation — Map agent delegation paths to ASI03 and constrain any privilege that can be amplified at runtime.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is about governing agent entitlements as they move across apps.
Recommendation — Review agent entitlements under PR.AA-05 and remove any access that is not explicitly task-scoped.

Key terms

  • AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
  • Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.
  • Token Chaining: Token chaining is the exchange of one credential or assertion for another as an identity moves through multiple services. For agentic workflows, it can preserve continuity, but it also makes audit and revocation harder because effective access is assembled across several hops rather than held in one place.
  • Identity Delegation Drift: Identity delegation drift is the gradual expansion of permissions originally granted for a narrow workflow into broader, persistent access. It often appears in automation and AI tooling where convenience overrides review, leaving organisations with standing trust they no longer understand or need.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org