PaySentinel

An autonomous shopping agent with a deterministic spending firewall: give it a mission and a hard budget, and it buys the cart itself through PayPal — every cart verified before money moves.

Comment

Inspiration

Agentic commerce means an AI agent completing a purchase on your behalf, not recommending products for you to buy later. The blocker is trust: the usual pattern pipes a language model's output straight into a payment API. Models hallucinate products, mangle prices, and can be manipulated by the content they read. PaySentinel closes the loop the safe way: the model proposes, plain deterministic rules verify, and only then does PayPal pay. The firewall is what makes the agent allowed to spend at all.

What it does

You give PaySentinel a mission ("set up a work-from-home corner for video calls") and a hard budget. The agent proposes an itemized cart and explains every pick, then carries the purchase through to a captured PayPal payment with a receipt and order ID — mission to money in one session. Before checkout, a deterministic spending firewall verifies the cart:

  • G1 Budget — the total must be within your hard budget
  • G2 Catalog integrity — every item must exist in the catalog at exactly the catalog price (catches hallucinated items and price tampering)
  • G3 No duplicates — quantities folded into single lines
  • G4 Quantity sanity — 1–5 per item
  • G5 Non-empty cart

The quantity cap of 5 per item is an anti-hoarding bound: missions are household-scale, so a line asking for more than five of one item signals a runaway or manipulated plan, not a genuine need.

Only an approved cart unlocks the PayPal button. PaySentinel ships with a "Simulate rogue agent" button that feeds the firewall a tampered cart — inflated price, duplicate line, fake SKU, over budget — and shows it being blocked. Every plan, check, verdict, and payment lands in an audit trail. Two simulations, not one. The loud rogue cart — inflated price, duplicate line, fake SKU, over budget — is the easy catch. The subtle one is the honest test: every line is a real catalog item, the quantities are sane, and the total stays under budget. One price is simply marked up 5%. The budget check passes, and only catalog integrity (G2) catches it — and it does. The guard also re-runs at the moment a PayPal order is created, not only when the checkout button renders, so a cart that changed after approval still cannot slip through. The test suite now runs 12 checks, including the subtle cart, which must fail G2 and only G2.

Why this is agentic commerce

The purchase loop is complete: the agent selects the items, the firewall clears them, and PayPal captures a real sandbox payment with itemized purchase units. Nothing in the flow is a mock checkout or a recommendation list. The firewall is the trust layer that lets the agent act autonomously: prices are always taken from the catalog, never from the model, and the model's output is re-resolved against catalog SKUs before any money moves. The rogue-agent simulation proves the guard holds when the agent goes wrong, which is the failure a shopping agent has to survive in production.

How PaySentinel differs

The common safeguards for agent payments are approval flows and spend caps. An approval flow puts a human back in the loop, which gives up the autonomy that makes an agent useful. A spend cap limits the damage but never looks at the cart: a capped agent can still buy a hallucinated product at a tampered price. PaySentinel verifies the cart itself. Each proposed line is re-resolved against the catalog and must match the catalog price exactly; the budget, duplicate, and quantity rules run on top of that. The verdict comes from deterministic code, so the same cart always produces the same verdict, and a blocked cart removes the PayPal button entirely. The agent stays autonomous from mission to captured payment, and the verification layer is the reason it is allowed to.

Where the catalog comes from

G2 is only as strong as the catalog behind it, so the trust story is explicit. In this demo the catalog is a small curated list shipped in the repo, and the agent can only reference it, never write to it. In production the same design takes the catalog from merchant-signed feeds, with prices cross-checked against a second independent source before the guard trusts them.

How we built it

  • PayPal: JavaScript SDK in sandbox mode, client-side order creation and capture with fully itemized purchase units (every line that reaches PayPal has passed the firewall first).
  • AI: two planners. A built-in deterministic planner (keyword/tag matching over the catalog) so the demo runs with zero setup, and an optional live LLM planner for any OpenAI-compatible endpoint (bring your own key). The model's output is treated as untrusted: SKUs are re-resolved against the catalog, prices are always taken from the catalog — never from the model — and the firewall has the final say.
  • AG Grid (community edition) renders the audit trail.
  • Plain HTML/CSS/JS modules, no build step, hosted as a static site. The guard is pure functions with a 12-case test suite (node test/logic.test.mjs — all passing).

Challenges

The interesting design problem was trust boundaries: deciding exactly which numbers the AI is allowed to influence (which items, how many) and which it must never touch (prices, totals, the decision to pay). The rogue-agent simulation exists because "the firewall works" is a claim — we wanted judges to be able to watch it refuse a bad cart.

What we learned

Verification layers that work for human checkout (review screens) do not automatically exist for agent checkout. A small, deterministic rule set between the model and the payment rail catches the failures that matter — including the ones a demo audience can reproduce in one click.

What's next

Real merchant catalogs and search, multi-currency budgets, team approval workflows (agent proposes, human approves above a threshold), and webhook-verified settlement status instead of client-side capture.

Built With

Share this project:

Updates

Submission history