AgentPurse: Safe Payments for AI Agents

Give your AI an allowance, not your credit card. AgentPurse lets AI agents buy safely: an AI Risk Guard checks each purchase against your budget, then PayPal pays with a single-use authorization.

Comment

Inspiration

AI agents are getting good at doing things for us, and the next obvious step is buying things for us. But today there are only two options for giving an agent money: hand it a real card or API key and hope it never goes wrong, or don't let it buy anything. Neither works.

We wanted a third option, the same one parents use for kids and companies use for employees: an allowance with rules. Give the agent a budget, a per-purchase cap, and a human in the loop for anything unusual, and never give it the card at all. That idea became AgentPurse: give your AI an allowance, not your credit card.

What it does

AgentPurse sits between an AI agent and a payment provider.

  1. The owner signs in to the web dashboard, adds a payment method to the vault, and sets an intent: a budget, an auto-approve limit ($50 in our demo policy) and a per-purchase cap ($200).
  2. The agent gets a scoped key, not the card. When it wants to buy something, it sends a purchase request to the AgentPurse API.
  3. The Risk Guard evaluates every request in layers:
    • deterministic rules (budget, caps, limits)
    • a prompt-injection scan of the request
    • a live price check against Channel3 product data
    • an AI review that can only make a decision stricter, never looser, and fails closed to human escalation if the model is slow, rate limited or unavailable
  4. The outcome is one of three: auto-approved, escalated to the owner, or denied. Escalations appear in the dashboard (Overview, Approvals, Live monitor and Studio), where the owner can approve or deny.
  5. Payment happens in two steps: the provider authorizes a hold, then AgentPurse issues a single-use signed mandate, and only then is the payment captured. Replaying a mandate is rejected with HTTP 409.

The dashboard also includes live event streaming and an AI assistant in AG Studio that answers questions about real spending data, for example "How much was spent today?"

How we built it

  • Backend: Node.js and TypeScript with Fastify, Prisma on PostgreSQL, zod validation, and Server-Sent Events for the live monitor. Deployed on Render.
  • Frontend: Next.js (App Router) on Vercel, with a backend-for-frontend layer and an httpOnly-cookie session. AG Grid and AG Studio power the analytics dashboard and the assistant.
  • Payments: a provider-neutral PaymentProvider interface, implemented with the Braintree sandbox (a PayPal service). Swapping or adding providers doesn't touch the Risk Guard.
  • Price truth: Channel3 product data to catch overpriced or mismatched purchases.
  • AI layer: a pluggable provider interface (Anthropic, Gemini, any OpenAI-compatible API, or a no-AI mode). We started with Anthropic's Claude, moved to Google Gemini when we ran out of credit, and finished on Groq, which runs an open-weight model (gpt-oss-120b) through its OpenAI-compatible API. See the next section for why.
  • Developer experience: a monorepo with a shared package, a demo agent CLI with six scripted scenarios, an OpenAPI spec, a Postman collection, and over 600 automated tests.
  • Tooling: the whole project was built with Kiro, with Claude helping on design decisions, prompts, debugging and documentation.

Challenges we ran into

  • Finding an AI provider that was reliable and free. This was our biggest challenge, and it shaped the architecture:
    1. Anthropic (Claude) was our first provider and the best fit for the review step, but our API account ran out of credit, so live reviews started failing with a "credit balance too low" error.
    2. Google Gemini was our free alternative, but the model we tried was overloaded and timing out, and the older model we fell back to was no longer available to new users. Reviews hung or timed out.
    3. Groq was the one that worked. Its OpenAI-compatible API served an open-weight model fast enough for a live purchase decision, with a free tier. After we added it, all six demo scenarios passed against the deployed system.

Because we had built a provider-neutral AI layer, each switch was a configuration change, not a rewrite of the decision logic.

  • Money can't depend on an AI that can fail. Every failure above could have approved or blocked purchases wrongly. We made the review fail closed: it can only tighten a decision, and an error, timeout or rate limit escalates to a human.
  • Free-tier limits. Groq's rate limits (requests and tokens per minute) and Render's cold starts forced us to add caching, short prompts, a reasoning-effort setting for the open-weight model, and clear "rate limited, retry after" handling.
  • Live updates across domains. The live monitor depends on exact origin configuration between the Vercel frontend and the Render API. A single trailing slash was enough to show "Offline."
  • Design churn. One restyling pass broke the interface, so we reverted it, kept the reviewed design, and limited later changes to the Studio view only.
  • Making the AI assistant safe. The Studio assistant is read-only, owner-authenticated and rate limited, with a small fixed set of tools.

Accomplishments that we're proud of

  • A complete, working flow: owner policy, agent request, layered risk decision, human approval, sandbox payment capture.
  • Six live demo scenarios that all pass against the deployed system: small safe purchase, needs approval, over cap, overpriced, prompt injection, and replay.
  • An AI review that is useful but never trusted with authority: it can only say "no" or "ask a human."
  • Surviving three AI providers in one build without changing the safety logic.
  • Single-use mandates that make a replayed payment fail by construction.
  • Good developer documentation for an early project: README, OpenAPI spec, Postman collection and a scripted demo.

What we learned

  • Safety in agent payments comes from architecture, not from a smarter model. Deterministic rules first, AI only as an extra guard, and fail closed.
  • Provider-neutral interfaces pay off: we changed AI providers twice, from Anthropic to Gemini to Groq, without touching the decision logic.
  • Open-weight models on fast inference are good enough for a narrow review task, and make the project easy for anyone to run for free.
  • Prompt injection is a payments problem, not just a chat problem. Any text a purchase request carries is untrusted input.
  • Free-tier constraints are a good forcing function: smaller prompts, caching and honest error states made the product better.
  • A tidy owner experience matters as much as the guard: a human approval is only useful if the owner is actually informed.

What's next for AgentPurse: Safe Payments for AI Agents

  • PayPal checkout adapter alongside the Braintree sandbox implementation, and a path to production payments.
  • Owner notifications by email and push, so approvals don't depend on watching the dashboard.
  • Multi-instance readiness: move the in-memory rate limiter and event bus to a shared store.
  • Agent SDKs and tool-protocol support, so popular agent frameworks can use AgentPurse in a few lines.
  • Richer policies: merchant allow-lists, category budgets, time windows and per-agent rules.
  • Benchmarking review models, including Claude, against our adversarial scenarios, and publishing a security model and threat-model write-up.

Built With

Share this project:

Updates

Submission history