AI agent multi-hop delegation exposes OAuth’s trust chain limits

At a glance

What this is: This analysis shows that OAuth handles single-hop agent delegation, but multi-hop agent chains expose gaps in token exchange, auditability, and downstream trust.

Why it matters: IAM, NHI, and autonomous governance teams need to rethink how delegated access is represented, enforced, and audited when agents can spawn other agents.

By the numbers:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read WorkOS's analysis of AI agent multi-hop delegation and OAuth limits

Context

Multi-hop delegation is the point where agent identity stops behaving like ordinary OAuth-backed access and starts becoming a governance problem. A single agent can be traced through token exchange, but once that agent spawns others, the chain of authority becomes harder to represent, harder to validate, and much harder to audit across NHI and agentic AI programmes.

The issue is not authentication alone. It is whether the identity stack can preserve intent, scope, and accountability after multiple agents have delegated work across services, organisations, and approval boundaries. That is why the article sits at the intersection of OAuth, NHI governance, and emerging autonomous identity controls.

Key questions

Q: How should security teams handle agent delegation when one agent can spawn another?

A: Treat each hop as a separate governance event, not as a continuation of the first approval. Define who authorized the chain, what each agent was allowed to do, and where authority must narrow before the next hop can proceed. If you cannot trace that cleanly, the workflow is not ready for production use.

Q: Why do multi-hop AI agent workflows create more risk than single-agent automation?

A: Because each additional hop creates another place where scope can drift, tokens can be exchanged, and intent can be altered without a clear human checkpoint. The risk is not only compromise. It is semantic loss of control across a chain that still looks authenticated at every step.

Q: What breaks when OAuth is used as the only control for agent-to-agent delegation?

A: OAuth can show that a token was issued and exchanged correctly, but it cannot prove that downstream actions still matched the original authorization intent. In multi-hop workflows, that leaves policy, accountability, and semantic enforcement outside the token itself.

Q: Who is accountable when a spawned agent makes an unauthorized downstream decision?

A: Accountability should follow the delegation chain, not the last API call. The organization that designed the workflow, the team that granted the initial authority, and the operators who permitted the chain to continue all share responsibility for defining and enforcing the boundary.

Technical breakdown

Why OAuth token exchange breaks down across agent chains

OAuth token exchange was designed to represent delegated access when the path stays short and readable. RFC 8693 can express a chain with nested act claims, but those prior-actor claims are informational, not enforcement-grade. In a multi-hop agent flow, that means the token can describe the delegation path without making downstream access decisions depend on it. Once agents begin spawning other agents, the chain becomes longer than the control model that was built to validate it. The result is an identity record that is traceable in theory but weak in practice.

Practical implication: treat token exchange as a transport mechanism, not proof that every downstream hop remained within original authority.

What changes when agents can spawn other agents

Agent spawning creates a delegation topology rather than a simple caller-to-service relationship. Each hop can exchange credentials, narrow or widen effective context, and introduce a new place where policy may be interpreted differently from the previous hop. That is why the technical challenge is not only who authenticated, but how authority survives redistribution across agent-to-agent interactions. If the system cannot preserve monotonic permission reduction and actor continuity, the delegation chain becomes semantically unstable even when every API call is authenticated.

Practical implication: design runtime policy and token constraints for hop-by-hop authority loss, not static approval of the first actor.

Why audit logs miss the real failure mode

Audit systems usually record token issuance, token exchange, and API calls. They do not reliably capture semantic manipulation inside agent conversations, which is where multi-hop abuse often lives. A downstream agent may appear fully authorized while being nudged through a series of individually benign messages or tool calls that collectively produce an out-of-scope action. This is why the article's examples matter: the logging layer can show that each exchange succeeded, while the governance layer still cannot prove that the action matched the human's original intent.

Practical implication: pair audit logs with delegation-aware policy checks that can evaluate intent, scope, and hop lineage at runtime.

Threat narrative

Attacker objective: The attacker aims to turn legitimate agent delegation into an authorization path that produces unauthorized downstream actions while still looking valid to logs and token exchange systems.

1. Entry occurs when a compromised or manipulated agent gains influence inside a legitimate multi-agent workflow, rather than by breaking initial authentication.
2. Escalation occurs as the attacker uses one agent's trusted session or outputs to steer downstream agents into broader or unauthorized actions.
3. Impact occurs when the chained agents reach production data, financial actions, or other sensitive systems with authority that appears valid at each hop.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Multi-hop delegation is a trust-chain problem, not a simple OAuth problem. The article shows that a human can authorize the first agent correctly and still lose control once that agent spawns others. RFC 8693 can represent delegation, but it cannot make every hop enforcement-grade. The field should stop treating representable chains as governable chains.

