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
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
