Inspiration
AI agents are starting to spend real money: restocking offices, renewing software, booking travel. When a person pays, the payment itself is the proof they meant it. When software pays, there is no such proof. Nothing in the payment shows what the human actually authorized, how much, for what, or for how long. We built AuthPal to close that gap. The payments industry does not need faster agents. It needs proof of permission that travels with the money.
Why now
McKinsey estimates that by 2030, agentic commerce could orchestrate 900 billion to 1 trillion dollars of US retail revenue, and 3 to 5 trillion globally. PayPal is building for that future itself: an Agent Toolkit, an MCP server, and checkout inside AI assistants. Every one of those agents will spend money on someone's behalf. None of them can yet prove the person said yes. AuthPal is that proof. AuthPal is the customer-facing authorization: the pass says yes or no before the payment ever reaches PayPal.
What it does
AuthPal is the permission slip for AI money. A person grants an agent a signed, limited pass: a cap on each purchase, a cap per month, the categories it may buy, an optional list of approved sellers, and an expiry date. The pass is digitally signed, so it cannot be altered without detection. Every time the agent tries to spend, AuthPal checks the purchase against the pass first. If it fits, the payment goes through PayPal and the decision is written to a public ledger. If it does not fit, the purchase is refused before PayPal is ever contacted, and the refusal explains itself in plain English: over the per-purchase cap, over the monthly cap, wrong category, seller not on the list, pass expired, pass revoked. The person who granted the pass can revoke it instantly, and a revoked pass stops everything.
The pass travels. Any seller can check it before accepting an agent's order: paste the pass token on the Seller check page, enter the purchase, and get a verdict on the spot, with no account and no integration. A pass can also be single-use, dying after its first paid purchase. Agent frameworks can use AuthPal directly through its MCP server, which exposes four tools: grant a pass, check a purchase, pay with a pass, and revoke a pass. When a purchase is allowed, AuthPal creates a real PayPal order with an approve link; after the buyer approves in PayPal, a capture completes the payment and the ledger entry updates to captured.
How we built it
AuthPal is a Node.js and Express app with server-rendered pages and no build step, so anyone can read the code and run it. Each permission pass (called a mandate in the code) is a payload signed with HMAC-SHA256; verification re-checks the signature and every limit, including how much the pass has already spent this month, before any payment call is made. Allowed purchases are placed through the PayPal Orders API v2 in the PayPal sandbox, using OAuth client credentials, and the real PayPal order IDs land in the ledger next to each decision. The MCP server is hand-rolled JSON-RPC 2.0 over HTTP with no new dependencies, and it calls the same permission functions the web pages use, so every path enforces the same rules. The demo agent is deterministic on purpose: it plans purchases from a small-business catalog by keyword, so judges see the permission layer make every decision, not a language model improvising. The product direction is Michael Faber's; the engineering was done with Muse, Meta's AI assistant, which is fitting for a hackathon about the age of agents. An automated test suite of 21 tests covers the signature, tampering and forgery rejection, both caps, category and seller rules, expiry, revocation, single-use passes, and the MCP tools.
Challenges we ran into
The hard part was not calling PayPal. It was everything around the call. A refused or failed check must never count against the monthly cap, or an agent could be starved by its own mistakes. Verification had to be strict enough to reject a forged pass and plain enough that a small business owner understands every refusal without a manual. We also learned that a demo of a trust product has to run against the real sandbox, not a mock: our first live payments failed on a network stall, and only the re-run against real PayPal order IDs proved the chain end to end.
Accomplishments that we are proud of
The full loop works against the real PayPal sandbox: grant a pass, watch an agent buy inside it and produce real PayPal order IDs, watch it get refused outside it before PayPal is touched, then revoke the pass and watch it go dead. Every step is in the ledger with its reasons. The pass itself is now a designed card the owner can read at a glance, sellers can verify a pass with no account, passes can be single-use, and agent frameworks can plug in through MCP. The demo takes about two minutes and needs no explanation from us.
What we learned
Permission has to be data, not a settings page. A signed pass that travels with the payment can be checked by anyone in the chain: the agent, the payment platform, the merchant. And a refusal is a feature, not an error: the moment an agent is stopped, in words a person can read, is the moment the product earns trust.
What's next
Webhook-confirmed settlement, so the ledger reflects captured money the moment PayPal confirms it. Passes for whole teams of agents under one shared monthly ceiling. Seller checks embedded in checkout flows. The same model then moves from the sandbox to live payments unchanged.
