Delegating Spending Authority to an Agent

Lesson 1 ended on the hard question. Payments assume a present, deciding human, and an agent removes them. So how do you let software spend your money?

The naive answer is to give the agent your card number. This is a catastrophe, and it is worth being precise about why. A card number is a bearer credential: whoever holds it can spend, at any merchant, for any amount, until the card is cancelled. Hand that to an agent and you have granted unbounded, irrevocable, unauditable authority. A bug, a prompt injection, or a compromised agent means arbitrary spending. Worse, you would have no way to prove afterward what you did and did not authorize.

So the real problem is not "can an agent submit a payment?" Technically, trivially, yes. The problem is:

• Authority: how does the agent prove it is genuinely acting for you?
• Bounds: how is what it can spend limited in advance?
• Evidence: when the charge is disputed, who can prove what was authorized?

Those three questions are what every agentic payment protocol is answering, and they are security questions, not shopping ones.

The good news is that Lesson 1 already revealed the shape of the answer. Tokenization showed that a payment credential can be deliberately weaker than the card it represents, scoped to a merchant, revocable. Agentic commerce takes that principle and pushes it much further.

The organizing idea has a name in security, and recognizing it demystifies the whole field. It is the capability: instead of handing over a key that opens everything, you issue a narrow, unforgeable permission to do one specific thing.

The contrast is sharp:

The principle underneath is least privilege: grant the minimum authority sufficient for the task, and no more. It is old, well-understood engineering, and agentic commerce is essentially its application to money.

The move is to stop asking "how do we trust the agent?" and instead ask "how do we make trusting it unnecessary?" If the credential an agent carries can only buy one thing from one seller for one amount, then a compromised agent, a hallucinating agent, and a malicious agent are all bounded by the same wall. You do not have to trust the agent's judgment; you constrain its reach.

Every scheme in this lesson is a variation on that idea. What differs is where the boundary is drawn and who signs what.

The cleanest concrete instance is the Shared Payment Token (SPT), part of the Agentic Commerce Protocol (ACP) that OpenAI co-developed with Stripe.

The SPT is a payment credential with four restrictions baked in. It is:

• Bound to a specific merchant, useless anywhere else.
• Bound to a specific amount, it cannot be inflated.
• Time-bounded, it expires.
• Single-use, it cannot be replayed.

Walk the consequences, because each one kills a specific attack. A token leaked in transit cannot be spent at a different store (merchant-bound). An agent tricked into paying more cannot (amount-bound). A token captured today cannot be used next month (time-bounded). A token cannot be charged twice (single-use).

Compare this to the alternative, an agent holding your card. The card is a skeleton key valid everywhere, forever, for any sum. The SPT is a ticket for one show, one seat, one night.

And notice the lineage from Lesson 1. Network tokenization already scoped a credential to a merchant. The SPT adds amount, time, and single use. It is the same idea with the screws tightened, which is exactly why the payments industry could adopt it quickly: it is not a new trust model, it is an existing one taken further.

What the SPT does not answer is the question of intent. It proves the payment is permitted. It says nothing about whether you wanted this particular pair of shoes.

Google's Agent Payments Protocol (AP2) attacks the intent question directly, and its mechanism is the most conceptually interesting in agentic commerce.

AP2 is built on Mandates: cryptographically signed digital artifacts that serve as auditable proof of a user's instructions. Each Mandate is a W3C Verifiable Credential, signed by the user's wallet or the agent's key, and passed between parties as a verifiable JSON object. The protocol defines two stages.

The Intent Mandate captures your high-level instruction, with its scope and constraints, and you sign it in your AP2-compatible client. For example:

Intent Mandate (signed by the user)
  "Buy a pair of running shoes,
   size 10, under $150, white or grey,
   deliver to my saved address"

Critically: the agent cannot exceed this scope without re-prompting you. The constraint is not a suggestion in a prompt, it is a signed boundary.

