Sign the limits, not the purchase

If your agent asks for your thumbprint every time it's about to act, you're not delegating, you're babysitting. AP2, the Agent Payments Protocol, fixes that with a mandate: you sign the limits once, on a screen no agent controls, and the agent acts later inside them without you. Whoever it hands the mandate to can check, cryptographically, that it stayed inside the lines. It was built for shopping, but as Alan from Google put it on stage, it really is delegated user authority, and it's broadly applicable.

That line comes from the last conversation of the day-two livestream at AGNTCon + MCPCon North America, October 23, a tour of Google's pile of agent protocols. It's about two minutes long, and it names a problem I have with every agent I run.

Payments was the hardest test, not the point

Alan is a product manager at Google who helped with A2A and with MCP adoption inside Google, and he sits on the technical steering committee of the Agentic AI Foundation. He also worked in payments at Google for six years, which is where AP2 comes from.

His take on the name: it's poorly named. The host summed up the idea as "I as a human put my thumbprint on my phone to say, yes agent, go do this on my behalf." Alan's answer: "That's effectively a mandate. It's used for purchases because we were like, what's the hardest problem that we can do right now?" Then: "But that delegation of authority is valuable in a lot of other contexts."

Payments makes a good first test because money has a built-in judge. A refund or a chargeback is a dispute about whether you really meant it, so in his words "you have to force the delegation so that it's provable." He calls AP2 the strategic piece, and he's honest that it'll take a long time to spread. Its sibling, UCP, the Universal Commerce Protocol, is the tactical one: the conventions of online shopping (cart, inventory, shipping options) as small modules over MCP and A2A, usable today.

Approving every moment loses the flight

The host's own setup is one I'd have built too. Their agent has access to the 1Password API. When it wants something, say a passport number, it pings the vault and a notification lands on the phone. Tap, approve, done.

Alan's name for that: human present. You authorize this one action, right now. It works, until the task is longer than your attention span.

Then came the flight ticket. You set the agent searching, it does all the work, you step away from the computer. It comes back: "I'm ready to pay for this flight. Do you authorize it?" You thought you authorized it twenty minutes ago. You authorized it five different times, and it never actually bought it. So you authorize again, and now the price isn't available anymore, and the whole workflow starts over.

The blunt verdict on stage: take the agent out of the equation and you could write a script that does that. The agent isn't the slow part. The approval model is.

Human present, human not present

The fix Alan described is the other mode, human not present. His example: "Hey, when these sneakers go on sale, if they're in your size, one of your trusted vendors, just buy them."

That sentence holds three limits (the item, your size, a set of shops) and one trigger. You approve it once, before anything happens. The agent then buys at 3 a.m. without waking you, and the shop can still tell that you agreed to exactly this.

Same thumbprint, different moment. In human-present mode you sign the purchase. In human-not-present mode you sign the limits, and the purchase is the agent's job.

An open mandate, then a closed one

Here's how AP2 actually does it. I read the v0.2 spec, released in April, after the stream. It's short and concrete.

