Agent payment mandates need enforcement, not just signatures
AP2 and x402 let agents pay. A signed mandate says what an agent may spend; something still has to stop it spending more. Where enforcement should sit.
5 min readThe plumbing for agent payments arrived fast. Google's Agent Payments Protocol (AP2) launched in September 2025 with more than 60 partners. Coinbase's x402 moved to a neutral foundation under the Linux Foundation in April 2026, and has processed more than 165 million payments. Card networks have agent token and agent identity programs.
These standards answer two questions well: how does an agent pay? and who is this agent? A third question gets much less attention: what stops an agent spending more than it was allowed to?
Three agentic payment protocols
x402 turns HTTP's long-unused 402 status into a payment flow. A server replies "payment required" with its terms. The agent's wallet signs a stablecoin payment and retries the request with proof of payment. It's simple and fast, and suits payments of a few cents. But the protocol has no model of limits. How much an agent may pay, to whom and how often is left to whoever builds the wallet.
AP2 goes further. It expresses the user's authority as signed mandates. An open payment mandate can carry a budget, an amount range, allowed payees, allowed payment instruments, an execution window and recurrence rules. Merchants, credential providers, networks and processors each verify the mandate for the transaction in front of them.
Verifiable Intent, a Mastercard draft, goes further still. Google and Mastercard contributed AP2 and Verifiable Intent to the FIDO Alliance in April 2026. In Verifiable Intent, the user signs constraints, including a cumulative budget, and the agent signs the final values within them. The spec says payment networks "MUST maintain stateful tracking of cumulative spend per L2 mandate pair".
That is real progress. A mandate turns "the user said it was fine" into a signed, machine-readable statement of what's allowed.
Verifying a mandate isn't enforcing it
A mandate is a statement. Enforcement is a point in the flow where a payment cannot be signed unless the mandate holds. The two differ in three ways.
1. Some limits need state. "No more than $500 this month", "at most 10 payments" and "stay within budget" all depend on what has already been spent. Each verifier sees one transaction. None of them sees the running total unless someone tracks it. If the wallet tracks it, the limit is only as strong as the wallet code. If nobody does, the budget is a suggestion. AP2 doesn't say who keeps the total. Verifiable Intent gives the job to the payment network, which helps, but the running total then sits in the network's own ledger, where neither the owner nor the merchant can check it.
2. Checks after signing come too late. When a merchant or network rejects a payment that breaks the mandate, the attempt has already happened. On card rails, a mistake can be disputed. With stablecoins, a signed payment that reaches the chain is final. The cheapest place to stop a bad payment is before the signature exists.
3. The agent sits too close to the key. In many agent wallets, the code that decides to pay and the code that signs run side by side. A prompt-injected or buggy agent doesn't need to forge a mandate. It only needs the wallet to sign something the mandate never covered.
None of this is a flaw in the protocols. They define the message and who checks it. Where the limit is enforced is left to implementers, and that's where the risk sits.
Additionally, every one of these standards covers payments only. An agent that also trades, borrows or stakes needs the same enforcement point for those actions, so a payment budget and a trading limit are checked against the same account.
Enforcement should sit between the agent and the key
The pattern that closes the gap is an enforcement point at signing, between the agent and the key:
- The owner approves the mandate with their own key: payees, budgets, amount ranges, windows, recurrence.
- The agent proposes a payment. It never holds a signing key.
- The enforcer checks the payment against the mandate and the running state: amounts spent, payments made, time remaining.
- Only a passing payment is signed, along with a proof that it satisfied the mandate at that state.
- Downstream parties check the proof: the facilitator, payment service provider (PSP), merchant or network, without trusting the wallet's code or logs.
This fits both protocols. With AP2, the proof travels with the payment mandate as evidence it was honored, including cumulative limits that no single verifier could see. With x402, a facilitator can require a valid proof before it settles, so merchants accept only payments that came from a bounded agent.
Pakt agentic guardrails
Pakt runs this pattern today, in beta, for AI agents trading Hyperliquid perpetuals, a more demanding case than payments: account-level limits on leverage, concentration and reserves, checked against projected state after each order. Orders are checked inside secure hardware (a TEE), signed only if every rule passes, and come with a zero-knowledge proof generated in under two seconds. Refused orders never get a signature.
Payments need simpler rules (payees, budgets, windows) but the same three guarantees: enforced outside the agent, enforced before signing, and provable to anyone downstream. Pakt builds these checks to each use case.
An invitation to protocol builders
Agent payments will scale only if merchants, PSPs and issuers can accept them without auditing every wallet. Signed mandates give the ecosystem a shared language for what agents may do. The next step is a shared way to prove they did only that.
We'd like to work with protocol contributors and PSPs on an enforcement profile: what a proof of mandate compliance should contain, and how facilitators and verifiers can check it.