Delegus

Demo

One grant. Two sellers. Two rails.
Revoked once — refused everywhere.

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, settling on two different payment rails. 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, with example companies. Every terminal line is the real output, in order; short pauses between steps are added for reading.

What happens, in three steps

  1. One grant, two sellers, two rails. 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.
  2. 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 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?" (the payment rail's 402) is never asked, because "is it authorized?" already said no.
  3. Revoke once, refused everywhere. Northwind revokes the grant. The next request to either seller — on either rail — is refused, because each seller checks with Delegus before acting. One revocation reaches both.

Who authorized it, and what was paid

Delegus sits on the buyer's side of two sellers at once, and it does not move money. The payment rail is a separate question, asked second.

The payment receipt

Stripe's receipt records what was paid — the amount, the card, the charge. Stripe is a verifier in this demo, not a competitor: its seller calls Delegus /verify before taking the payment.

The Delegus receipt

The Delegus Decision Receipt records who authorized it — which company's grant allowed this action, under which mandate, and the evidence the decision rested on. It re-verifies offline, for either rail, 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. It is buyer-side and rail-neutral: one grant, two sellers, a card rail and an invoice rail. 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, on either rail.

Running budgets that add up across many orders are not part of v0.2; v0.3 specifies those, and they are not shown here. Northwind, Acme GPU and Globex Data are example companies.

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, the founding pilot program.