A mandate is a signed digital credential, an SD-JWT, the selective-disclosure flavour of a JSON Web Token. There are two kinds: a checkout mandate (what's being bought, from whom) and a payment mandate (how much, with which card or account). Each comes in two stages.

The open mandate is what you sign. The agent drafts the limits, and a Trusted Surface shows them to you, takes your biometric and signs with your key. The spec says that surface MUST be non-agentic: the model never holds your pen. The open mandate also carries the agent's public key in a cnf claim, so it's bound to that one agent. A copy in anyone else's hands is useless.

The closed mandate is what the agent makes later, alone. It finds a real cart, writes the exact transaction, and signs it with its own key, the one named in your open mandate. That signature links the closed mandate back to the open one.

The limits are a list of typed constraints. Version 0.2 defines these:

• On the checkout side: checkout.allowed_merchants and checkout.line_items, with acceptable products and quantities.
• On the payment side: payment.amount_range, payment.allowed_payees, payment.allowed_payment_instruments, payment.execution_date, and the pair for repeat jobs, payment.agent_recurrence (say monthly, at most 12 times) with payment.budget, a cap on the total.
• Plus iat and exp on the open mandate, so the whole thing expires.

Stripped down, the payment side of Alan's sneakers would look something like this:

{
  "vct": "mandate.payment.open.1",
  "cnf": { "jwk": "the agent's public key" },
  "constraints": [
    { "type": "payment.amount_range", "currency": "USD", "min": 0, "max": 20000 },
    { "type": "payment.allowed_payees", "allowed": ["one of your trusted shops"] }
  ]
}

My favourite line in the spec is the reason open mandates exist at all: "even well-behaving Agents need to have their behavior tightly constrained above what a normal authorization model would require of human users." Nobody gives a human a card that only works at three shops, under two hundred dollars, until Friday. An agent should get exactly that.

Three checkers, and none of them is you

In human-not-present mode, nobody asks you anything at checkout. Three other parties check instead.

The credential provider (your bank or wallet) gets both payment mandates, open and closed, verifies them and only then issues a payment token. The merchant checks the closed checkout mandate against its current cart and checks that your open limits are met. The merchant's payment processor checks that the mandates inside the token are bound to that exact checkout. Each signs a receipt.

A few rules in there are small and very good:

• An unknown constraint counts as a failure. If a checker doesn't understand one of your limits, it says no rather than skip it.
• After a successful receipt, the agent shrinks the open mandate's scope by what it just spent. That's how a budget holds across repeat purchases.
• The agent must not present overlapping mandates until a receipt comes back with an error. No double spend by racing two shops.
• When a limit can't be settled, the checker returns unresolved_constraint and the flow drops back to human present. You get asked, once, about the one thing that's actually new.

That last one is the flight ticket fixed. The agent doesn't come back five times. It comes back when the price moved outside what you signed.

Every approval in my fleet is human present

Then I looked at my own setup, and it's all the host's 1Password pattern.

My selling agent drives a Chrome on the Mac mini that's logged in to my resale accounts as me. It drafts every buyer reply and waits for my OK in chat before it sends. When I asked an agent to let another agent of mine send SMS from my phone, Claude Code's auto mode refused to apply the config change on its own, because it was a permission grant. It only went through once I approved it by hand. And this note will reach the site the same way. The agent that drafted it can open the pull request, but the merge is my click.

All of that is fine for now. Here's what bugs me after this talk. The logged-in browser carries my whole authority: any listing, any price, any message. My OK is a chat message that nobody downstream can check. The limits live in my head and in a prompt, not in anything signed.

It's the other half of a note I wrote yesterday, on Chi Wang's DotSpace talk. His rule was that an agent carries your request, not your authority. AP2 is how a bounded slice of authority can travel after all: as a signed object with the limits written in, checked by whoever receives it. It's also the same idea as the gateway in my note on enterprise agents, where the keys never enter the sandbox. Here your key never touches the agent; it stays on the Trusted Surface.

What I haven't done: I haven't run AP2's samples, and v0.2 only defines checkout and payment mandates. Nothing in the spec covers "reply to buyers on this one listing, never below this price, until Sunday". That's the mandate I'd actually want, and nobody gives a format for it yet.

Try it

The AP2 part of the stream is two minutes, starting at 5:19:25. Watch it, then read the agent authorization page of the spec. It's the clearest write-up I've seen of why agents need tighter limits than people.

If you want more:

• The AP2 moment on the stream, Live from AGNTCon + MCPCon North America, day two, October 23, 2026
• Agent Payments Protocol, the site, with the agent authorization and flows pages
• google-agentic-commerce/AP2, the spec and samples, Apache 2.0, v0.2.0 since April 2026
• An agent can carry your request, not your authority, Chi Wang's rooms where agents of different owners work together
• Hope isn't security, where the keys never enter the sandbox

If you've signed an open mandate for something that isn't a purchase, tell me what the limits looked like. I'd love to see one for messages.

Plain text: sign-the-limits-not-the-purchase.md · Atom feed · All notes