Inspiration

Autonomous agents already draft invoices, hire contractors, negotiate rates, and fill in forms. The moment money moves, a business owner faces two bad choices: hand the agent the PayPal token and pray, or keep a human in every single step and become an approval button.

Escrow protects the buyer from the seller. Nothing protects a business owner from their own AI agent.

Underneath both bad choices is the same fatal flaw: the rule that decides whether money may move lives in a prompt or in someone's head, not in deterministic code the owner controls. One prompt injection, one hallucinated vendor, or one misplaced decimal point, and the account is drained.

Mandate is the third option. An agent gets a wallet of authority, not a wallet of money.


What it does

Mandate is a deterministic spend-authority layer in front of PayPal. Staff and AI agents ask; a pure function of the owner's signed rules decides; PayPal moves exactly the cents that were locked.

  • Anyone can ask, nobody can pay: Agents connect over the Model Context Protocol (MCP) with keys carrying six tools—none of which can approve, pay, or change rules.
  • A pure function decides: Every charge, payout, and refund receives DENY, AUTO, or NEEDS_APPROVAL from a deterministic decide() function—no LLM makes the payment authorization decision. It enforces payees, categories, monthly caps, milestone limits, funding coverage, and duplicate asks.
  • Say yes to the rule, not the payment: A signed standing rule ("Priya is paid from settled Northwind money, up to her 60% share") lets matching payouts clear automatically with zero taps. Everything else waits for the owner.
  • Bilateral AI negotiations: Two companies' autonomous agents negotiate contracts move-by-move across private reservation prices. A deal is signed only after both sides' private rules validate the agreed figures.
  • Money in releases money out: A contractor is paid only from client money that PayPal confirms has settled on the same job, never above their share, and never before funds arrive.
  • On-page card payments: Clients pay right on our page using PayPal's native Card Fields (Orders v2) with zero redirects. The server re-reads the order and refuses to capture if the amount or currency deviates by a single cent.
  • Tamper-proof receipts: Every transaction locks parameter hashes signed with Ed25519. Anyone can verify receipts offline in the browser without trusting our server.

How we built it

  • Server: TypeScript on Node.js 24, Hono, Zod, and node:sqlite using immediate transactions. Integer cents everywhere, idempotency keys on every write, and OpenAPI specs for all 118 routes.
  • PayPal Rails: Orders v2 (card fields on-page), Payouts v1 (contractor disbursements), Payments v2 (refunds), Invoicing via Agent Toolkit, disputes, and webhook signature verification.
  • Authority & Security: A deterministic gate (decide()), SHA-256 locks signed with Ed25519, WebAuthn passkeys for biometric taps, and HMAC-SHA256 machine keys.
  • AI Layer: Open-weights models on Ollama Cloud (gpt-oss:120b for negotiators, gemma4:31b for rule drafting, gpt-oss:20b for the clerk). Prompts are versioned, fenced against injection, snapshot-tested, and audited by output guards.
  • Console & Analytics: React, Vite, TanStack Query, vanilla CSS; an AG Grid ledger with live filtering and CSV export; and a control room powered by AG Studio with an AI dashboard analyst.
  • Testing: 891 API tests (including 46 red-team attack suites and fast-check property tests) and 150 browser test runs via Playwright.

Challenges we ran into

  1. Concurrency and Exactly-Once Execution: Preventing duplicate asks, webhook replays, and background sweeps from racing on the same row. Solved with stable ask-hashes, duplicate.open guards, and atomic SQLite transactions.
  2. Settling to the Cent: When a payment differs from an invoice, the system forces PayPal API gap accounting (discounts, fees, credit notes). If no PayPal field justifies the discrepancy, the transaction halts.
  3. Private Bilateral Limits: Keeping client reservation prices strictly hidden from studio owners during AI negotiations required server-level redaction and cryptographic signing boundaries.
  4. Validating 3-D Secure: Client browsers can misreport 3DS status; our server verifies the issuer's response directly from PayPal's recommended action matrix before capturing funds.
  5. Card Form State Persistence: The client checkout page previously refreshed on state change, resetting what the buyer typed into the credit card fields. We re-architected it to isolate the card frame from background SSE stream updates.

Accomplishments that we're proud of

  • 891 API tests across 75 files passing clean in CI, with comprehensive red-team penetration suites.
  • 23 verified cryptographic guarantees checked on every build (e.g., no payout exceeds contractor share, unsettled funds cannot be paid out, AI cannot touch PayPal tokens).
  • End-to-End Real PayPal Sandbox Proof: Real Orders v2 card captures (16863006RF678602F), paid Invoices (INV2-76H8-5LLT-E4P4-C2HD), and live Payouts v1 disbursements (SJ5B3GGM7UBAU) executed without human taps via standing rules.
  • Zero-Trust Offline Receipt Verification: Downloadable receipts verify directly in the browser against public keys with zero backend round-trips.
  • Production Accessibility & Performance: Mobile Lighthouse score of 90 on Welcome, 88 on Unlock, and automated axe WCAG 2.1 AA audits passing on every authenticated screen.

What we learned

  • AI may only add friction: A model can flag anomalies or demand an owner tap; it must never possess the power to approve or pay. Every architectural decision flows from that single principle.
  • A rule in a prompt is not a rule: Only versioned, deterministic data executed by pure functions provides the auditability required for enterprise financial compliance.
  • Refusals are the product: Operators don't just ask "how do I pay?"—they ask "why did this fail?" Clear, auditable rejection codes (payee.unknown, funding.missing, cap.monthly) build user trust.

What's next for Mandate

  • PostgreSQL & Multi-Tenancy: Moving from single-tenant embedded SQLite to distributed PostgreSQL for enterprise scale.
  • Multi-Rail Expansion: Applying the same deterministic spend boundary to ACH, corporate debit cards, and stablecoin payouts.
  • Agent Payments Protocol (AP2): Adopting AP2 standard credential formats so Mandate authority locks can travel seamlessly across external agent payment networks.
  • Quorum Approvals: Multi-signature threshold approvals for high-value transactions exceeding configurable enterprise policy thresholds.

Built With

Share this project:

Updates

Submission history