Hi Sangam, Yaron, Jijie, First - sorry to be a little late to this thread - I've been traveling.
Sangam, on your original question, whether this is already solved somewhere: for the part where the call crosses a gateway or an MCP server, I think it largely is. The OpenID AuthZEN working group has a binding for it, COAZ-MCP <https://openid.github.io/authzen/authzen-coaz-mcp-binding-1_0.html>. The shape is that the PEP, either an MCP gateway or the MCP server itself, maps the live JSON-RPC message into an AuthZEN authorization request and calls a PDP before the message takes effect. Tool arguments are addressable in that mapping, so the decision is over the concrete call rather than the tool class. From a mapping declared in a tool's input schema: "action": { "name": "transfer_funds" }, "resource": { "type": "account", "id": "$params.arguments.from_account" } Two things in it speak to your first two questions. On where the authority comes from: the mapping is authored by the MCP server and the arguments come from the caller, so the binding treats both as untrusted input. Section 11.4 says policy MUST NOT treat any attribute originating in a declared mapping as authoritative for identity or privilege, and that only the subject identifier, which the PEP verifies against the validated access token, is trustworthy. So the emitted arguments are inputs to the decision and never the source of authority for it. The host does not have to construct a finer-grained authority object out of its own untrusted output. On reusable versus per-invocation authority: this gives you a per-call decision without a per-call token. The token stays as coarse as it is, and the PDP call is what narrows per invocation. Your deployment B is not inherently unenforced. It is unenforced when nothing on the path is acting as a PEP. What it does not cover is the case you and Jijie both arrived at. The binding scopes itself to gateway-as-PEP and server-as-PEP, so a host's in-process function dispatch sits outside it, and your placement point stands for that path. One more thing, since Yaron kindly named my drafts: the token issuance and token exchange profiles gate at the authorization server and decide whether a token is issued and how it is shaped. They do not see tool arguments, because at issuance time the arguments do not exist yet. Different surface from the one you are asking about. Thanks, Omri -- Omri Gazitt On Tue, Sep 1, 2026 at 12:53 AM Sangam Das <[email protected]> wrote: > 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 > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