Delegation chain splicing is a named failure mode the industry now has to account for. Once an attacker can insert themselves between legitimate agent hops, the security model collapses from a caller-service model into a manipulated actor chain. That failure mode is exactly why nested act claims and informational lineage are insufficient for agent governance. Practitioners should treat chain integrity as a first-class control objective.

Permission attenuation needs to become the default assumption for agentic delegation. Each hop should be able to do less, not more, than the previous hop, because agent spawning multiplies rather than isolates risk. The article's IETF drafts point toward monotonic attenuation and verifiable actor chains, which aligns with OWASP Agentic AI Top 10 and NIST AI Risk Management Framework thinking for autonomous systems.

Runtime policy must sit between agent identity and tool execution. Token validity alone does not answer whether an action still matches the current task, chain position, or human intent. That is the practical governance gap this article surfaces for NHI and autonomous programmes. Teams should treat agent-to-tool policy as the enforcement layer, not the token as the control.

Cross-domain delegation exposes the weakest part of identity governance: fragmented accountability. When a chain crosses organisations, each authorization server can validate only part of the path, while the auditor must reconstruct the whole story after the fact. That is not a logging problem alone. It is a governance assumption that breaks when control ownership is split across multiple trust domains.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments.
• That growth path matters because the OWASP Agentic AI Top 10 and the Ultimate Guide to NHIs both point to governance gaps that scale faster than manual review.

What this signals

Multi-hop delegation will force identity teams to move from token validation to chain validation. The practical question is no longer whether an agent was authenticated, but whether every hop in the delegation path remained within policy and intent. Programmes that still depend on isolated access reviews will struggle once agentic workflows become recursive.

Delegation chain splicing is the kind of control gap that will push organisations toward runtime authorisation and stronger provenance capture. The governance model has to account for who initiated the chain, which agent acted next, and whether the permitted scope narrowed at each step. That is a different operating model from human-centric SSO or ordinary service-account review.

AI agent identities should be treated as traceable non-human actors with lifecycle and policy controls, not as disposable integration glue. The more the workflow relies on spawned agents, the more the programme needs unique identity, scope attenuation, and auditable delegation lineage. This is where the Ultimate Guide to NHIs and the NIST AI Risk Management Framework become directly relevant to operational planning.

For practitioners

• Map every agent delegation chain end to end Record the human authorizer, each spawned agent, every token exchange, and every downstream service touchpoint so you can see where authority changes shape. This is the minimum basis for tracing multi-hop access across NHI and agentic workflows.
• Enforce hop-by-hop permission attenuation Require each delegation step to carry equal or lesser permissions than the previous hop, and block any agent from spawning a more powerful successor. Apply this to tool scopes, data access, and write actions.
• Move enforcement to the runtime policy layer Place a policy decision point between agent identity and tool invocation so the system can evaluate current task context, chain position, and action sensitivity before execution. This avoids relying on bearer token validity alone.
• Replace shared credentials with unique agent identities Give each agent its own credentials and audit trail instead of reusing API keys across the workflow. Shared credentials destroy attribution when an incident occurs three or more hops downstream.
• Bind sensitive actions to explicit human approval Route high-stakes operations such as production changes, regulated-data access, or financial actions through a verified human decision before the chain can continue. That keeps critical actions from being inferred only from prior delegation.

Key takeaways

• Multi-hop agent delegation breaks the assumption that a valid token chain is the same thing as controlled authority.
• The evidence now points to a real governance gap, with 52% of organisations able to audit AI-agent data access and 48% unable to do so.
• Practitioners need chain-aware runtime policy, hop-by-hop attenuation, and unique agent identities before spawned-agent workflows scale further.

Key terms

• Multi-hop Delegation: A delegation pattern where one agent spawns another agent, which may then delegate again before acting on a resource. In practice, authority becomes distributed across several runtime decisions, so the security model must preserve scope, lineage, and accountability at every hop.
• Delegation Chain Splicing: A failure mode where an attacker inserts or positions themselves between legitimate delegation hops and alters the apparent actor lineage. The chain may still look authenticated, but the trust path no longer reflects the original human authorization or the intended sequence of actors.
• Permission Attenuation: A control principle in which each delegated hop receives equal or lesser authority than the previous one. For autonomous or spawned agents, attenuation must be enforced at runtime, because the risk is not just over-privilege at issuance but privilege growth through chaining.
• Actor Chain Provenance: The verifiable record of which identities participated in a delegated action and in what order. This matters when multiple non-human actors are involved, because auditability depends on proving the chain, not merely proving that a token existed.

Deepen your knowledge

Multi-hop delegation, agent identity, and runtime policy are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are designing controls for spawned-agent workflows, it is worth exploring.

This post draws on content published by WorkOS: AI agents and the multi-hop delegation problem. Read the original.