Agent payments: mandates, not trust

The budget check is inside the model

Would you give an AI your credit card? I did, for this episode. The interesting part isn’t that it worked. It’s the protocol, and the governance layer, that stopped it from spending too much.

Here’s the problem as I keep meeting it. Most agentic payment approaches wire the budget check inside the LLM: a system prompt that says “don’t spend more than $X.” That is structurally the same as asking someone to enforce their own spending limit. The model that decides to buy is the model that checks whether it should. When those are the same component, you don’t have a control. You have a suggestion.

There’s now an open protocol aimed at exactly this problem: AP2, the Agent Payments Protocol v0.2, built by Google’s A2A team and donated to the FIDO Alliance. The core move is simple: the mandate lives outside the agent. It is external, cryptographically signed, and the agent can’t override it. The agent operates inside a boundary it didn’t draw and can’t redraw.

AP2 defines a mandate chain, and the chain is the whole point: Shopping Agent, Checkout Mandate, Merchant Agent, Payment Mandate, Credentials Provider, Payment Processor. Each hop is verifiable. No hop can be skipped. A payment only happens when the entire chain checks out.

The scenario: FIFA 2026 quarter-final tickets

Abstract protocols need a concrete purchase, so the demo is a consumer shopping concierge with an unforgiving brief. The user signs a mandate: 2 Category 3 tickets to a FIFA 2026 quarter-final, under $1,500 each, with a hard cap of $3,200 total. The agent monitors TicketVault, a mock ticket marketplace, overnight. No human is present.

When a price drops, a DMN spending policy evaluates the cart in a Camunda Business Rule Task. That evaluation happens outside the model, natively in Camunda, and its result determines everything that follows. I built three paths through the same governance layer:

Path	Trigger	DMN result	Outcome
Golden	Price drops to $1,350, cart $2,700	APPROVE	Receipt for $2,700, fully autonomous
HITL	Price drops to $1,560, cart $3,120 (97.5% of cap)	HITL_REQUIRED	Payment Desk approval before checkout
Mandate breach	Standing purchase of $3,500 exceeds the $3,200 cap	DECLINE	Auto-declined before it ever reaches the processor

The golden path is the demo everyone wants to see: price drops at 3 a.m., the agent buys, a receipt is waiting in the morning. The other two paths are the product. A cart at 97.5% of the cap doesn’t sail through on a technicality; it wakes up a human at the Payment Desk. And a purchase over the cap doesn’t get argued down by a clever prompt; it is declined by a rule table before the payment processor ever hears about it.

The governance layer

The DMN spending policy is five rules, and I like that it’s boring: a cap check, a near-cap trigger that routes anything above 95% of the mandate to human review, a payment instrument whitelist, a velocity limit, and a catch-all approve. It runs in Camunda as a Business Rule Task, not inside the LLM. The agent never sees the policy as text it could rationalize around. It sees a decision result.

The third layer is the audit trail, and it comes free with the architecture. Every authorization hop lives in Camunda Operate: mandate issued, price caught, DMN evaluated, credentials issued, receipt stored. Every decision, permanently, as a process instance you can open and replay. Nobody wrote logging code to get this.

The LLM proposes. The DMN disposes. If your spending policy can be moved by a well-crafted paragraph, it is not a spending policy.

Mandates, not trust

AP2 v0.2 defines two mandate types, and each one has an open stage and a closed stage. Open means the user pre-signs the constraints. Closed means the agent signs the specific transaction that happened within them.

The Checkout Mandate. The user pre-signs the item scope, the price ceiling, a TTL, and a merchant allowlist. At purchase time, the agent closes it with the specific cart: SKU, price, checkout hash. The merchant verifies the closed mandate before fulfilling anything.

The Payment Mandate. The user pre-authorizes the funding instrument: the source, the maximum amount, category restrictions. The agent closes it with the exact amount and the checkout hash. The Credentials Provider verifies both mandates before issuing the payment token.

The closing step is where the cryptography earns its keep. Each mandate is bound to a specific transaction via an ECDSA P-256 signature. Neither mandate can be reused. Neither can be forged. And any party in the chain can verify independently, with no central authority required. That last property is what makes the chain a protocol rather than a platform.

This episode has a companion piece that goes much deeper on the protocol mechanics, the threat model, and the failure modes: the AP2 Field Guide. If this article is the episode, the field guide is the manual.

What didn’t make the LinkedIn post

This episode is still in build, so the honest notes matter more than usual.

The demo simulates several AP2 components. The Credentials Provider and the full A2A transport are mocked for demo purposes; TicketVault is a fake marketplace. What is faithful to AP2 v0.2 is the part that matters for evaluating the protocol: the mandate structure, the signing logic (real SD-JWT via jose, real ECDSA P-256 signatures), and the party interactions. And the governance layer is not simulated at all: the BPMN, the DMN spending policy, and the HITL Payment Desk are real Camunda 8 running on a live SaaS cluster.

The mandate patterns are also deliberately stack-agnostic. Camunda is my engine, but the same open-then-close mandate flow works on Temporal, LangGraph, n8n, or plain Node.js. The repo includes a MAKE_IT_REAL doc with a 5-step upgrade path from this demo to production AP2, covering exactly which mocked components you replace and in what order.

One more honest note: the repo is private until the episode ships. It goes public with the episode, alongside the demo video. The field guide is already live, because the protocol analysis doesn’t need to wait for my production schedule.

Ship log

Protocol: AP2 v0.2 (Agent Payments Protocol, Google A2A team, donated to the FIDO Alliance)
Engine: Camunda 8 (live SaaS cluster): BPMN orchestration, DMN spending policy, HITL Payment Desk
Model: Claude Sonnet as the shopping agent
Cryptography: SD-JWT via jose, ECDSA P-256 mandate signatures
Policy: 5-rule DMN decision table (cap, 95% near-cap HITL, instrument whitelist, velocity, catch-all)
Frontend: React with AG-UI over SSE, carried forward from EP 02
Backend: Node.js
Companion: AP2 Field Guide
Repo: public when the episode ships