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

[Sangam Das <[e-mail]>]

Dear Yaron,

Thank you — that framing helps.
I agree that per-emission user consent is the wrong gate. A standing,
user-approved mission (or equivalent intent object) is the right place for
durable authority and constraints. Evaluating later fine-grained requests
against that mission, with AuthZEN at issuance or exchange, is a coherent
way to downscope without consent fatigue. I would treat that mission as the
independent authority source in the first question, not as something the
model is allowed to write.

Where I still want to be precise is when the evaluation is allowed to be
skipped.
If the host already holds a mission-bound token and the model emits {name,
arguments}, there are two deployments:

A. Host always token-exchanges / re-issues against current mission + live
arguments, then invokes only with the new token.
B. Host invokes with the token it already has, because the tool is in
mission scope.
A is the path you describe. It can address question 2, and
AuthZEN-on-issuance is the decision point for that new token.

B is the loop most tool hosts run today. Mission constraints never see the
live arguments unless something on the host (or at the sink) compares them.
Token issuance work does not run on that path.
Karl’s mission draft itself separates those: baseline bounds are token
lifetime and carried constraints; point-of-use evaluation against current
mission state before execute is an additional runtime profile. That runtime
check is question 3.
Ashay put the host form of it as:
MUST NOT invoke a tool sink unless the finalized parameter digest matches
an authorized policy assertion.

If the policy assertion is the approved mission (or a token derived from
it), and the digest is over the live arguments, that is A even when the
host does not go back to the AS — or it is an explicit deny on B.
So I do not see mission / AuthZEN and that host rule as competing paths.
Mission is where trustworthy act-specific authority originates. The
host/sink rule is how it is applied at the boundary that can create the
effect, including local dispatch that is not an OAuth RS.
If the WG view is “conforming agent hosts are deployment A; B is
non-conforming,” that is a clean answer. I would just want that stated,
because B is what Claude/ChatGPT/MCP loops do unless someone wraps invoke().
Thanks,
Sangam


On Wed, 2 Sep 2026 at 3:43 AM, Yaron ZEHAVI <
[e-mail]> wrote:

> Thanks for the quick response Sangram,
>
>
>
> I agree model generated output brought on every request to user’s approval
> as the sole enforcement gate presents high friction leading to
> consent-fatigue risks.
>
>
>
> There’s emerging work around first approving a higher level intent /
> mission which contains authority and constraints which may then serve as
> guardrails for fine-grained requests, serving as an additional enforcement
> gate which can reject, approve or approach user for approval.
>
> One example is Karl Mcguinness’ work on mission bound authorization
> <https://github.com/mcguinness/mission-bound-authorization>.
>
>
>
> An enforcement gate based on approved intent could enable lowering tokens
> authority and lifetime while raising the fine-grained authorization detail,
> effectively having clients make more frequent requests which are then
> evaluated against current state of agent, user and the standing mission’s
> authority.
>
>
>
> This could address the 2nd and 3rd questions you’ve named, while avoiding
> unwanted user-friction as not every client request would require user
> approval.
>
>
>
> I share your concern that these challenges are not yet sufficiently
> addressed, but see the work around approved intent / mission as well as
> policy-driven authorization decision (e.g: Omri Gazitt’s drafts on AuthZEN
> Profile for OAuth 2.0 Token Issuance / exchange) as a good path forward.
>
>
>
> Regards,
>
> Yaron
>
>
>
> Classification: CONFIDENTIAL
>
> *From:* Sangam Das <[e-mail]>
>
> *Sent:* Tuesday, September 1, 2026 12:32 PM
> *To:* Yaron ZEHAVI <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [OAUTH-WG] Binding OAuth-authorized calls to specific
> tool-call arguments in agentic/MCP flows
>
>
>
> You don't often get email from [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 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]> 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]>
> *Sent:* Tuesday, September 1, 2026 9:52 AM
> *To:* [e-mail]
> *Cc:* [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]. 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/*
> <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).
>
> 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).
>