MIME-Version: 1.0
From: Sangam Das <info@sangamdas.com>
Date: Tue, 1 Sep 2026 13:21:59 +0530
Message-ID: 
 <CAHCJH6HA8EWiP63o+RcW4vum-xvZCob23GDYqgJZU3LjkcU2TA@mail.gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000030353e065a6732fe"
Message-ID-Hash: OB4CJ73WQJX677UUMLSXZB3STSOLB343
CC: wimse@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BOAUTH-WG=5D_Binding_OAuth-authorized_calls_to_specific_tool-cal?=
 =?utf-8?q?l_arguments_in_agentic/MCP_flows?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/oauth/Vl595YM2eGCK2OpnWWXSxBeHwck>

--00000000000030353e065a6732fe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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
=E2=80=94 the tool name and arguments the model just emitted. A prompt-inje=
cted 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 =E2=80=94 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/0=
2/
<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 =E2=80=94 flagging th=
is now
rather than later.)

Mainly interested in whether this gap is already solved somewhere I'm
missing.

Thanks,
Sangam

--00000000000030353e065a6732fe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p dir=3D"ltr">Hi all,</p>
<p dir=3D"ltr">A question prompted by watching how MCP/tool-use agents actu=
ally fail in practice:</p>
<p dir=3D"ltr">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 age=
nt holds a valid token, none of these constrain the <em>specific call</em> =
it&#39;s about to make =E2=80=94 the tool name and arguments the model just=
 emitted. A prompt-injected or poisoned-context agent can hold a fully vali=
d, correctly-scoped token and still invoke the right tool with attacker-con=
trolled arguments, and OAuth has no visibility into that argument payload a=
t all.</p>
<p dir=3D"ltr">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 + argum=
ents) rather than just to the resource/scope class =E2=80=94 something clos=
er to a per-invocation proof tying a grant to <em>this exact call</em>, not=
 <em>this class of calls</em>? Or is this considered out of scope for OAuth=
/WIMSE and better handled at the host-application layer?</p>
<p dir=3D"ltr">I<b>&#39;ve written up one possible approach in more detail =
as <code>draft-das-agentic-tool-binding-02</code> (&quot;tool_use Is Not in=
voke(): Binding Execution-Finality to Agentic Tool-Call Interfaces and MCP&=
quot;), if useful as a starting point rather than a proposal:=C2=A0<font co=
lor=3D"#0b5394"><a href=3D"https://datatracker.ietf.org/doc/draft-das-agent=
ic-tool-binding/02/">https://datatracker.ietf.org/doc/draft-das-agentic-too=
l-binding/02/</a></font></b></p><p dir=3D"ltr"><span style=3D"background-co=
lor:transparent">(Note: this builds on architecture covered by my pending p=
atent applications, disclosed per RFC 8179 for transparency =E2=80=94 flagg=
ing this now rather than later.)</span></p>
<p dir=3D"ltr">Mainly interested in whether this gap is already solved some=
where I&#39;m missing.</p>
<p dir=3D"ltr">Thanks,<br>
Sangam</p></div>

--00000000000030353e065a6732fe--