Dear Chiradeep, Thank you for this detailed and timely analysis, and I find your "delegation chain splicing" concept particularly relevant. Your timing is impeccable; we have been actively discussing how to securely bind the requested party beyond the initial delegation point to prevent exactly the kind of context-switching you’ve described. I agree with your assessment regarding the gap between the subject_token and actor_token. The lack of a normative requirement to bind the may_act claim of the subject token to the actual identity presented in the actor token is a structural blind spot.Practical Challenges: The Dynamic Discovery Problem
While I agree with the need for stronger binding, I see significant practical limitations in requiring the delegation chain to be fully defined upfront. In sophisticated multi-agent systems, agent discovery is often dynamic. A primary agent might not know which specific downstream sub-agents (e.g., a specialized medical coding agent or a specific CI/CD runner) will be required to fulfill a request until the execution phase. - The Scalability Issue: Listing every potential actor in a may_act claim at the start of the flow could lead to massive tokens and require the user (or the initial STS) to have perfect foresight of the entire downstream topology. - The Flexibility Issue: Hard-coding the chain limits the ability of the system to adapt to runtime failures or load balancing, where a different, but still trusted, agent needs to step in. Evaluating "Exchangeable" Subject Tokens via Intermediate Consent To solve the "Dynamic Discovery" problem while maintaining the security you've identified, we are evaluating an improvement to the draft-oauth-ai-agents-on-behalf-of-user draft: The Intermediate Consent/Exchange Step. Instead of a static chain, we are exploring a flow where the incoming subject_token is exchanged for a specifically "exchangeable" subject token. 1. Request for Delegation: When a primary agent discovers it needs a sub-agent, it requests a refined token from the Authorization Server (AS). 2. Precondition/Policy Check: The AS evaluates the request against a precondition (e.g., "Is this sub-agent in a 'Highly Trusted' tier?") or triggers a dynamic user delegation (e.g., a push notification to the user for high-risk sub-agent access). 3. Binding: The AS issues a token where the aud (audience) is explicitly bound to the sub (subject) of the intended actor, and/or has may_act, including the requested actor, intending to exchange the token. Does the introduction of a "precondition check" at the AS provide the "verifiable provenance" you suggested in your third mitigation (Per-step delegation receipts)? Additionally, this step would grant a mechanism for dynamic authorization delegation (step-up) for the downstream actors. Exploring Audience (aud) to Subject (sub) Binding One mechanism we have also been evaluating and implementing at the token exchange is, without requiring a pre-defined list of all actors, is a stricter enforcement of the Audience (aud) claim. Specifically, we are looking at a requirement where: The aud (Audience) of the subject_token must match the sub (Subject) of the actor_token. In theory, this ensures that the token being exchanged was specifically intended for the party currently acting as the "actor." This would prevent an intermediary from taking a token meant for "Agent A" and using it as a subject_token in a request where "Agent B" is the actor. I'm also looking forward for everyones thoughts on this: Is the cryptographic link created by requiring the aud (audience) of step 'N' to match the sub (subject) of step 'N+1' strong enough to prevent splicing? Are there edge cases where an attacker could still manipulate the context? Should both may_act and aud validations occur simultaneously, or is one of them sufficient? Regards, Ayesha On Fri, Feb 27, 2026 at 9:58 AM <[email protected]> wrote: > Dear OAuth Working Group, > > I am writing to share a potential security finding related to the act (actor) > claim in RFC 8693 (OAuth 2.0 Token Exchange) that I believe warrants > consideration, particularly as the working group advances specifications > for agentic OAuth flows (draft-oauth-ai-agents-on-behalf-of-user, > transaction tokens, etc.). > Summary > > I may have identified a structural weakness I call *"delegation chain > splicing"* -- a technique by which a compromised intermediary can present > mismatched subject_token and actor_token inputs to the token exchange > endpoint from different delegation contexts. The STS validates each token > independently (per Section2.1-2.2), finds both valid, and issues a new > properly-signed token asserting a delegation chain that never actually > occurred. > > The root cause is that RFC 8693 does not require cross-validation between > the subject_token and actor_token -- specifically, there is no mechanism > to verify they belong to the same delegation flow, authorization session, > or trust context. > Why This Matters Now > > While RFC 8693 Section4.1 correctly states that nested act claims are > "informational only" for access control, the proliferation of agentic AI > systems creates deployment contexts where delegation chain history is > increasingly relied upon for: > > - Audit trail integrity (required under HIPAA, SOC 2) > - Policy enforcement ("was there a human in the loop?", "how many > delegation hops?") > - Anomaly detection and trust scoring > - Compliance reporting > > The may_act claim (Section4.4) provides partial mitigation by restricting > which actors may exchange a token, but it validates the actor's *identity*, > not that the actor credential was *acquired within the same delegation > context*. It is also optional -- there is no normative requirement that > subject tokens carry may_act or that the STS enforce it. > > The draft-oauth-ai-agents-on-behalf-of-user specification takes a step in > the right direction by binding the authorization code to the actor > (Section5.5), but this protects only the initial user-to-agent delegation. > Subsequent agent-to-agent token exchanges -- where chain splicing occurs -- > remain unaddressed. > Real-World Precedent > > CVE-2025-55241 (Microsoft Entra ID, patched July 2025) demonstrated that > actor token validation failures have Critical-severity impact in > production. That vulnerability involved unsigned actor tokens enabling > cross-tenant impersonation -- a closely related class of act claim misuse. > Suggested Mitigations for Consideration > > 1. > > *Cross-validation requirement:* The STS should verify that the > actor_token subject matches an authorized next-actor declared in the > subject_token (strengthening may_act from optional to normative). > 2. > > *aud/sub chaining within act claims:* Require that nested act claims > include fields forming a verifiable chain -- similar to what OIDC-A 1.0 > specifies for delegation_chain, where the aud of step N must match the > sub of step N+1. > 3. > > *Per-step delegation receipts:* Each STS that performs a token > exchange includes a signed attestation of the delegation step, providing > independently-verifiable provenance. > > Full Write-Up > > A detailed write-up with three concrete scenarios (healthcare, > multi-tenant SaaS, CI/CD), mechanism description, conditions for > exploitability, anticipated counterarguments, and mitigations is attached. > > This finding was independently validated by multiple analyses working from > the RFC 8693 specification text alone. > > I welcome feedback and am happy to discuss further. > > Best regards, > > Chiradeep Chhaya > ------------------------------ > > *Note: This finding was identified during security research with the > assistance of AI tools (Claude by Anthropic and Gemini by Google), which > were used for collaborative analysis, adversarial review, and independent > validation. I am sharing it with the working group for independent > validation and consideration in ongoing specification work.* > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
