Dear Sangdam,
Thanks for sharing.
I believe effective enforcement depends in a large part on how specific and
fine-grained the approved authority is.
For example in RFC 9396 is this RAR example:
{
"type": "payment_initiation",
"actions": [
"initiate",
"status",
"cancel"
],
"locations": [
"https://example.com/payments";
],
"instructedAmount": {
"currency": "EUR",
"amount": "123.50"
},
"creditorName": "Merchant A",
"creditorAccount": {
"iban": "DE02100100109307118603"
},
"remittanceInformationUnstructured": "Ref Number Merchant"
}
Which defines an exact payment amount and beneficiary.
A resource server can leverage these to deny a request with non-matching
arguments.
Could you please explain what gaps you identify, which cannot be mitigated with
fine-grained authority properties?
Regards,
Yaron
Classification: CONFIDENTIAL
From: Sangam Das <[email protected]>
Sent: Tuesday, September 1, 2026 9:52 AM
To: [email protected]
Cc: [email protected]
Subject: [OAUTH-WG] Binding OAuth-authorized calls to specific tool-call
arguments in agentic/MCP flows
You don't often get email from [email protected]<mailto:[email protected]>.
Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
This message is from an external sender - be cautious, particularly with links
and attachments.
Hi all,
A question prompted by watching how MCP/tool-use agents actually fail in
practice:
DPoP sender-constrains a token to a key. RAR and ID-JAG can scope a token to a
resource and a set of permitted actions. But once an agent holds a valid token,
none of these constrain the specific call it's about to make - the tool name
and arguments the model just emitted. A prompt-injected or poisoned-context
agent can hold a fully valid, correctly-scoped token and still invoke the right
tool with attacker-controlled arguments, and OAuth has no visibility into that
argument payload at all.
Is there existing or in-flight work that binds authorization to the content of
a specific call (e.g., a digest of the tool name + arguments) rather than just
to the resource/scope class - something closer to a per-invocation proof tying
a grant to this exact call, not this class of calls? Or is this considered out
of scope for OAuth/WIMSE and better handled at the host-application layer?
I've written up one possible approach in more detail as
draft-das-agentic-tool-binding-02 ("tool_use Is Not invoke(): Binding
Execution-Finality to Agentic Tool-Call Interfaces and MCP"), if useful as a
starting point rather than a proposal:
https://datatracker.ietf.org/doc/draft-das-agentic-tool-binding/02/
(Note: this builds on architecture covered by my pending patent applications,
disclosed per RFC 8179 for transparency - flagging this now rather than later.)
Mainly interested in whether this gap is already solved somewhere I'm missing.
Thanks,
Sangam
This message and any attachment ("the Message") are confidential. If you have
received the Message in error, please notify the sender immediately and delete
the Message from your system, any use of the Message is forbidden.
Correspondence via e-mail is primarily for information purposes. RBI neither
makes nor accepts legally binding statements via e-mail unless explicitly
agreed otherwise. Information pursuant to ? 14 Austrian Companies Code:
Raiffeisen Bank International AG; Registered Office: Am Stadtpark 9, 1030
Vienna, Austria; Company Register Number: FN 122119m at the Commercial Court of
Vienna (Handelsgericht Wien).
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
