AP2 spending mandates: let an AI agent shop inside limits you sign

A signature on a mandate must be readable to the person signing it. A plain hex string tells a user almost nothing, which is why the Ethereum community wrote EIP-712. It sets a way to hash and sign typed data. So the wallet can show named fields like the spending limit, allowed merchant, and expiry ^[3]. The standard states its aim plainly. Signed messages used to be unreadable hex, and this method lets the user see the data to check it before signing ^[3].

EIP-712 also defines a domain separator that ties a signature to one app. So a signature made for one purpose cannot easily be reused somewhere else ^[3]. The standard notes it does not include replay protection by itself. So the protocol using it must handle that separately ^[3]. For a mandate, that means the signed data should carry its own expiry and purpose, and the verifier should check both.

AP2 is a protocol layer, not one signature scheme. So the exact encoding for a given mandate depends on how each app builds it. When an app uses EIP-712, the typed structure gives the user a readable object to approve. It also gives a merchant a fixed hash to check ^[3].

Readable typed data also helps a user catch mistakes before signing. A mandate that names a merchant, a limit and an expiry is easier to check than a long string of hex characters. The EIP-712 standard puts a chain identifier in its domain separator. So a wallet can refuse to sign when the chain does not match the active network ^[3]. That check is one small step in a larger review, but it shows how the signing format itself can warn a user before money moves.

This is the point most often misread, so it deserves to be stated plainly. A mandate is a statement of what the user authorized. It does not force a merchant to accept it. The protocol's model depends on the merchant verifying the mandate before accepting an agent's payment. A merchant that does not check the authorization is not bound by it. The user is then left with whatever protection the payment rails offer by default.

This is why the AP2 documents stress that the protocol aims to create a common language for compliant agents to transact with compliant merchants ^[2]. Interoperability is the goal, and it only holds when both sides speak the same verification rules. An agent builder should not assume that a signed mandate will be honored by every seller on the internet. It will be honored by sellers who run the check.

A merchant that wants to honor a mandate needs a verifier that reads the signed fields and checks them against the sale. The AP2 specification describes this chain of verifiable credentials, but a seller must still build the check into its checkout flow ^[2]. Until it does, the mandate works only as evidence of intent, not as an enforced limit. Agent builders should ask sellers directly whether they verify mandates before routing a large payment through them. Where the answer is no, the user's protection rests on the rails behind the purchase, not the signature.

SpendTheBits offers spending mandates that follow the AP2 pattern. A mandate is a signed message, not a payment.

It is important to be precise about compatibility. SpendTheBits mandates are AP2-aligned, not AP2-compliant. The alignment is in the idea: a user signs bounded authority, and a merchant that checks it can enforce the bounds. The conformance is not yet there. We built the signing side this way. A user can set limits today without waiting for every seller to adopt the same checker.

Per-purchase and 24-hour caps are useful because they bound the damage from a bad decision. An agent that makes up a large purchase, or a prompt injection that tries to drain a wallet, hits a ceiling it cannot raise by itself. The mandate is an external rule that the model does not control. That separation is the real value: the model proposes, and the signed rule disposes.

Limits do not solve everything. A mandate cannot stop a merchant that ignores it, and it cannot protect a user who signs one that is too generous. In short, a mandate narrows what an agent can do and makes its authority legible to anyone who checks. For a wider view of capping agent spend, see our piece on AI agent wallet spending limits. To set the caps, read how to set spending guardrails.

Caps are easiest to reason about in plain currency terms. A per-send cap limits one bad choice. A rolling 24-hour cap limits how much an agent can do in a day, even across many small choices. SpendTheBits applies spending guardrails. Loosening a guardrail is held behind a delay, so a thief with an unlocked phone cannot raise the limit at once. These controls sit outside the model, the same principle a mandate relies on. Neither replaces careful review of what the agent may buy.

If you are building an agent that will spend money, start by deciding which merchants will check mandates and which will not. Treat the unchecked merchants as outside the protocol's guarantees and restrict your agent to checked sellers when the stakes are high. Keep mandate lifetimes short, so a leaked signature quickly loses value. Also keep per-purchase caps low until the agent has behaved well over time.

An agent that holds the key signing its own mandates has no real limit. Third, expect the specification to change. The AP2 repository is public and still includes sample and SDK code. So users should pin versions and read release notes before upgrading ^[1]. To learn how an assistant can be steered into bad actions, read our note on prompt injection in crypto AI assistants. It explains why the rule should sit outside the model.

Finally, read the wallet's own documentation for how mandates are shown and revoked. Whatever tool you use, the test is the same. Can the person who signed see exactly what they agreed to, and can a merchant prove it before taking the money? That is the whole job of AP2 in one sentence.