Mandate

Spend authority for autonomous agents — signed, scoped, revocable budgets that let AI agents pay with PayPal inside limits a human sets.

Comment

Inspiration

Agents can already browse, plan, and decide. The one thing we still do not let them do is spend money — because a card number is all-or-nothing. It cannot say "up to $150 per purchase, only at these merchants, only for footwear, ask me above $100, and stop the moment I say so."

That is not a model problem. It is an authorization problem. Mandate is the missing primitive: delegated spending authority that an AI agent can carry and a payment gateway can verify.

What it does

A human issues a mandate: total budget, per-transaction cap, approval threshold, merchant allowlist, authorized categories, velocity limit, and expiry.

The agent receives an HMAC-SHA256 signed capability token. On every purchase attempt, the gateway:

  1. verifies the token signature — the agent cannot edit its own limits;
  2. runs the policy engine: status, expiry, merchant, category, per-transaction cap, remaining budget, and velocity;
  3. if the amount is above the approval threshold, stops and asks the human;
  4. otherwise creates and captures a PayPal Orders v2 payment;
  5. writes an auditable ledger entry for every check and every order.

When the human approves, the mandate is re-checked before capture, so a revocation or expiry that happened while the request was pending still wins. Revocation itself is server-side and instant: the token remains cryptographically valid, but the gateway refuses it.

The demo storefront shows all three outcomes in about a minute: an autonomous purchase inside the rails, a cheaper listing blocked because the marketplace is not on the allowlist followed by a human approval, and an instant block after revocation.

How I built it

  • Backend: Python 3 standard library only. python3 app.py and it runs — no pip install, no build step, no database, no framework.
  • Payments: PayPal Orders v2 — create order, capture order, plus a webhook receiver with signature verification. Runs against the PayPal sandbox when credentials are set, and falls back to a clearly labelled mock so judges can run it with zero setup.
  • Authority: HMAC-SHA256 signed capability tokens. Token limits are the authority; revocation lives server-side so it can change independently.
  • Policy: a pure, fully unit-tested engine that returns a verdict and a human-readable reason for every rule it checked.
  • AI: an OpenAI-compatible planner converts a goal into a structured search plan, with a deterministic heuristic fallback. The model proposes; the policy engine disposes.
  • Frontend: hand-written HTML/CSS/JS with a live decision trace, approval queue, and ledger. No framework and no build step.
  • Tests: 20 unit and integration tests covering every policy rail, the token layer, and the PayPal client against a stub server.

Challenges I ran into

  • Explainability over booleans. A blocked payment is useless to a user unless they can see which rule fired. I rebuilt the policy output as a per-check audit trail, and that became the core of the UI.
  • The model must never be the security boundary. It was tempting to let the LLM judge whether a purchase was allowed. I kept every authorization decision in deterministic code and let the model only plan the search.
  • Approval races. Between "agent asks" and "human approves", the mandate can be revoked, expire, or run out of budget. The gateway re-evaluates before capture.
  • Zero dependencies. Without a web framework I wrote the HTTP routing, JSON persistence, and token layer myself — which made the security model easier to explain and the whole thing trivial to run.

Accomplishments I am proud of

  • A genuinely working prototype that runs with a single command and no setup.
  • Tamper-evident spending limits: rewriting the budget in the token fails signature verification.
  • Human-in-the-loop that is actually enforced, not decorative.
  • 20 passing tests covering every policy rail and the token layer.
  • A demo that tells the whole story — autonomy, escalation, revocation — in under three minutes.

What I learned

  • Agentic commerce is an authorization problem before it is a UX problem.
  • Users and merchants will need explainable decisions, not risk scores.
  • The right split is: the model proposes, deterministic policy disposes.
  • A capability token plus a server-side revocation list is a surprisingly small amount of code for a large amount of trust.

What's next for Mandate

  • Vault a funding instrument per mandate, so agents never see payment details.
  • A merchant-side SDK to accept a mandate_token at checkout.
  • Sub-mandates: an agent delegating a narrower budget to a specialist agent.
  • Exportable audit packs and spend analytics for finance teams.
  • Replace the mock catalog with a real merchant feed.

Built With

Share this project:

Updates