When an agent buys something, what did we actually authorise?
A six-control framework for recording delegated authority, checking the final purchase, preserving evidence, and making stop mean stop. The aim is to make every consequential decision inspectable before money moves and explainable after it does.
- 6
- published controls
- 7
- purchase stages
- 22 Sep 2026
- source review
Permission is a state, not a moment.
Authorisation is not a one-time approval. It is a live state that has to be captured, checked, evidenced, exhausted, expired, and revoked.
The problem
A payment can fit a spending limit while the product, seller, timing, or commitment still falls outside what the person meant.
The lens
Treat a shopping instruction as delegated authority with a lifecycle: creation, use, amendment, exhaustion, expiry, and revocation.
The standard
Put deterministic checks outside the model and leave enough evidence for a sceptical third party to reconstruct the decision.
A budget check catches only one kind of wrong purchase.
This example keeps the mandate fixed and changes the cart. It is an interactive illustration of the research framework, not evidence from a live payment system.
Interactive control test
Would this purchase still be authorised?
Keep the buyer's permission fixed. Change the proposed purchase and see why a budget check on its own is not enough.
Recorded permission
Buy one cabin suitcase
- Scope
- Hard-shell · cabin size · one item
- Total cap
- CA$250, including tax and delivery
- Sellers
- Maple Travel or Northstar Luggage
- Changes
- Ask before changing material or size
- Duration
- One purchase · expires at 6:00 p.m.
This is a human-readable example of a mandate. A real system would encode the same conditions in a signed, machine-checkable record.
The cart matches the recorded permission
The item, final total, seller, and timing all fit the mandate the buyer confirmed.
- Item
- Alpine 55 · hard-shell cabin suitcase
- Final total
- CA$238 · tax and delivery included
- Seller of record
- Maple Travel
- Commit time
- 5:12 p.m. · mandate is live
One hard-shell cabin suitcase
CA$238 is within the CA$250 all-in cap
Maple Travel is on the approved seller list
No material, size, or product change
One-use mandate is live and unused
Allow the payment
Every recorded condition matches. The payment can proceed with a scoped credential.
What stays constant
One buyer mandate, including product, total cost, seller, substitution, and timing.
What changes
The final cart, seller of record, product substitution, or live permission state.
Research outcome
The same budget can still require allow, ask, or block decisions when another condition changes.
The agent can propose. It cannot grade its own work.
The enforcement boundary sits between the agent and the payment credential. The policy engine compares the final cart with live authority using deterministic rules the model cannot rewrite.
- 1
Buyer
Confirms the mandate on a trusted surface.
- 2
Mandate service
Stores scope, limits, expiry, use, and revocation state.
- 3
Shopping agent
Explores the web and submits a proposed final cart.
Reads untrusted input - 4
Policy engine
Checks the cart against current authority and fails closed.
Control boundary - 5
Payment + merchant
Receives the narrow credential and returns the receipt.
Untrusted input
Pages, reviews, product text, and other agents.
Live control inputs
Mandate, running total, seller identity, and revocation.
Evidence out
Policy decision, credential scope, buyer action, and receipt.
Different standards solve different layers.
ACP coordinates checkout. AP2 records delegated authority. Visa, Mastercard, and Stripe are building agent identity and scoped payment controls. EMVCo is now exploring shared intent state across the transaction lifecycle. Together they provide useful building blocks; none alone proves that an ambiguous human goal was interpreted correctly.
ACP
Coordinate checkout
Lets an agent and merchant exchange product, checkout, order, and credential information through a common flow.
AP2 · EMVCo draft
Represent authority
Encodes signed mandates and explores how authorised intent persists, changes, expires, and is referenced over time.
Stripe · Visa · Mastercard
Constrain payment
Binds credentials or network checks to an agent, seller, amount, currency, expiry, or transaction context.
Where the controls sit
A purchase passes through seven moments. Select a stage to see what can go wrong and which control covers it. Revocation cuts across the entire journey.
Step 2 of 7
Permission is recorded
What the agent may buy, from whom, for how long, and what to do when the exact thing is unavailable.
What can go wrong: Skip this and there is nothing for a later purchase to be checked against, and nothing to show a dispute eleven months from now.
A purchase needs to be checked against the permission behind it. Protocols such as AP2 already provide mandate mechanisms; the practical question is whether an implementation captures the relevant conditions and enforces them throughout the task.
Read the full control →Six controls, with an owner and proof.
Each control begins with a failure, places enforcement at a specific point, and names the evidence that should remain. Open any control for the full legal, technical, and product reasoning.
Test the awkward cases before customers do.
These are design-time acceptance tests for a future implementation, not empirical results. A production test pack should add currency changes, partial fulfilment, downstream agent delegation, disputes, and refunds.
Taxes and delivery push the final total over the cap
Invokes C1 · C2
A refundable request becomes a cheaper non-refundable fare
Invokes C1 · C5
The storefront and seller of record are different parties
Invokes C3
The same credential is replayed for a duplicate purchase
Invokes C2 · C3
A hidden page instruction changes the cart after approval
Invokes C2 · C4
The buyer revokes while a payment request is in flight
Invokes C6
What I would require for a first release
Make permission explicit
Capture scope, total cost, seller, substitution rules, duration, and purchase count in a record the buyer confirms.
Keep enforcement outside the model
Submit the final cart to a deterministic policy engine that reads the live mandate and cumulative spend.
Issue the narrowest credential
Bind payment capability to the approved seller, amount, currency, expiry, and one specific use wherever the rail allows it.
Prove and rehearse stop
Keep tamper-evident decision records, propagate revocation, and measure the time from stop request to final permitted action.
No-go conditions
Do not spend when the mandate is missing or ambiguous, the live state cannot be reached, the final cart falls outside a recorded condition, the seller or payment destination cannot be verified, or revocation status is unknown.
What this framework is built on
I reviewed primary protocol and payment-network materials, then compared what each layer can establish. A signed instruction gives tamper-evident evidence of encoded authorisation; it does not prove that the person's underlying intent was understood.
Agent Payments Protocol v0.2 specification
Signed checkout and payment mandates, autonomous payments, deterministic validation, and receipts.
Open primary source ↗Agentic Commerce Protocol
Programmatic checkout and secure credential relay between buyers, agents, and merchants.
Open primary source ↗Shared Payment Tokens
Seller-specific credentials with amount, currency, expiry, lifecycle status, and revocation controls.
Open primary source ↗Visa Intelligent Commerce
Agent-specific tokens, authenticated payment instructions, and network checks for merchant and amount.
Open primary source ↗Agent Pay
Registered agents, agentic tokens, consumer-set authority, transaction visibility, and dispute support.
Open primary source ↗Draft Agentic Payments Framework
A proposed shared intent state for recurring purchases, cumulative budgets, amendments, and post-transaction activity.
Open primary source ↗Scope
Consumer purchases made by an AI system acting on a person's instruction.
What remains open
Semantic intent, downstream delegation, liability, dispute policy, and recourse.
Research cutoff
Landscape sources reviewed 22 September 2026; detailed controls show their own check dates.
Written in a personal capacity from public sources. This is a proposed product and control framework, not legal advice, a compliance determination, or a judgement about any company. Protocols and deployments are evolving; the status labels above are accurate to the research cutoff shown.