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

[Sangam Das <[e-mail]>]

Dear Jijie,

Thank you for the pointer to the demo repo, and for stating the boundary so
clearly.

Your three points match what I see in aic-capability-demo:

   1. Bounds come from the principal (and role intersection at the CA), not
   from the model’s emitted arguments.
   2. The HTTP/MCP gateway checks the concrete parameters against those
   bounds per request and fails closed.
   3. That enforcement is at the gateway / MCP endpoint, not inside the
   host’s first local dispatch.

That is a real answer for every call that actually crosses gateway-http.
The wallet / database / deploy / MCP matrices in the README are the right
kind of evidence for this thread.

I agree AIC composes with RAR and mission-bound authorization rather than
replacing them: the certificate is the offline-verifiable assertion; an
online decision can still narrow it.

The remaining case is the one you already named — the in-process function
table (or any other path that never presents the AIC-JWT to the gateway).
On that path the host would need to invoke the same bound-check before
invoke(), or it is an alternate route around the sink you implemented.

I do not read that as a defect in AIC. It is a placement question: gateway
for networked MCP/HTTP, host wrap for local dispatch.

I will look through the repo in more detail. Happy to map a single MCP
tools/call against your std/mcp-v1 allowlist if that is useful.

Thanks again,
Sangam

On Wed, 2 Sept 2026 at 10:56, Jijie Wei <[e-mail]> wrote:

> Sangam, you asked whether this gap is already solved somewhere. We have
> implemented an answer in the AIC work and it is running; details and test
> matrices are in the public demo repo below.
>
> The pattern, in the vocabulary this thread has converged on:
>
> 1. The policy assertion is certificate-bound and independent of the model
>    output. A principal signs a DelegationAuthorization carrying capability
>    declarations with precise parameters (database: tables, columns,
>    row_filter, limit; wallet: assets, per-transaction amount, recipient
>    allowlist; MCP: tool allowlist). These are encoded in an X.509 agent
>    certificate and its JWT carrier. The authorized bounds come from the
>    principal (optionally intersected with the operator role's policy at
>    issuance) -- never from the model's emitted arguments.
>
> 2. Enforcement happens at the sink boundary. An AIC-aware gateway verifies
>    the presented credential, then checks per request that the concrete
>    operation parameters fall within the certificate's declared bounds
>    before forwarding. For MCP, a tools/call must reference an allowlisted
>    tool; the structured operation (table, amount, recipient, environment,
>    tool) is matched against the bound parameters. Unknown or out-of-bounds
>    operations are denied (fail-closed).
>
> 3. One boundary I want to state explicitly: this enforces at the network
>    gateway / MCP endpoint, not inside the host process's first dispatch
>    (the function table). In-process enforcement would require the host to
>    invoke the same verifier at that earlier point; that is a different
>    layer.
>
> The credential is transport-identity anchored (X.509 presented over mTLS,
> or a short-lived JWT issued from the same CA). This composes with, rather
> than replaces, RAR / mission-bound dynamic authorization: the certificate
> supplies offline-verifiable bounds, and an online policy decision can
> further narrow them.
>
> Running implementation (capability schemes, gateway plugins, test
> matrices): https://github.com/varwof/aic-capability-demo
>
> Happy to map the details if useful.
>
> Best,
> Jijie Wei
> --
> WIMSE mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>