---
title: "Multi-hop delegation for AI agents, and how the consent chain gets lost"
description: "When agent A delegates to agent B to a tool, the user's consent and identity get lost along the way. Here is how multi-hop delegation should actually work."
author: "Alex Olivier"
date: "2026-08-28T09:31:52.805Z"
canonical: "https://www.cerbos.dev/blog/multi-hop-delegation-ai-agents"
image: "https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/Multi_hop_delegation_for_AI_agents_and_how_the_consent_chain_gets_lost_fd7592de8a.png"
tags: ["guide"]
source: "https://www.cerbos.dev/blog/multi-hop-delegation-ai-agents"
---

# Multi-hop delegation for AI agents, and how the consent chain gets lost

A single agent calling a single tool is the demo. Production looks different. An agent takes a request from a user, hands part of the work to a second agent, which calls a tool, which reaches a database. By the time the request lands on the data, it has passed through four parties, and somewhere along that chain the two things that should have governed it, who the user is and what they agreed to, have usually gone missing.

This is the multi-hop delegation problem, and it is the part of agent security that current tooling handles worst. Each hop tends to run with broad, standing credentials rather than a narrow, time-bound grant tied to the original user. That is not a niche concern. A [2026 study from CyberArk](https://finance.yahoo.com/news/study-only-1-organizations-fully-133000355.html?guccounter=1), now part of Palo Alto Networks, found that 91% of organizations have at least half of their privileged access sitting always-on, and only 1% have fully moved to just-in-time access. Standing privilege is the norm, and a delegation chain built on standing privilege means every hop can do far more than the request in front of it requires.

This piece explains what multi-hop delegation is, why the chain breaks, what a well-designed chain looks like, and how to keep the user's identity and consent intact from the first hop to the last. It is the anchor for deeper articles (coming soon) on per-hop authorization, audit across sub-agents, and Rich Authorization Requests.

## What is multi-hop delegation?

Multi-hop delegation is when a request passes through a chain of agents and services, each acting on behalf of the original user, before it reaches the resource it targets. A user delegates to an agent, that agent delegates to a sub-agent or a tool, and so on. The authorization question at each hop is whether this party, acting for this user, may take this action, and the hard part is carrying enough of the user's identity and consent along the chain for that question to be answerable at every step.

The word that matters is *acting for*. Each hop is not exercising its own authority. It is exercising a slice of the user's, and the moment the chain forgets that, the whole thing turns into a set of over-broad services doing whatever their own credentials allow.

## Why the chain breaks

There are a few distinct ways a delegation chain loses the plot, and they compound.

The first is blind token forwarding. The easy way to pass identity down a chain is to forward the incoming access token unchanged to the next hop. It is also the way that breaks security. The Model Context Protocol's own [security guidance](https://modelcontextprotocol.io/specification/draft/basic/security_best_practices) is blunt about this. An MCP server must not accept a token that was not explicitly issued for it, and a proxy that forwards tokens can become a confused deputy, using its trusted position to act for a caller who should not have been allowed. The [confused deputy problem](https://en.wikipedia.org/wiki/Confused_deputy_problem) is not new, it was named in 1988, but agents give it a much larger surface, because an agent usually holds broader privileges than any single user it serves.

The second is that the identity often is not in the request at all. Google's [Agent2Agent protocol](https://a2a-protocol.org/latest/topics/enterprise-ready/), now under the Linux Foundation, is explicit that its payloads do not carry user or client identity directly. Identity is established at the transport layer between the two agents. That is a reasonable design choice for agent-to-agent communication, but it means the protocol moving work between agents is not the thing carrying the user's delegation, so something else has to.

The third is impersonation dressed up as delegation. [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693.html), the OAuth Token Exchange standard, draws the line precisely. Impersonation means a downstream party is given all the rights of the user and becomes indistinguishable from them. Delegation means the acting party keeps its own identity, separate from the user, and any action is recorded as this agent representing this user. A chain that impersonates loses the acting party at every hop. A chain that delegates keeps both identities visible the whole way down. Most naive implementations impersonate, because it is less work.

![multi-hop delegation - how the chain loses the user (1).png](https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/multi_hop_delegation_how_the_chain_loses_the_user_1_3d3181b446.png)

## The problem that is genuinely unsolved

George Fletcher, in what several attendees called the strongest talk at [Identiverse 2026](https://www.cerbos.dev/blog/identiverse-2026), drawn from more than a hundred sources across the IETF, W3C, and academic work, named it the crossing-the-trustee problem. Inside a single organization you can paper over delegation, because everyone shares infrastructure and trust. The moment a chain reaches into a different trust domain, where the party you are delegating to answers to someone else, the easy answers stop working. Business-to-business cases can be handled with contracts and a transparency layer. Consumer cases, he was candid, are still open.

That split decides what you can build now and what you have to wait on. The within-organization chain, the one most enterprises are actually deploying, is solvable today with existing standards and a policy layer. The cross-organization consumer chain is a research problem, and any vendor claiming to have fully solved it is worth a second look.

## What a well-designed chain looks like

The clearest picture of a working chain came from Reiner Mertens of KuppingerCole at [EIC Berlin 2026](https://www.cerbos.dev/blog/eic-identity-stack-built-for-humans-is-not-going-to-hold-up-for-agents). His argument was that the standards and tooling already exist, and enterprises fail at this for organizational reasons rather than technical ones. The architecture he described has four properties.

**First, workload identity** is verified before any user context is trusted. You cannot safely carry a user's identity to a service whose own identity you cannot verify. This is what [SPIFFE](https://www.cerbos.dev/blog/cerbos-pdp-v0-42-and-v0-43-spiffe-identity-support-smarter-logging), the CNCF workload identity standard, provides. Each workload proves who it is with a cryptographically verifiable identity document before it is handed anything on the user's behalf. Mertens called this a solved problem, and he is right.

**Second, a policy decision** is made at every hop, not only at the edge. The service receiving a delegated request evaluates whether this caller, acting for this user, may do this, against its own policy, rather than trusting that someone upstream already checked. RFC 8693 encodes the same discipline at the token level. The consumer of a token must only consider the token's top-level claims and the party named as the current actor.

**Third, the delegation is carried explicitly** rather than by forwarding a bearer token. Token Exchange expresses this with the act and may\_act claims, which record that delegation has occurred and identify the acting party, and pre-authorize who is allowed to become an actor for whom. The IETF's [Transaction Tokens draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/), built as a profile of Token Exchange, extends this so that the user's identity and authorization context are preserved and available to every workload in the call chain, and each workload can immutably assert that it was part of that chain.

**Fourth, every hop is logged with the full context.** The audit record at each transfer captures the acting party, the user being represented, the policy that decided, and the outcome. As Martin Kuppinger put it during the EIC agent workshop, authorization will never again be located with a single entity. It is a delegation chain that has to be monitored, hop by hop.

![multi-hop delegation - the well-designed consent chain (1).png](https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/multi_hop_delegation_the_well_designed_consent_chain_1_932e6d3d00.png)

## A test for any delegation approach

If you are evaluating a delegation design, Fletcher's talk offered a helpful checklist. A sound approach models the delegator, the delegatee, and multi-hop chains. It verifies external authority when there is any, such as a contract or a policy. Purpose travels with the delegation and is only selectively shareable. Constraints, both the ones the user set and the ones the mission implies, are enforced at every hop. A hop can never grant more than the delegator holds, and revocation flows downward. It works across organizations with no shared infrastructure. The full chain is auditable back to the original principal. And privacy is native. His own observation was that most proposals score well on the first few and fall apart on the rest, which is a useful thing to know before you commit to one.

## The standards are arriving, unevenly

It is worth knowing where the standards actually are, because the picture is patchy and the marketing tends to paper over the gaps. Delegation is being worked on in several places at once, and they do not yet add up to a single answer.

The primitive is stable. Token Exchange has been an RFC since 2020, and the act and may\_act claims give you a standard way to record and bound delegation inside a token. On top of it, the IETF's [WIMSE working group](https://datatracker.ietf.org/wg/wimse/about/), for workload identity in multi-system environments, is chartered specifically for fine-grained, least-privilege access across platforms, with the security context passed along the call chain. Its Transaction Tokens work is the part aimed at preserving user identity and provenance across every hop. These are active but non-final drafts, so they are the right things to track and the wrong things to bet the whole architecture on today.

The protocols moving agent work around are further behind on identity. Google's Agent2Agent handles agent-to-agent authentication at the transport layer but does not carry the user in the payload, and the Model Context Protocol secures the single client-to-server hop without defining cross-hop, on-behalf-of provenance. A [2026 preprint](https://arxiv.org/abs/2603.24775) that scanned roughly two thousand public MCP servers reported that all of them lacked authentication, which is a single-author preprint and should be read as a signal rather than a settled figure, but it matches what everyone deploying this is finding. The plumbing to verify who is acting is mostly not there yet.

![OpenID AuthZEN authorization standard.png](https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/Open_ID_Auth_ZEN_authorization_standard_26940d683e.png)

What is settled is the decision layer. The [OpenID AuthZEN Authorization API](https://www.cerbos.dev/authzen) reached final specification status in January 2026, and it defines a standard way to ask a policy decision point whether a subject may take an action on a resource in a given context. That is exactly the question each hop needs answered, and it is the one part of this stack you do not have to wait on. Homan Farahmand of Gartner framed delegation, both user-to-agent and agent-to-agent, as the central authorization challenge for agentic IAM at Gartner IAM London 2026, and the settled decision layer plus the maturing token layer is how you meet it without waiting for every draft to finalize.

## How Cerbos fits

Every property above comes down to one thing that is easy to state and easy to skip. A policy decision, made at each hop, that can see the whole chain. That is what Cerbos is.

Cerbos is an authorization management platform that runs as its own component, separate from agent and application code. At each hop in a delegation chain, the service or gateway calls the Cerbos Policy Decision Point and asks whether this agent, acting for this user, may take this action on this resource right now. The decision is deterministic and evaluated against policies written as code, so the rule can read the acting party, the delegation chain in the token, the resource, and the context together. Because Cerbos speaks the OpenID AuthZEN standard, it slots in as the decision point at every hop without tying the architecture to one vendor, and because every decision is logged with the full chain, the [audit trail](https://www.cerbos.dev/features-benefits-and-use-cases/audit-logs) that most implementations lose is produced as a byproduct. We have written more on [treating tokens as authorization decisions](https://www.cerbos.dev/blog/tokens-are-authorization-decisions-a-guide-to-policy-driven-token-issuance) and on governing [non-human identities](https://www.cerbos.dev/features-benefits-and-use-cases/authorization-non-human-identities) under the same model.

Machine identities already outnumber human ones by [more than 109 to 1](https://www.helpnetsecurity.com/2026/05/14/2026-identity-security-landscape-report/), Gartner expects [40% of enterprise applications](https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025) to include task-specific agents by the end of 2026, and Gartner also expects [over 40% of agentic AI projects](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027) to be canceled by 2027, partly due to inadequate risk controls. Delegation is one of those controls. The chains are being built either way. The question is whether each hop is a decision you can see and prove, or a broad credential you are hoping stays in its lane.

---

[Try Cerbos](https://hub.cerbos.cloud/) to see per-hop authorization for agent chains in practice, or [book a call](https://www.cerbos.dev/workshop) to walk through your delegation model with the team.

Go deeper:

* [Securing AI agents and non-human identities in enterprises](https://solutions.cerbos.dev/securing-ai-agents-non-human-identities-in-enterprises) (eBook) for the full pattern behind agent authorization  
* [Zero Trust for AI: Securing MCP servers](https://solutions.cerbos.dev/zero-trust-for-ai-securing-mcp-servers) (eBook) for authorization across agents and tools

## FAQ

### What is multi-hop delegation for AI agents?

Multi-hop delegation for AI agents is when a request passes through a chain of agents and services, each acting on behalf of the original user, before reaching the resource it targets. A user delegates to an agent, the agent delegates to a sub-agent or tool, and each hop must be able to answer whether this party, acting for this user, may take this action. The difficulty is carrying enough of the user's identity and consent along the chain for that question to be answerable at every step.

### Why does the consent chain break in agent delegation?

The consent chain breaks in agent delegation for three main reasons. Blind token forwarding passes the original token unchanged to the next hop, which the MCP security guidance forbids because it creates a confused deputy. Many agent protocols, including Agent2Agent, do not carry user identity in the payload at all. And naive implementations impersonate the user rather than delegating, so the acting agent's own identity is lost at each hop. Together these mean the downstream service sees a broad credential rather than a specific user acting through a specific agent.

### What is the difference between delegation and impersonation in OAuth?

The difference between delegation and impersonation in OAuth, as defined in RFC 8693, is whether the acting party keeps its own identity. In impersonation, a downstream party is given all the rights of the user and becomes indistinguishable from them. In delegation, the acting party keeps its own identity separate from the user, and every action is recorded as this party representing that user. Delegation is what a multi-hop chain needs, because it preserves both the acting agent and the original user at every hop.

### Can multi-hop agent delegation be solved with today's standards?

Multi-hop agent delegation within a single organization can be solved today by combining workload identity (SPIFFE), Token Exchange (RFC 8693\) to carry the delegation, and a policy decision at each hop. The genuinely unsolved case is cross-organization consumer delegation, described at Identiverse 2026 as the crossing-the-trustee problem, where the delegated party answers to a different trust domain. Business-to-business chains can be handled with contracts and a transparency layer, but consumer cross-domain delegation remains an open research problem.

### Where should authorization happen in a delegation chain?

Authorization in a delegation chain should happen at every hop, not only at the edge. Each service that receives a delegated request should evaluate, against its own policy, whether this caller acting for this user may take this action, rather than trusting that an upstream hop already checked. This mirrors the RFC 8693 rule that a token consumer must only consider the token's top-level claims and the current actor, and it is what keeps a compromised or over-privileged middle hop from reaching everything the chain can reach.

### How does Cerbos handle multi-hop delegation?

Cerbos handles multi-hop delegation by acting as the policy decision point that each hop calls before it proceeds. The service or gateway asks Cerbos whether this agent, acting for this user, may take this action on this resource, and Cerbos returns a deterministic decision based on policies written as code that can read the delegation chain in the token, the resource, and the context. Because Cerbos speaks the OpenID AuthZEN standard and logs every decision with the full chain, the per-hop enforcement and the replayable audit trail are produced together, without tying the architecture to one vendor.