Subject: [OAUTH-WG] Binding OAuth-authorized calls to specific tool-call arguments in agentic/MCP flows
From: Sangam Das <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 1 Sep 2026 13:21:59 +0530
List-Id: OAUTH WG <oauth.ietf.org>

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/
<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