SpendGuard

A policy guard between AI agents and PayPal: plain-English rules, single-use approvals bound to the exact order, prompt-injection checks on invoices, and a tamper-evident audit log.

Comment

Inspiration

AI agents can already create PayPal orders and invoices: PayPal's Agent Toolkit exposes tools like create_order and create_invoice. Meanwhile, the OWASP Top 10 for LLM Applications 2025 ranks prompt injection (LLM01) as the number one risk. If an agent can move money, a hidden line in a product page or an invoice note shouldn't be enough to make it pay.

What it does

SpendGuard is the policy layer between an AI agent and PayPal's write APIs, covering money out and money in.

  • Plain-English policy. Describe your spending and billing rules; gpt-4o-mini compiles them into structured rules, validated with Zod. A budget meter shows today's cap, and a dry-run lets you test a rule without saving it.
  • Decisions with reasons. The agent asks to buy; the engine returns allow, needs approval, or block, with the reason.
  • Exact-order-bound approvals. No PayPal write happens without a single-use approval token that expires in 10 minutes and is bound to a SHA-256 hash of the exact item, merchant, amount, currency and category. Capture without a token returns 403.
  • Real PayPal sandbox payments. Approved spends create and capture Orders v2 orders through the official Agent Toolkit.
  • Bill (money in). The same policy and the same token guard Invoicing v2: draft, review, create, send, remind, collections, live status and import.
  • Invoice Intake. An incoming seller invoice is treated as untrusted data. Its notes are scanned for invoice-borne prompt injection, and paying it still needs the same order-bound token.
  • Tamper-evident audit. Every decision goes into a SHA-256 hash-chained log, with a Verify button and an exportable receipt.

How we built it

  • Stack: Next.js 15, TypeScript, Zod, OpenAI gpt-4o-mini, PayPal Orders v2 and Invoicing v2 via @paypal/agent-toolkit (sandbox), Upstash Redis via the Vercel Marketplace, hosted on Vercel.
  • The LLM never touches PayPal. It only returns JSON: a policy, a purchase plan, or an invoice draft. Every PayPal write goes through one server-side service that first consumes a server-issued approval token.
  • Tests: Vitest covers policy decisions, Invoice Intake, dry-run, the hash chain, and every token failure mode (missing, replayed, expired, wrong content): 43 passing, plus 3 opt-in sandbox end-to-end tests.

Challenges we ran into

  • Persistence. Our first free host lost state when it went idle and took over a minute to wake up. Moving to Vercel meant swapping the file store for Redis.
  • One product, not two. Invoicing started as a separate app. Folding it in so Spend and Bill share one policy, one approval modal and one audit chain took a redesign, not just a new tab.
  • Binding approvals to content. Approving "a purchase" isn't enough. The token has to commit to exactly what was approved, so a swapped merchant or amount fails.

Accomplishments that we're proud of

On the production URL, the full flow works against the real PayPal sandbox: a policy compiled with OpenAI, a $35 purchase held, a 403 on capture without a token, an approved order captured as COMPLETED, an invoice created and sent, a poisoned incoming invoice blocked, and the audit chain verified intact.

What we learned

Guardrails for agent payments belong on the server, in front of the API call, not in the prompt. A content-bound, single-use token is a simple primitive that makes "human in the loop" enforceable rather than advisory.

What's next for SpendGuard

  • Replace the phrase-based injection detector with a classifier, keeping the phrase rules as a fallback.
  • Use a live merchant catalog instead of the built-in one.
  • Support multi-agent budgets and approvals through PayPal's own notification channels.

How SpendGuard maps to the judging criteria

  • Technological Implementation: real sandbox Orders v2 and Invoicing v2 through the official Agent Toolkit; /api/health reports llm: openai, paypal: sandbox-agent-toolkit, store: redis.
  • Design: Spend and Bill share one shell, with the same policy meter, decision cards, approval modal and audit log; the app explains the token next to the approve button and on the 403.
  • Potential Impact: agentic commerce is shipping now (PayPal agent tools), and prompt injection is the top risk those agents inherit. SpendGuard lets a small business's agent buy and invoice only inside a policy.
  • Innovation: one guard for both directions, exact-order-bound single-use approvals, Invoice Intake for agent-to-agent invoices, a hash-chained audit log, and policy dry-run.
  • Presentation: a 2:50 video recorded on the live site that walks the flow end to end, with captions checked against the screen.

Built With

Share this project:

Updates

Submission history