Dear Ayesha,
Thanks for the detailed response -- good to know this lines up with discussions
you're already having. The mechanisms you're evaluating are exactly what I
think is needed here.
Jumping into your questions:
On the Intermediate Consent Step and "Verifiable Provenance"
Your precondition check is closer to my first mitigation (cross-validation at
the exchange boundary) than to my third (per-step delegation receipts). Worth
separating these:
-
Cross-validation(what you're describing): The AS verifies at exchange time that
the delegation is authorized -- "Is this sub-agent in a trusted tier? Does the
user consent?" This stops the splice in real time.
-
Per-step delegation receipts(my mitigation #3): Each exchange step produces a
signed artifact that downstream parties can verify independently, without
calling back to the AS. A chain of signed assertions: "AS-1 authorized Agent-X
to delegate to Agent-Y at time T with scope S."
So your consent step prevents the splice; receipts prove after the fact that
each step was authorized. They're complementary -- you could issue the receipt
as part of the consent step.
I'd prioritize the consent step for the draft. Receipts matter in audit-heavy
environments (healthcare, financial services) but add token size and
complexity. They also help with an operational concern I'll get to below.
On aud/sub Binding: Is It Strong Enough?
Short answer: yes, aud/sub binding is the right primitive. How well it holds up
depends on enforcement and a few edge cases I've been thinking through.
The core mechanic works: If Alice's token carriesaud: "agent-X", and the STS
requiresactor_token.subto match, then Agent-X can't present Agent-N's
actor_token --sub: "agent-N"doesn't match aud: "agent-X". Splice blocked.
But there are edge cases worth working through:
-
Upstream delegation splice.This one concerns me the most. Agent-X legitimately
holds Alice's token (aud: "agent-X"). Agent-X then requests anewtoken from the
AS with aud: "agent-N" to enable sub-delegation. If the AS issues this without
checking whether Agent-X is actually authorized to re-delegate to Agent-N on
Alice's behalf, the splice just moves upstream -- Agent-X gets the AS to
produce the mismatched token for it. Your precondition check is what closes
this hole: the AS has to verify the re-delegation before issuing the new token.
I'd suggest calling this out explicitly in the draft -- aud/sub binding
prevents splicing at the exchange boundary, but without the precondition check,
a malicious agent can effectively get the AS to splice on its behalf.
-
Multi-instance actors.In production, an "agent" is often a horizontally-scaled
service behind a load balancer. Alice's token might haveaud: "agent-x-service",
but the instance presenting the actor_token hassub: "agent-x-instance-47". The
simple equality check breaks. The AS would need to resolve service principal
identifiers to sets of valid instance-level subjects. Not a blocker, but it's
real implementation complexity.
-
Multi-audience tokens.A token withaud: ["agent-X", "agent-Y", "agent-N"]weakens
the binding since multiple actors could satisfy the match. For delegation, I'd
push for single-valued audience claims to keep the 1:1 binding strict.
-
Missing audience claims.audis optional in JWTs. Noaudon the subject_token means
no binding, which means the splice is back on the table. Strong argument for
makingaudmandatory when tokens participate in delegation chains.
-
STS-to-STS federation.When delegation chains span multiple STSs across trust
domains, each STS sets the audience for its own leg. A downstream STS trusts
the upstream token's audience claim but can't verify the upstream STS actually
performed the aud/sub check. A misconfigured upstream STS could issue tokens
with overly permissive audience values.
-
Revocation propagation.If Alice revokes consent for Agent-X, the consent step
prevents new delegations. But tokens already held by downstream agents
(Agent-Y, Agent-Z) are still valid until they expire. We'd need to address
chain-wide invalidation -- short lifetimes, back-channel revocation, or
requiring resource servers to re-validate the full chain on each request.
-
Token refresh as a bypass.Related to revocation: if the AS issues refresh
tokens alongside exchanged access tokens, the refresh flow (RFC 6749 Section 6)
doesn't require re-presenting the subject_token or actor_token. An agent whose
delegation has been revoked could still refresh its way to a new access token
if the refresh endpoint doesn't re-validate the delegation context. DPoP (RFC
9449) dealt with a similar gap by requiring proof presentation on refresh, not
just on initial requests. I'd suggest the draft include guidance along the
lines of: "When refreshing tokens issued via delegated token exchange, the AS
SHOULD re-validate the delegation context, including verifying that upstream
consents remain active." Without that, the consent-per-step model has a quiet
backdoor through the refresh endpoint.
On may_act vs aud -- Simultaneous or Either/Or?
I think you need both, enforced together. They cover different failure modes:
-
aud/sub binding: "Was this tokenintended forthe actor presenting it?" -- a
per-transaction binding that prevents misuse at the exchange boundary.
-
may_act: "Is this actorauthorizedto act on behalf of this subject?" -- a policy
declaration from the subject (or the AS on their behalf).
Each alone has gaps: - aud/sub alone: Without the precondition check, a
malicious agent can ask the AS to issue a token with aud matching any
downstream actor (the upstream delegation splice from edge case #1). - may_act
alone: Validates identity but not that the actor_token came from the same
delegation context -- the original gap.
Both together: the token has to be intended for the actor (aud) AND the subject
has to have authorized that actor (may_act).
On the Dynamic Discovery Problem
Agreed -- requiring the full chain upfront is impractical for real agent
systems. The intermediate consent step handles this well: the AS verifies each
delegation at exchange time while the chain gets built incrementally as agents
discover what they need downstream.
There are some operational costs to this approach worth documenting in the
draft:
-
Latency:Every delegation hop in a chain of N agents adds a synchronous
round-trip to the AS. For latency-sensitive orchestration this adds up.
-
Availability:The AS becomes a single point of failure for every agent-to-agent
delegation, not just user logins. An AS outage halts all agent collaboration.
That's a meaningfully higher availability bar for AS infrastructure.
-
Offline/disconnected scenarios:Consent-per-step is inherently online. For edge
computing or intermittent connectivity, pre-signed delegation receipts
(mitigation #3) are probably the better fit since they don't require an AS
callback.
-
Backward compatibility:On the upside, this should be backward-compatible at the
protocol level. RFC 8693 is a framework; these are AS-side validation rules.
Existing clients don't change -- the AS just gets stricter about what it
permits.
Not reasons to avoid the approach, but trade-offs that implementers should
understand.
Pulling This Together
If I were writing a concrete mitigation profile, I'd combine your consent step
with the binding mechanisms:
- The AS MUST verifysubject_token.audmatchesactor_token.subat each token
exchange (with support for resolving service principal identifiers to
instance-level subjects).
- For delegation chains, thesubject_tokenMUST carry a single-valuedaudclaim
identifying the intended next actor.
- The AS MUST validate the delegation against policy (may_act or equivalent)
before issuing the new token.
- The AS SHOULD issue the new token withaudset to the intended downstream
actor, maintaining the binding through the chain.
- Implementers SHOULD use short token lifetimes and consider back-channel
revocation to limit exposure for downstream tokens after consent is withdrawn.
- When refreshing tokens issued via delegated exchange, the AS SHOULD
re-validate the delegation context, including verifying that upstream consents
remain active.
Happy to keep this going and contribute to the draft if it's useful.
Best.
On Friday, February 27th, 2026 at 1:20 AM, Ayesha Dissanayaka
<[email protected]> wrote:
> 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.
>
> -
>
> Request for Delegation: When a primary agent discovers it needs a sub-agent,
> it requests a refined token from the Authorization Server (AS).
>
> -
>
> 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).
>
> -
>
> 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 theact(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
>> mismatchedsubject_tokenandactor_tokeninputs 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
>> thesubject_tokenandactor_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 nestedactclaims 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
>>
>> Themay_actclaim (Section4.4) provides partial mitigation by restricting
>> which actors may exchange a token, but it validates the actor'sidentity, not
>> that the actor credential wasacquired within the same delegation context. It
>> is also optional -- there is no normative requirement that subject tokens
>> carrymay_actor 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 ofactclaim misuse.
>>
>> Suggested Mitigations for Consideration
>>
>> -
>>
>> Cross-validation requirement:The STS should verify that
>> theactor_tokensubject matches an authorized next-actor declared in
>> thesubject_token(strengtheningmay_actfrom optional to normative).
>>
>> -
>>
>> aud/subchaining withinactclaims:Require that nestedactclaims include fields
>> forming a verifiable chain -- similar to what OIDC-A 1.0 specifies
>> fordelegation_chain, where theaudof step N must match thesubof step N+1.
>>
>> -
>>
>> 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]
