An AI agent, paying suppliers under bounded authority.

A CommBiz customer delegates a bounded payment authority: AUD 50,000, 30 days, one approved supplier. An accounts payable orchestrator spawns one sub agent per invoice and settles them across MCP resource servers, while the bank grants, narrows, holds, or refuses every step. Press a scenario and watch the authority flow, shrink, and snap.

Guardrails, each one supposed to fail

Idle press a scenario to begin

Authority envelopeAUD 50,000

supplier_payment

Budget remainingAUD 50,000

enforced at payments RS

Start with 1 · Register & attest, then 2 · Delegate authority, then run the supplier payment run.
Click any actor or hop to open the inspector.

Granted Narrowed Denied Read / info Human step-up Held for a second approver client_id ap-orchestrator-agent client_id payments-agent Click any hop to inspect the real artifact

Same client_id and key = a spawned sub agent (narrowed authority inside one agent identity). Own client_id and own attestation = a distinct agent (its own identity, acting on the customer's behalf).

What you are looking at: Raidiam product reference implementation, stands in for your authorisation server CBA side illustration The CommBiz OP on this stage is a reference implementation deployed for the demo. It stands in for Ping or Entra and is not a Raidiam authorisation server. Open any actor to see its treatment.

Tracethe live run, hop by hop, click a card for the decoded token, RAR & MCP call

Standards, honestly mapped

This console runs on real specifications, plus a small profile of its own. We label which is which: an established standard versus this demo's profile. We do not claim a spec endorses what it does not.

StandardThis demo’s profile

The two gates on every hop

Every hop is checked twice at the token endpoint. Client eligibility is the enforced OAuth gate, off the token: may this client obtain a token carrying these scopes / authorization_details types at all? Standard OAuth answers that from the client’s registered metadata (its allowed scopes; some servers also bound authorization_details_types). The Trust Controller (Raidiam Connect) just packages that eligibility into a named, reusable bundle, a “role”, but the authorisation server still enforces the resolved metadata, not the role. Envelope asks whether the request is within what was delegated: a type within a held type, amount ≤ parent? And separately, RAR (RFC 9396) is the authority on the token, typed authorization_details where the type carries the power and purpose rides inside, binding use + audit. Eligibility (off the token) gates the request; purpose (on the token) governs its use. Narrowing only moves down; amounts only shrink.

Model A vs Model B, watch the client_id

Model A (one client). The sub agents run inside one OAuth client: an orchestrator spawning workers it controls, one per invoice. The act chain grows (ap-orchestrator to invoice-agent to payment-agent) but client_id stays ap-orchestrator-agent on every hop. Model B (cross agent). The settlement leg is handed to a genuinely separate Payments Agent, its own client and its own attested key. It authenticates as itself and re-exchanges the invoice token on the customer's behalf (RFC 8693 on behalf of across distinct clients), so the payment hop's client_id changes to payments-agent. Run both (3 and 4) and compare the settlement step in the inspector.

The full actor list

Honest limits, what this is, and isn’t

When the pill reads Live, this console is bound to the real agent backend over same origin JSON and SSE (/state, /run/stream, /envelope, /delegation/status, /revoke): the tokens, act chains, MCP calls and 401s in the inspector are the actual signed artifacts the services produced. When the backend is unreachable the pill reads Replay and the same beats render from a faithful model of that trace, so the shape is honest but the tokens are illustrative rather than freshly signed. The authorisation server, resource servers and agent provider on this stage are demo deployments: the CommBiz OP is a reference implementation standing in for Ping or Entra, and no mTLS, DPoP or PAR is in play.