What Is an Agent Mandate?

What is an agent mandate?

In payments, the word already has a precise meaning. In the SEPA Direct Debit scheme, the rulebook defines a mandate as "the expression of consent and authorisation given by the Debtor to the Creditor to allow such Creditor to initiate Collections for debiting the specified Debtor's account." An agent mandate is the same idea, with an AI agent acting on the consent and the consent written as a signed credential machines can check.

The Agent Payments Protocol (AP2), announced by Google in September 2025 and now being standardized in FIDO Alliance working groups, puts mandates at the center: "Mandates are the core means that AP2 uses to authorize agents." It defines two types, each in an open and a closed stage. A Checkout Mandate covers the items and purchase details and is shared with the merchant. A Payment Mandate "Authorizes a payment against a specific payment instrument" and is shared with the credential provider, networks and the merchant's payment processor. An open Payment Mandate "Captures the user's constraints on payment (e.g., budget, allowed instruments) for autonomous execution," per the AP2 site. Google's September 2025 announcement described an Intent Mandate, signed up front with the user's rules, and a Cart Mandate for the exact items and price; the current spec drops those names for open and closed Checkout and Payment Mandates. AP2's samples cover card payments and x402. Mastercard's Verifiable Intent uses mandates in the same role (see Mastercard Agent Pay), and UCP vs ACP shows where each protocol fits.

How an agent mandate works

AP2 has two modes. In Human Present, the user approves the exact checkout. In Human Not Present, the user "sees and approves a set of constraints," and the agent completes the purchase within them. The autonomous flow:

1. 1.The user signs open mandates that the agent drafted, on a trusted surface. They "MUST include the agent's public key," and the spec recommends setting their expiry "to the smallest value that will allow the Shopping Agent to complete the assigned task."
2. 2.The agent builds a checkout. The merchant returns a signed checkout.
3. 3.The agent signs closed mandates for that checkout with its own key and presents them alongside the open ones.
4. 4.Verifiers check the constraints: the merchant for the Checkout Mandate, the credential provider and network for the Payment Mandate.
5. 5.Receipts come back. If the purchase is disputed, the mandates and receipts "provide a non-repudiable picture of the transaction."

Most constraints compare one purchase with its rules: payee, instrument, amount range, date. The budget and agent-recurrence constraints need history. The spec's evaluation rule, restated as pseudocode:

on closed Payment Mandate m, under open mandate M with payment.budget:
  spent = sum of amounts of previously closed Payment Mandates under M
  if spent + m.amount > M.budget.max:
      reject                      -- Payment Receipt with an error
  approve
  spent = spent + m.amount        -- "added to the accumulated total"

That is a read, a check and a write. If two closed mandates under one open mandate are evaluated at once and the total isn't updated atomically, both can pass. AP2 also puts part of this on the agent: "Shopping Agents MUST NOT present any subsequent open Payment or Checkout Mandates without receiving a rejection receipt from the previous one." What the platform must read before it presents a mandate is its authorization-time context.

Why agent mandates matter in real-time systems

The mandate states the limit; somebody still has to hold the running total. For Verifiable Intent, the constraints spec assigns it to the network: "Payment networks MUST maintain stateful tracking of cumulative spend per L2 mandate pair when a mandate.payment.budget constraint is present." The agent platform holds the rest: which mandates are in use, purchases in flight under each, and budgets that span many mandates, such as a company cap across employees. When several workers act under one open mandate, the platform has to serialize them itself, or a worker builds and signs a purchase the verifier is about to reject.

Tacnode enforces nothing inside a network's or credential provider's records, and the verifiers' checks stay where the protocols put them. What Tacnode can hold is the platform's side: mandate usage, reservations and receipts held in Tacnode are covered by ACID transactions, so two workers cannot both reserve the remaining budget of the same mandate, and each receipt is written back as context for the next purchase. Concurrency between agents is covered in ACID for agents.

FAQ