“I’d separate what the user authorised from what the code enforces, because the model can be wrong or fooled about both. An agent purchase has three layers: checkout with the merchant, proof the user approved the spend, and moving the money. Protocols such as ACP, UCP and AP2 standardise those messages, but the controls are still mine to build.
For overspending: the user’s intent becomes signed rules, such as office supplies, under $300 an order, four vendors. Code checks every cart against them, using the merchant’s total in minor units, never a number the model typed. Payment goes through a scoped token, capped, expiring and tied to one seller, never the raw card. Each checkout session keeps one idempotency key, so a retry after a timeout can’t buy twice. Above the cap, the user approves the exact cart and total.
For being tricked: page text never changes the cart; only the user’s mandate does. Once the agent has read a merchant page, the session is tainted, so a cart line that isn’t in the intent, a new vendor or a changed shipping address is held for the user, decided by code that reads the arguments, not the page.
And every step writes an append-only record: intent, cart, verdict, approval, token cap, result. When someone says ‘I didn’t buy this,’ I can show what they signed.”