Demo
One grant. Two sellers. Two ways to pay (card and invoice).
Revoked once, refused by every seller that checks.
Northwind Robotics' buying agent carries a single signed grant from its company. It buys GPU time from one seller and datasets from another: two businesses that have never met the agent, paid in two different ways, by card and by invoice. Every order is checked for authority first. When Northwind revokes the grant, both sellers refuse the next request.
Watch it end to end
Recorded from a live run in Stripe test mode. Every terminal line is the real output, in order; short pauses between steps are added for reading.
What happens, in three steps
- One grant, two sellers, two ways to pay (card and invoice). The company signs one grant: its agent may buy specific things, up to a set amount per order, until a set date. The agent buys GPU time from Acme GPU, which takes a card payment (Stripe), and datasets from Globex Data, which bills on a net-30 invoice. Both sellers accept the same grant; neither had to meet the agent first. The one authorized card purchase created a single payment in Stripe.
- Out-of-scope orders are refused before any money moves. The agent tries a $5,000 order the grant does not allow, and separately tries to buy something the grant never listed. Delegus Check answers the authority question first and refuses each one (HTTP 403) with a reason, one because it is over the per-order limit, the other because that item is not on the grant. Because authority failed, the payment step is never reached: no card is charged, no invoice is raised. "Can it be paid?" is never asked at the payment step, because "is it authorized?" already said no.
- Revoked once, refused by every seller that checks. Northwind revokes the grant. The next request to either seller, by card or by invoice, is refused, because each seller checks with Delegus Check before acting. One revocation reaches both.
What was decided, and what was paid
Each seller checks with Delegus Check before acting; Delegus Check doesn't move money. Payment is a separate question, asked second.
The payment receipt
Stripe's receipt records what was paid: the amount, the card, the charge. Stripe's seller checks with Delegus Check before charging.
The Delegus receipt
The Delegus receipt records the decision: which grant was checked, against what, and the evidence it relied on. It re-verifies offline, whichever way the order was paid, years later.
What this shows
The demo uses only what the frozen v0.2 protocol ships: a grant with per-action limits (the $5,000 order is refused because it exceeds what the grant allows per order), a signed decision for every ALLOW and DENY, and revocation that every later check sees. Each seller checks with Delegus Check before acting; Delegus Check doesn't move money. One grant, two sellers, one paid by card and one by invoice. Stripe was called exactly once, for the single authorized card purchase, and every refusal happened before any Stripe call. Each decision receipt re-verifies offline afterward, whichever way the order was paid.
Running budgets that add up across many orders are not checked in v0.2, and they are not shown here. v0.3, live now, adds budgets across orders: see Budgets.
Learn more
How the one-line middleware works: MCP servers. How a receiving service verifies an agent action: integrate as a relying party. To pilot it, write to hello@delegus.ai.