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