Delegated Human Context Across Agent-to-Agent Chains

Abstract

Agentic AI systems introduce an identity problem that becomes visible when agents begin calling other agents. In a simple single-agent model, OAuth2.1 authorisation can capture user consent and issue a scoped access token to one agent. That model works when the user is present, the same agent requests and uses the token, and the scope of the action is known at consent time.

Multi-agent systems break these assumptions. A user may interact with one orchestrating agent, while that agent delegates work to specialised downstream agents. If each downstream agent requires its own authorisation grant, users face repeated consent prompts, grants become difficult to reason about, and the system loses a clear view of which grant is authoritative.

A sound agent-to-agent identity model must preserve the original human user context through every hop. Each downstream action should carry the original user, the acting agent, and the full delegation path that produced the request.

1. Introduction

An AI assistant that queries data, invokes tools, and coordinates services is not just one workload making authenticated API calls. It may represent a chain of authorised actions, each executed by a different agent process and each implicitly claiming that the original user sanctioned what is happening.

Traditional service-to-service identity usually asks:

“Is this service the service it claims to be?”

Agentic systems must also ask:

“Is this service authorised to act on behalf of this specific user, for this specific purpose, to this specific extent?”

This shift becomes critical when agents call other agents. A valid workload identity can prove which agent made a request, but it does not, by itself, prove which human authorised the action or how the request moved through the agent chain.

The design principle is:

Agent-to-agent calls need provenance. Every downstream action should carry the user, the acting agent, and the full delegation path.

2. The Single-Agent OAuth2.1 Model

In the single-agent case, the OAuth2.1 authorisation code flow provides a clean model.

The user is redirected to an authorisation server, sees the scopes requested by the agent, grants consent, and the agent receives an access token scoped to what was approved. The agent then presents that token to resource servers, which validate it and enforce the scope.

In this model:

This works because the interaction is simple: one user, one agent, and one grant. The agent that requests the token is the same agent that uses it.

However, this model depends on three assumptions:

1. The user is present at authorisation time.

2. The agent requesting the token is the agent using it.

3. The scope is known and finite when consent is granted.

These assumptions begin to fail in multi-agent systems.

3. Where Multi-Agent Orchestration Breaks the Model

A common agentic architecture uses a central orchestrator between the user and several specialised agents. The user interacts with one interface, while the orchestrator delegates work to downstream agents such as retrieval, execution, or notification agents.

Under a naive OAuth2.1 model, each downstream agent is treated as a separate OAuth2 client requiring its own authorisation grant. This leads to repeated consent prompts for the same or overlapping scopes within one user session.

The problem is not only user experience. Multiple independent grants create authorisation ambiguity:

• Which grant is authoritative?

• How does revocation propagate?

• Does the combined set of grants exceed what the user intended?

• Which agent holds which permission at which point?

The user may believe they approved one system to perform one task, while the identity layer has created several separate grants across internal agents.

4. Agent-to-Agent Call Chains and the Confused Deputy Problem

The more serious breakdown occurs when agents call agents.

User -> Agent 1 -> Agent 2 -> Agent 3 -> Resource Server 

Agent 2 may receive a request from Agent 1 and need to call a resource server on behalf of the original user. But the token available to Agent 2 may identify Agent 1 as the caller, or Agent 1 may simply forward its own access token.

This creates the confused deputy problem. Agent 2 is being asked to act for the user, but it may not hold a token that correctly represents both the original user and Agent 2 as the current actor.

Three common alternatives fail:

The result is an identity chain that cannot reliably prove who authorised the downstream action or which agent is currently responsible for it.

5. The Audit Trail Collapse

Without a coherent delegation model, audit logs become incomplete.

If Agent 3 modifies a resource, the log may show only Agent 3’s client ID. It may not show that Agent 3 was called by Agent 2, which was called by Agent 1, which was acting on behalf of a user who approved a specific set of actions.

The missing piece is the causal chain: the record of human intent that produced the machine action.

This is not only an observability gap. In systems where agent actions modify data, initiate transactions, or send communications on a user’s behalf, the inability to reconstruct the authorisation chain is a fundamental identity failure.

6. RFC 8693 Token Exchange and the Delegation Model

The solution is a delegation model that preserves human principal context through the full agent chain, at every hop, in a verifiable and inspectable form.

