[OAUTH-WG] Re: [WIMSE] Re: Binding OAuth-authorized calls to specific tool-call arguments in agentic/MCP flows

["Raut, Ashay" <[e-mail]>]

  *   So the issue is not that model-generated values can never become authorized. It is that the same untrusted output should not effectively define both the act and its own authority without an independent validation step.

Agree with this statement here.



  *   the concrete Candidate Act remains non-effective until independently authorized act-bound state is verified at the boundary capable of creating the external effect, and equivalent execution paths cannot bypass that boundary.

Fair call out. It’s almost like we need spec to say, “A conforming host implementation MUST NOT invoke a tool sink unless the finalized parameter digest matches an authorized policy assertion”.

On side note, you can pass Txn token’s ​ tctx​ claims along with agentic_context​ so that deep down call chains can do fine grained authorization to enable defense in depth and additional checks for agent initiated actions. Refer to https://www.ietf.org/archive/id/draft-araut-oauth-transaction-tokens-for-agents-02.html

Ashay

Get Outlook for Mac<https://aka.ms/GetOutlookForMac>
From: Sangam Das <[e-mail]>
Date: Tuesday, September 1, 2026 at 3:32 AM
To: Yaron ZEHAVI <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [EXTERNAL] [WIMSE] Re: [OAUTH-WG] Binding OAuth-authorized calls to specific tool-call arguments in agentic/MCP flows


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


Hi Yaron,

Agreed on the payment example.

If a client already has a concrete intent — Merchant A, EUR 123.50, that IBAN — puts those values into authorization_details, and the Resource Server compares the actual POST /payments against the approved values, RFC 9396 is doing exactly what it was designed to do. I am not identifying a gap in that pattern.

The distinction I am trying to understand is between expressiveness of the authority and how a dynamically generated invocation becomes authorized and eventually effective.

There seem to be three separate questions.

First, who establishes the authoritative values?

In an agent loop, the concrete {tool, arguments} may originate only after the model executes:

standing/delegated authority
→ model emits {name, arguments}
→ host considers invoke(name, arguments)

RAR can represent those arguments precisely. But copying the same untrusted model-generated arguments into a finer-grained authorization object does not by itself establish an independent authorization decision. There still needs to be some trusted basis — user intent, policy, prior validated state, or another authority source — against which that concrete Candidate Act is approved.

So the issue is not that model-generated values can never become authorized. It is that the same untrusted output should not effectively define both the act and its own authority without an independent validation step.

Second, reusable authority and per-invocation authority are different deployment shapes.

A host may already possess authority permitting use of a tool/API across multiple calls. RAR can express a much narrower per-call grant, but obtaining such a grant after each model emission is itself an additional authorization lifecycle. RFC 9396 does not by itself require a host holding reusable authority to stop before each invoke() and obtain or construct act-specific authority.

Third, there is the effectuation boundary.

Even where exact arguments are authorized, the property I am exploring is:

  *   verify the finalized live arguments against the act that was actually validated;
  *   verify current authority and the intended effectuation sink;
  *   handle concurrent/replayed use appropriately;
  *   and only then permit the external consequence.

This also matters for sinks that are not naturally OAuth Resource Servers, such as local function dispatch, computer-use submission, local persistent-state writes, or other host-controlled effects.

I have also been looking at Transaction Tokens and draft-niyikiza-oauth-attenuating-agent-tokens. They clearly cover parts of this space already — including transaction context, tool/argument constraints, per-invocation PoP, audience binding, and replay controls — so I would not claim OAuth work stops at coarse resource/action scope.

The residual invariant I am trying to identify is broader:

the concrete Candidate Act remains non-effective until independently authorized act-bound state is verified at the boundary capable of creating the external effect, and equivalent execution paths cannot bypass that boundary.

If the OAuth view is that this last property belongs entirely to the host/resource implementation, with OAuth providing the sufficiently specific authority object, that is itself a useful answer. If it belongs partly in OAuth, then I think the interesting question becomes where the trustworthy act-specific authorization originates and how it is carried to the final effectuation point.

Thanks — your example helped me separate these issues much more precisely.

Sangam


On Tue, 1 Sep 2026 at 3:35 PM, Yaron ZEHAVI <[e-mail]<mailto:[e-mail]>> wrote:
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 <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, September 1, 2026 9:52 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [OAUTH-WG] Binding OAuth-authorized calls to specific tool-call arguments in agentic/MCP flows

You don't often get email from [e-mail]<mailto:[e-mail]>. 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<https://www.google.com/maps/search/Am+Stadtpark+9?entry=gmail&source=g>, 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial Court of Vienna (Handelsgericht Wien).