Take an ordinary request. A user asks an orchestrator agent for the quarterly report. The orchestrator hands the data work to an analyst sub-agent. The sub-agent calls a reporting tool, and the tool calls the finance API. Four hops, one sentence from a human.
By the time the request reaches the finance API, all that’s left is a token. The standard that says how a token records “who is acting for whom” is RFC 8693, OAuth 2.0 Token Exchange. Section 4.1 lets the token carry the whole chain by nesting act claims. Then it says: “For the purpose of applying access control policy, the consumer of a token MUST only consider the token’s top-level claims.” And, a few lines down: “Prior actors identified by any nested act claims are informational only.”
So the finance API enforces the last hop. The three before it are a record, not a rule.
That was a sensible design in January 2020, when a delegation chain usually meant a front end calling a back end. In a multi-agent system, the earlier hops are where the risk sits. Below I go through how chains fail, what the 2026 drafts and papers propose, and what each proposal still leaves open.
TL;DR
- RFC 8693 enforces only the last hop. Earlier actors in the
act chain are “informational only.” In a multi-agent system, that is where the risk sits. - Chains fail three ways. Authority does not narrow (one compromised sub-agent reached all 8,100 actions in one study, 1.5 behind a broker), the recorded history can be forged, and the first token is scoped by hand with no standard behind it.
- Four fixes are on the table, and each puts the check in a different place: exchange the token at every hop, make the chain verifiable, let the holder narrow the token offline, or put a broker in the path.
- None of them scopes the root token or stops data already in the payload from leaving. Attenuation also gives up revocation, and it says nothing about order or frequency.
- What you can do this week: draw the chain, stop treating
act history as evidence, narrow in the harness rather than the prompt, constrain arguments as well as tools, and write the root scope down.
Three ways a chain fails
Authority does not narrow
The easiest way to wire a multi-agent system is to pass the same credential down the chain. Every hop then holds whatever the first hop held.
Dantuluri and Sundi put a number on that in Delegation Without Trust (arXiv 2609.00267, submitted 31 August 2026). They built a synthetic environment of 8,100 tool and resource actions and ran 2,000 randomized delegation scenarios with a compromised sub-agent. Under bearer delegation, the compromised sub-agent could reach all 8,100 actions. Behind their authorization broker, which gives each sub-agent only the authority for its sub-task, it reached a mean of 1.5.
Don’t read too much into 8,100. It’s an artifact of how they built the environment, and the paper doesn’t describe how the actions were generated. The ratio is what matters: without narrowing, one compromised sub-agent has the blast radius of the whole system.
They also checked the defaults of four ecosystems against four threats: confused deputy, token theft and replay, prompt-injection privilege escalation, and a compromised sub-agent. LangGraph 1.2.10, CrewAI 1.15.13 and AutoGen 0.7.5 were vulnerable to all four out of the box. The MCP authorization specification (revision 2026-07-28) was partly protected against token theft, which the authors credit to Resource Indicators (RFC 8707), and vulnerable to the other three. Only the LangGraph case was executed, against a real compiled StateGraph. CrewAI and AutoGen were judged by reading their tool-execution base classes, and MCP by reading the spec. Treat those three as design review, not exploitation.
Bearer delegation keeps the authority constant down the chain. The receiving hop can only enforce the top-level claims either way.The history can be forged
If earlier actors are informational, a forged history is informational too. Nobody checks it, so nobody notices.
On 26 February 2026, Chiradeep Chhaya described one way to forge it on the IETF OAuth working group list and called it “delegation chain splicing.” A compromised intermediary sends the token exchange endpoint a subject_token from one delegation flow and an actor_token from another. The security token service validates each one on its own, finds both valid, and “issues a new properly-signed token asserting a delegation chain that never actually occurred.” The root cause, per the post, is that RFC 8693 “does not require cross-validation between the subject_token and actor_token.” The may_act claim doesn’t save you either. Section 4.4 says its claims “pertain only to the identity of that party,” not to where the actor credential came from.
This is a finding reported on a mailing list. There’s no CVE and no vendor advisory. I still think it matters, because audit pipelines, policy engines and compliance tooling increasingly read the act chain as if it were evidence.
The first token is scoped by hand
The first hop has a different problem. Someone has to decide what authority the orchestrator needs to “produce the quarterly report.” The IETF’s agent identity framework, draft-ietf-wimse-aims-00, adopted as a WIMSE working group document on 15 September 2026, names that step and then sets it aside. Section 10.1: “The process through which the mission is translated into authorization requirements is out of scope of this specification.”
So the most consequential scoping decision in the chain has no standard behind it. Managed platforms make it for you by default, and the default can be generous. In October, Zenity Labs showed that the default execution role for AWS Bedrock AgentCore agents wasn’t scoped to one agent. A prompt injection that read the role’s credentials from the metadata service could list, invoke and read the conversations of every AgentCore agent in the account and region. AWS restricted the role in late September, nine months after the first report. Every narrowing scheme below starts from whatever that decision produced. If the root token is too broad, attenuating it hop by hop gets you a chain of tokens that are each slightly less too broad.
What is on the table
Four approaches are in circulation. They aren’t really competitors. Each one puts the check in a different place.
1. Exchange the token at every hop
The OAuth-native answer is to go back to an authorization server at each hop and ask for a narrower token. Transaction Tokens (draft -11, 30 July 2026, now waiting for its shepherd write-up) do this inside one trust domain. A Transaction Token Service mints short-lived tokens, “on the order of minutes or less” (section 6), bound to a transaction ID. Section 13.6 says the requested scope must be “equal or less than” the scope of the original subject token, and section 13.15 forbids a replacement token from expanding it. Section 13.14 covers the case I like most: if the service can’t work out the original scope, it “MUST reject the Txn-Token Request and MUST NOT treat an unknown scope as unconstrained.”
Across trust domains, OAuth Identity and Authorization Chaining does the equivalent job. Revision 17 (19 July 2026) is in the RFC Editor queue.
The cost is a synchronous call to an authorization server at every hop, and an authorization server that knows enough about each sub-task to scope it. With an orchestrator fanning out to dozens of sub-agents, that’s a lot of policy living in one place.
2. Make the chain verifiable
The second approach keeps the chain in the token but makes it checkable. OAuth Actor Chain (draft-mw-oauth-actor-chain-02, 13 October 2026, an individual draft with authors including Telefonica and Aryaka) defines six profiles, combining two assurance levels with three levels of disclosure. In the “verified” profiles, every actor step produces “one actor proof and one AS acceptance,” so a receiver can check the prior actors instead of taking them on faith. Its predecessor, draft-mw-spice-actor-chain-00 (25 February 2026), put the aim plainly: a claim that “replaces the informational-only nested act claim with a tamper-evident, ordered record of all actors.” The current revision is more cautious. It “does not change the base meaning of sub, act, or may_act,” and the evidence lives in a separate top-level extension. It’s also explicit about its limits: the proofs don’t show “that an actor performed a task, produced a correct result, remained uncompromised, or that every branch or off-protocol actor was disclosed.”
This fixes forged history. It doesn’t narrow authority by itself. A perfectly verified chain of five actors who all hold the same broad scope is still five broad tokens.
3. Let the holder narrow the token offline
The third approach comes from capability systems. Google’s Macaroons paper (Birgisson et al., NDSS 2014) showed that a token holder can add caveats that narrow a token without calling the issuer, and that nobody can strip a caveat once it’s added. Biscuit carries the same idea forward with public-key signatures and a Datalog policy language.
Two 2026 proposals apply it to agents.
Attenuating Authorization Tokens for Agentic Delegation Chains (draft-niyikiza-oauth-attenuating-agent-tokens-01, 15 June 2026, an individual submission from N. A. Niyikiza of Tenuo) lists the tools an agent may call and the constraints on each argument. A holder derives a narrower token locally, and any enforcement point holding the root issuer’s key can verify the whole chain. The draft states six invariants. Four of them carry the security argument:
- Depth monotonicity (I2): each derived token is exactly one level deeper and can’t exceed the parent’s maximum depth.
- TTL monotonicity (I3): a derived token can’t outlive its parent.
- Capability monotonicity (I4): the derived tool set is a subset of the parent’s, and every argument constraint is at least as strict.
- Cryptographic linkage (I5): each token carries
par_hash, a SHA-256 digest of its parent’s signing input. This is the draft’s answer to splicing. A token derived from parent A won’t verify against parent B, even if both share a holder key.
When a tool has argument constraints, enforcement runs closed-world (section 3.3). Arguments the token doesn’t name are rejected, and so are constrained arguments that are missing. For agents this is the property that counts, because the confused deputy lives in the arguments the model fills in.
AIP (Sunil Prakash, arXiv 2603.24775, March 2026) proposes Invocation-Bound Capability Tokens that put identity, attenuated authorization and provenance into one append-only chain: a signed JWT for a single hop, a Biscuit for multi-hop. Prakash reports verification at 0.049 ms in Rust (0.189 ms in Python), 2.35 ms added in a multi-agent deployment on Gemini 2.5 Flash, and rejection of all 600 attack attempts in the evaluation. Two attack categories, delegation-depth violation and audit evasion through empty context, were caught only by the chained form. Plain JWTs missed both.
4. Put a broker in the path
The fourth approach doesn’t trust the agent to narrow anything. Dantuluri and Sundi’s broker sits between agents and tools and holds the delegation state itself. In their evaluation it resisted all eleven direct attacks, accepted none of 200,000 forged tokens, and decided in about 2.6 microseconds. The authors call one of their eight requirements “load-bearing”: R8, model-independent enforcement. “Authorization decisions are made by infrastructure PEPs, never by the untrusted model.”
That requirement also answers who does the narrowing in approaches 1 and 3. AIMS section 8 says: “The Large Language Model MUST NOT have access to an agent’s credentials.” The harness derives the narrower token, not the model. If your design lets the model decide what scope to request, you’ve moved the mission-to-authorization problem into the context window, which is exactly where a prompt injection can reach it.
How the pieces cover the requirements
Dantuluri and Sundi derive eight requirements and score existing standards against them. Here’s a slice of their Table 3:
| Standard | Chain provenance (R1) | Least-privilege attenuation (R2) | Sender-constrained (R3) | Revocation (R6) | Model-independent (R8) |
|---|
| Token Exchange (RFC 8693) | Yes | Partial | No | No | No |
| SPIFFE/SPIRE | Partial | No | Yes | Partial | No |
| DPoP (RFC 9449) | No | No | Yes | No | No |
| Macaroons | Yes | Yes | Partial | Partial | Yes |
| Biscuit | Yes | Yes | Partial | Partial | Yes |
| MCP authorization | Partial | No | Partial | No | Partial |
This is the authors’ reading of each spec, not a conformance test, and the paper isn’t fully consistent with itself. Its Table 2 and section 5.2 score MCP differently on revocation and on R8. The overall pattern still holds up. Provenance and attenuation live in token exchange and capability tokens. Sender-constraining lives in SPIFFE, mTLS and DPoP. No single standard covers the set, so any real design combines at least two.
What narrowing does not fix
Each proposal is upfront about its own limits, and the limits line up.
Attenuation limits what a hop may do. It doesn’t limit what a hop can read once a task lands on it. Krti Tallam’s Authorization Propagation in Multi-Agent AI Systems (arXiv 2605.05440, May 2026) calls one version of this aggregation inference: “Even when each individual data access in a workflow is independently authorized, the synthesis of results may produce information that no individual access would expose.” The paper notes the problem is old; classified-information handling calls it the mosaic effect. Every call can be authorized and the combined output can still leak.
Order and frequency
The attenuating-token draft says it plainly in section 8.1.2: AATs “do not restrict which authorized invocations an agent chooses to make, in what order, or how many times.” A token that allows read_invoice allows reading every invoice in scope.
Revocation
Offline verification gives up revocation. The attenuating-token draft puts revocation of individual tokens out of scope (section 8.9) and leans on short lifetimes instead: “A short-lived leaf token provides a bounded damage window even when no revocation mechanism is deployed.” AIP and Biscuit make the same trade.
Resource resolution
The protocol authorizes the invocation it was shown, and “the tool remains responsible for resolving that invocation to the correct resource” (section 8.1.1). A tool that trusts a caller-supplied tenant ID is a confused deputy whatever token arrived.
The root
None of this scopes the first token. That is still the out-of-scope step in AIMS section 10.1.
Applied to a known chain
In June I published a five-stage chain that starts with a poisoned MCP tool description and ends with a rogue A2A agent that keeps receiving work after the malicious server is deleted. I walked it, on paper, through attenuated delegation, assuming the orchestrator derives a narrower token for every task it hands out.
Attenuation narrows what the rogue agent can do with authority. It does not stop the task data it was handed from leaving.Stages one and two don’t involve delegated authority at all. One is a context problem, the other a discovery problem, and attenuation doesn’t touch either. Stage three is where narrowing pays off: the rogue agent gets a token for one sub-task instead of the orchestrator’s full scope. Stage four only partly improves, because whatever data sits in the task payload leaves regardless. Stage five gets better, since derived tokens die with their parent, but the rogue registry entry survives and will be handed fresh tokens for new tasks until someone deletes it.
That’s analysis, not measurement. The next experiment is re-running the lab with an attenuating broker in the delegation path, and I’ll publish the numbers whichever way they fall.
What to do with this now
- Draw your delegation chain. For every agent-to-agent and agent-to-tool hop, write down which credential crosses it. If the same token crosses more than one hop, you have bearer delegation.
- Stop reading
act history as evidence. Until you adopt a verifiable chain, treat the nested actors in your logs as claims made by the last hop. - Narrow in the harness, never in the prompt. Whatever mechanism you pick, the code that derives the narrower token has to sit outside the model’s reach, which is what AIMS section 8 requires.
- Constrain arguments, not just tools. A tool allowlist without argument constraints leaves the confused deputy in place. The closed-world argument check is the part of the attenuating-token draft worth copying now, before you adopt the format.
- Write the root scope down. The mission-to-authorization step has no standard. Writing down what the first token may reach for each task type is cheap, and every other control depends on it.
Items 1, 2, 3 and 5 need no new infrastructure. Item 4 is where a gateway or broker earns its keep.
In issue #32 of the newsletter I asked for real examples of scope that is only enforced in the prompt. That is step 3 failing. If you have one, reply to the newsletter. I’m collecting them for this series.
The takeaway
The token standard most agent stacks lean on was written for a front end calling a back end, and it tells the receiver to ignore everyone but the last caller. In a chain of agents, that leaves the hops where a prompt injection lands unchecked. The drafts and papers this year show how to fix parts of it: narrow at every hop, sign the history, keep the narrowing out of the model’s reach. None of them decides what the first token should be allowed to do. That decision is yours, and it is the one to write down first.
If you want a quick read on your own agents against the OWASP Agentic Top 10, the Agent Security Scorecard takes about twelve minutes. If you want help drawing your delegation chain and deciding where the checks go, get in touch.
Primary sources
Standards and drafts
- RFC 8693: OAuth 2.0 Token Exchange, January 2020, sections 1.1, 4.1 and 4.4
- draft-ietf-wimse-aims-00: AI Identity Management System, WIMSE working group document, 15 September 2026, sections 8 and 10.1
- draft-ietf-oauth-transaction-tokens-11: Transaction Tokens, 30 July 2026, sections 6, 13.6, 13.14 and 13.15
- draft-ietf-oauth-identity-chaining-17: OAuth Identity and Authorization Chaining Across Domains, 19 July 2026, RFC Editor queue
- draft-mw-oauth-actor-chain-02: OAuth Actor Chain: Protocol and Interoperability, 13 October 2026, sections 2 and 5; predecessor draft-mw-spice-actor-chain-00, 25 February 2026
- draft-niyikiza-oauth-attenuating-agent-tokens-01: Attenuating Authorization Tokens for Agentic Delegation Chains, 15 June 2026, individual submission, sections 3.3, 4, 8.1 and 8.9
- RFC 8707: Resource Indicators for OAuth 2.0, February 2020
- RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP), September 2023
Research
- Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems (Dantuluri and Sundi, arXiv 2609.00267), 31 August 2026
- AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A (Prakash, arXiv 2603.24775), 25 March 2026
- Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure (Tallam, arXiv 2605.05440), 6 May 2026, section 5.2.2
- Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud (Birgisson et al., NDSS 2014)
- Biscuit authorization token
Incidents
Discussion
Earlier in this series