The Cart Mandate is produced by the merchant or merchant-side agent. It binds a specific SKU, price, tax, shipping, and total to that Intent. The buyer-side agent then verifies the Cart against the Intent before forwarding anything to payment. If the cart says 180 dollars and the intent said under 150, it fails, mechanically.

If conditions of the Intent Mandate are precisely met, the agent can sign the Cart on your behalf; otherwise it needs your approval. Finally, the payment method is linked to the verified contents of the Cart Mandate.

The reason AP2's design matters is what the chain produces at the end. The complete sequence, intent, to cart, to payment, creates a non-repudiable audit trail that answers the critical questions of authorization and authenticity.

Unpack "non-repudiable," because it is the load-bearing word. It means no party can later deny their part. The intent is signed by you, so you cannot claim you never asked for running shoes under 150 dollars. The cart is signed by the merchant, so they cannot claim they offered different terms. The payment is bound to that specific verified cart, so nobody can claim a different amount was agreed.

Why this matters practically: recall from Lesson 1 that card-not-present disputes come down to who can prove what, and that the merchant usually eats the loss. Agent transactions threatened to make this far worse, an unverifiable claim that "my AI bought this, I never approved it" would be impossible to adjudicate and would make merchants refuse agent traffic entirely.

A signed intent-cart-payment chain turns that argument into evidence. The dispute stops being one person's word against another and becomes a question of which signature is missing.

This is why AP2 leans on verifiable credentials rather than simply logging things. A log is a claim; a signed credential is proof. The protocol is not really about payments, it is about manufacturing evidence in a transaction where the human was not watching, which is precisely the gap Lesson 1 identified.

Scoped tokens bound the damage and mandates prove intent. One question remains from Lesson 1: the issuer decides, and it declines what looks anomalous. An agent buying at machine speed looks exactly like fraud. So the networks had to give issuers a way to tell the difference.

Visa built this into Visa Intelligent Commerce, and on 10 June 2026 connected its payment network to ChatGPT, letting agents complete purchases at any Visa-accepting merchant. What Visa contributes is precisely the missing infrastructure: the global network, payment tokenization, authorization, agent identification, and fraud monitoring. Note that list, it is Lesson 1's machinery, plus one genuinely new element: agent identification. That is the piece that lets an issuer's fraud model see "this is a known agent acting for this cardholder," rather than an unexplained 3am purchase.

Mastercard built Agent Pay, and extended it to Agent Pay for Machines (AP4M), aimed at agent-to-agent transactions, a future where businesses offer services that AI agents purchase and consume directly. That is a notable widening: not an agent shopping for a human, but software buying from software.

Google announced its Universal Commerce Protocol at NRF with Etsy, Shopify, Target, Wayfair, and Walmart, endorsed by Adyen, American Express, Mastercard, PayPal, Stripe, Visa, and Worldpay.

Read that participant list carefully. The networks, the processors, and the large merchants are all present. Whatever else is uncertain, the incumbents are not being disintermediated here, they are building the rails themselves.

Above the cryptography sits a layer of plain policy. Agentic transactions operate inside guardrails that the consumer or business sets: spending limits, required approval thresholds, and permission layers that keep the buyer in command even when an agent executes the work.

The approval threshold is the elegant part, and it resolves the tension the whole field faces. Full autonomy is useful but unsafe; full confirmation is safe but pointless (if you approve every purchase, the agent saved you nothing). A threshold gives you both: let the agent act freely below a line you choose, and require you above it. Reorder printer paper autonomously; ask before booking a flight.

Notice how the layers stack, each answering a different question:

They are complementary, not competing. A scoped token without a mandate proves permission but not intent. A mandate without a scoped token proves intent but leaves a spendable credential loose. Defense in depth: each layer assumes the others might fail.

Which is the right instinct, because Lesson 3 is about what happens when they do.

The user signs an intent mandate bounding what may be bought; the agent shops and the merchant returns a cart mandate binding exact terms; the agent verifies cart against intent, a scoped single-use token is issued for that merchant and amount, and the issuer approves it using agent identification.