Show the buyer the deal before the agent agrees to it

The screen says: booked, $340. Underneath that number is a seat fee, a fare that cannot be changed, and a subscription that renews in thirty days.

None of it was hidden. The agent read all of it. It read the renewal terms, the cancellation window and the restocking fee, and then it did what it was built to do, which is compress several pages of text into one line a person will actually read. The compression is the problem. An agent that reports everything it read is just a slower browser, so every useful agent throws something away — and what it throws away is chosen by a model, not by the rules about what a buyer has to be told.

There is a sharper version, which is the shopping form of the attack in C4. Hidden text on a page tells the agent to add something the buyer never asked for. If the confirmation shows a total rather than a full basket, nobody notices until a statement arrives. As in C1, I have not found a documented case of exactly that, so treat it as the predictable shape of the attack rather than something already recorded.

Both versions end in the same place. The buyer approved a number. They did not approve the thing the number was for.

The other controls ask what the agent was allowed to do. This one asks a stranger question: when the agent is the only thing that read the page, which of the two of you was told?

There is a great deal of law about what has to be on the screen. Under the EU Consumer Rights Directive, a trader must make the consumer aware of the main characteristics, the total price and the relevant duration directly before the order is placed, and the ordering button itself has to be labelled unambiguously enough that the consumer acknowledges an obligation to pay. The Court of Justice read that strictly in Fuhrmann-2 (C-249/21): what the button says is what counts. In the United Kingdom, the total price including every mandatory fee has to be given up front in an invitation to purchase, which has applied since 6 April 2025.

Ontario has the most useful wording of the three for this argument, and it has been sitting in a statute since 2002. Section 38 of the Consumer Protection Act, 2002 requires a supplier to give the consumer an express opportunity to accept or decline an internet agreement, and to correct errors, immediately before entering into it. It also requires the disclosure to be made in a way that ensures the consumer has accessed the information and is able to retain and print it. Not made available to them. Accessed. The Consumer Protection Act, 2023 will replace it, is not yet in force, and keeps the same idea.

Now put an agent in the middle of that requirement. The page renders, the shopping agent accesses the full disclosure, a model compresses it, and a human reads the compression. Has the consumer accessed the information? Ontario law does not appear to answer that, and I am not going to pretend it does. What is striking is that a provision from 2002, written for a web nobody expected software to shop on, frames the question this precisely.

That is the pattern across all three. Each describes something a person is supposed to see, and something a person is supposed to do about it, and none of them contemplates that the seeing and the doing might be carried out by software the buyer switched on that morning. So the question is who the law thinks is doing the seeing.

Agency law offers a route towards an answer, and it is worth being exact about how far that route actually goes, because this is easy to overclaim.

What is established is that agency law can impute to a principal knowledge an agent acquired within the scope of the agency, subject to limits and exceptions. What is not established is that an AI shopping agent is an agent in that sense for every purpose, which is the same open question C1 flags. And less established again is that a statutory disclosure duty, written to inform a natural person, is discharged because software acting for that person ingested the text.

Stack those three up and you have a collision between doctrines rather than a doctrine that already decides the result. I found nothing settling it in either direction, and the honest description is an open problem rather than a loophole the courts have blessed. What I will say is that a system designed on the assumption that showing it to the agent counts as showing it to the buyer is resting its weight on the least established of the three, and that is a decision somebody should make deliberately rather than by default.

Decide in advance which purchases a person has to see before they happen, and write that rule down alongside the mandate from C1. Not every purchase: an agent you have to supervise line by line is a browser with extra steps. The useful triggers are the same three as in C4 — spending above a threshold, anything that cannot be undone, and anything outside the pattern of what this buyer normally does.

When you do show something, show the commitment rather than a description of it. At a minimum that means the total with everything mandatory included, every line item rather than a subtotal, whether it renews, whether it can be cancelled and by when, and who the seller actually is.

Mark what the buyer did not ask for. If you build only one field, build this one: which items came from the buyer's instruction, and which the agent chose on their behalf. Substitutions and additions are exactly where an unauthorised purchase lives, and they are invisible in a total.

Do not let the model write the confirmation. If the agent generates the text the buyer approves, then an injected instruction can generate that text too, and the screen becomes part of the attack surface rather than a check on it. Render it from the transaction data, deterministically, the same way every time.

Make the approval specific and reproducible. Yes to a screen you can rebuild later is evidence; a thumbs-up in a chat log is an anecdote. And record the order of events, because permission asked for before the money moves is consent, and the same words after it has moved are a notification.

For every purchase over the threshold: exactly what was rendered, when it was rendered, what the buyer did, how long they had to do it, and which stored record it was rendered from.

A screenshot is not the answer here, because a screenshot proves what somebody kept rather than what the buyer saw. What you want is to be able to regenerate the screen from the data months later and show that it matches what was actually bought.

The question this is built for is narrow and awkward: can you put the screen in front of someone who thinks you invented it afterwards? If the honest answer is that you would have to reconstruct it from memory, the control is not there.

A great deal, and that is the surprise. Disclosure before purchase is the most heavily regulated part of consumer commerce. None of it was drafted with an agent in the middle.

The three obligations above are real and in force. What none of them settles is who has to be looking when the disclosure is made, because until recently the question could not sensibly be asked.

The closest thing to an answer came on 9 March 2026, when the UK's Competition and Markets Authority published Using AI agents: complying with consumer law — one of the first guidance documents from a major consumer authority aimed squarely at agentic AI. Its central position is that consumer law applies in the same way whether a consumer is dealing with a person or an AI agent, and that a business is responsible for the agents it deploys just as it is for its human ones. That is agency law being applied by a regulator, in as many words.

The limit matters, and it is easy to state too strongly. That compliance guidance is directed principally at businesses deploying agents towards their customers — handling queries, processing refunds, recommending products — rather than at the legal effect of a consumer's own shopping agent receiving a disclosure. The CMA's accompanying research does look at consumer-side agents and where they are heading, so this is not a regulator that has overlooked them. It is that the specific question this control turns on has not been given a compliance answer. The EU's Digital Fairness Act is the obvious place for one, and as of September 2026 the Commission has it under preparation rather than tabled.

One partial safety valve is worth knowing about, along with the size of the hole in it. Distance selling in the EU carries a right of withdrawal for a period after purchase, which takes some of the sting out of a wrong purchase. It has exceptions, and several cover accommodation, car rental, catering and leisure services tied to a specific date or period.

The flight in C1 is a harder case than that, and for a less obvious reason. Passenger transport is largely carved out of the Consumer Rights Directive altogether under Article 3(3)(k), rather than sitting inside the withdrawal regime as an exception to it, and the Commission has said the withdrawal right does not apply to air passenger services. The intuition survives — a mistaken agentic purchase of a flight has no generic cooling-off period to fall back on — but the mechanism is exclusion from the directive rather than an exception within it. Worth knowing which, because the two behave differently across other categories.

Nothing I am aware of requires a confirmation screen sized to the risk of the purchase. That makes this the cheapest control in the set to build and the easiest one to skip, which is usually how you can tell which controls are going to matter.