RFC 8693 OAuth 2.0 Token Exchange defines a mechanism for exchanging one token for another that represents a delegated or impersonated identity.

In the delegation pattern, the resulting token carries both:

The act claim can itself contain a nested act claim representing the previous agent in the chain.

For example:

User -> Agent 1 -> Agent 2 -> Agent 3 -> Resource Server 

A token presented by Agent 3 can represent:

sub = original user

act = Agent 3
  act = Agent 2
    act = Agent 1 

The resource server can now inspect the full delegation path. It knows who the user is, which agent is currently acting, and which agents delegated the request.

This makes the audit trail recoverable because every token at every hop carries the provenance of the request.

7. Impersonation Versus Delegation

RFC 8693 supports both impersonation and delegation, but they have different security and audit properties.

Impersonation may be suitable in narrow cases, such as a support tool acting as a user for administrative purposes. But for agentic systems where the agent identity matters for authorisation, audit, or rate limiting, delegation is almost always the correct pattern.

A system built on impersonation is difficult to retrofit with agent-level audit later, because the agent identity was not carried in the token from the beginning.

8. Delegation Solves Identity Propagation, Not Scope Integrity

Delegation preserves the user and agent chain, but it does not automatically prevent scope expansion.

A downstream agent might exchange a token and request the full scope it received. Worse, it might request scopes that were not present in the upstream token. If the authorisation server does not enforce constraints, token exchange can become a privilege escalation path.

The principle should be:

Each hop in a delegation chain can only carry equal or lesser scope than the token it received.

Agent 2 cannot request scopes absent from Agent 1’s token. Agent 3 cannot request scopes absent from Agent 2’s token. Scope can narrow through the chain, but it must never expand.

RFC 8693 permits a scope parameter in the token exchange request. The requesting agent can use this to declare the scopes needed for the downstream call, while the authorisation server enforces that the requested scopes are a subset of the subject token’s scopes.

9. Implementation Considerations for Keycloak-Based Systems

Keycloak provides building blocks for this model, but several implementation decisions matter.

9.1 Token exchange permissions should follow the call topology

Token exchange is controlled through client-level permissions. Token exchange between arbitrary clients should not be broadly allowed.

The permission model should reflect the intended agent chain:

Agent 2 may exchange tokens issued to Agent 1.
Agent 3 may exchange tokens issued to Agent 2. 

Broad permissions such as allowing any client to exchange tokens issued to any other client weaken the delegation model.

9.2 Resource servers must understand the act claim

When token exchange uses delegation rather than impersonation, Keycloak includes the act claim in exchanged tokens and returns it through introspection.

Resource servers that need to authorise based on the full delegation chain must explicitly read and interpret the actclaim. Most OAuth2 client libraries do not do this by default, so this behaviour must be implemented and tested.

9.3 Scope and lifetime controls must be deliberate

Keycloak supports scope constraints at the policy level, but strict scope integrity requires explicit configuration. Systems that require strong control may also need custom handling for scope violations.

Downstream token lifetimes also need attention. An exchanged token should not outlive the upstream token that produced it. Otherwise, downstream authority may survive after the original authority expires or is revoked.

10. Design Checklist

Before deploying agent-to-agent identity, teams should answer:

11. Conclusion

OAuth2.1 works well for a simple single-agent interaction, but multi-agent systems break its core assumptions. Repeated consent is unusable, token forwarding breaks audience binding, client credentials lose the human principal, and re-authorisation at every hop is impractical.

A delegation model solves the identity propagation problem by carrying the original user and the acting agent chain through every hop. RFC 8693 OAuth 2.0 Token Exchange provides the mechanism. The sub claim preserves the original user, while nested act claims represent the agents that handled the request.

For agentic AI systems, the key lesson is:

Authenticating agents is not enough. Every downstream action must preserve who authorised it, which agent is acting, and how the request reached that point.

Writer’s Overview

Ajit Gupta – Co-Founder & CEO, Midships  

Ajit leads Midships Group’s transition from a specialist identity consultancy to a portfolio of autonomous, AI-native business units. He focuses on long-term business relevance through platform thinking, customer outcomes, and scalable operating models.

Short bio: Ajit is a strategic founder with deep expertise in IAM, platform delivery, and AI services, driving Midships’ expansion across Asia, the Middle East, and beyond.

📧 ajit@midships.io  

🔗 LinkedIn: Ajit Gupta