On the night of Sunday 20 September a shopper who had told Meta's new assistant to buy something on Amazon did not get a confirmation. They got a popup. Amazon's wording left no room to wonder what it meant: continued access by an unauthorized AI agent violates Amazon's Conditions of Use, to which our customers have agreed.
The assistant was Muse, launched in the United States earlier this month. It had been downloaded more than 730,000 times in five days and sat at the top of the App Store free chart by 19 September. Amazon had asked Meta to keep Amazon.com out of it. Meta declined. So Amazon shut the door.
- A large retailer treated a mainstream consumer assistant as an intruder rather than a customer, and the grounds it gave were about identification, not about robots.
- The dividing line Amazon drew is one any shop can draw: an agent that says who it is gets a decision, an agent that hides gets refused.
- Three published schemes now let a merchant recognise an agent at the door, and all three rest on the same signature standard rather than on guesswork.
- The payment industry has written the merchant's right to refuse into its own specification, in plain words, alongside the right to serve agents a different page.
- Nothing here obliges a small shop to build anything this month. It obliges you to know which of your traffic is software before someone else decides for you.
- Blocking every agent is a position with a cost, because the same door refuses the assistant your customer is using to find you.
It is tempting to file this under giants fighting giants, a quarrel about one AI shopping agent that has nothing to do with anyone else. Both companies are large, both have lawyers, and the thing they are arguing about sounds distant from a shop that ships forty orders a week. That reading misses what Amazon actually said. Its objection was not that software was buying things. Its objection was that it could not tell what the software was, and that is a problem every online shop already has.
Why did Amazon say no?
Because the agent would not identify itself, and because Amazon believed it was holding customer credentials. Those two complaints sit underneath everything else in the dispute.
The reasons Amazon gave, reported by GeekWire in its account of the standoff over agentic shopping, came in a short list. Meta had not asked permission for Muse to reach the store. The agent did not announce itself while browsing. And Amazon said it appeared to capture and store customer credentials, which it treated as a privacy and security risk rather than a technical curiosity.
The identification point is the concrete one. SiliconANGLE's report on the block notes that Amazon's terms already require an agent to embed text in its HTTP requests saying what it is. Muse did not. It also reported that the agent could be prompted to read a customer's account pages and order history, which Amazon described as an undisclosed third party moving through customer accounts.
Meta's answer, given before the block, was that Muse cannot see passwords or payment methods and that anything shared goes into secure storage. It has built isolation around the product, including a per instance virtual machine and a review step that inspects sensitive actions such as purchases. Both things can be true at once. The agent can be well engineered and still be unrecognisable to the shop it is standing in, and it was the second fact that got it blocked.
Worth noting what did not happen. Meta's share price rose more than 11 percent after the news, which suggests the market read the block as a fight about control rather than a wound to the product. Amazon's earlier attempt to use the courts against Perplexity's Comet browser was dismissed on appeal in August. Blocking at the door worked where litigation had not.
May a merchant refuse an AI agent?
Yes, and the specification written by the card networks says so directly. The right to refuse is not a grey area that a merchant has to argue for after the fact.
Visa's published specification for its Trusted Agent Protocol sets out what a merchant may do once it can recognise an agent, and the list is generous to the merchant. You may accept or block agent interactions entirely. You may serve an agent a different experience, such as simplified HTML with fewer checkout pages. You may confine an agent to browsing and keep it away from payment, or the reverse. You may ask for more information about the shopper using a 402 response. And you may decide that data arriving with a failed verification is unusable.
That last provision is the interesting one for a small shop. It means the protocol anticipates verification failing and hands the merchant the decision about what to do next, rather than defaulting to trust. A shop that cannot verify is not obliged to proceed.
Amazon's position was not that agents are unwelcome. Its statement said third party applications buying on a customer's behalf should operate openly and respect a service provider's decision about whether to take part. The complaint was about openness, and about who gets to choose.
How do you tell an agent from a shopper?
By checking for a cryptographic signature on the request, because nothing else survives contact with a determined agent. A user agent string is a claim anyone can type, and behavioural guessing produces false accusations against real customers.
The mechanism the industry settled on is HTTP Message Signatures, defined in RFC 9421. An agent signs its request with a private key and names the key it used. The merchant fetches the matching public key from a directory the agent's operator publishes, then checks the signature. Identity becomes something verified rather than inferred, which is the whole point.
Cloudflare's engineering write up on recognising agent traffic cryptographically puts the idea plainly: signatures let bots authenticate themselves and let the sites they visit identify them. It also describes the practical payoff, which is that a site operator can act on signed agents as a category in its security rules instead of chasing individual requests. That is the difference between a policy and a game of whack a mole.
The comparison above is the practical shape of it. Against an unsigned agent you are guessing, and every rule you write is a rule that will occasionally catch a human. Against a signed agent you have a key to check and a named operator to hold responsible, so refusing becomes a decision rather than a gamble.
What the three schemes actually cover
Three separate efforts now touch this problem and they are easy to confuse, partly because their names all contain the word agent. They are not competitors so much as layers. One identifies the software, one structures the purchase, one sits in the payment path.
| Scheme | Who maintains it | What it establishes | What a merchant does with it |
|---|---|---|---|
| Web Bot Auth signatures | IETF draft work, deployed by Cloudflare | That a request came from a named piece of software | Sorts agent traffic from human traffic before any commercial decision |
| Agentic Commerce Protocol | Stripe, OpenAI and Meta | How a cart, a checkout and an order are exchanged with an agent | Lets an agent buy through a defined interface instead of a browser |
| Trusted Agent Protocol | Visa | Agent identity, shopper identity and the payment container | Verifies at the payment step and sets what may be refused |
| Platform conditions of use | The individual retailer | Whether an agent is permitted on that estate at all | Provides the grounds to block, as Amazon used this week |
The reason to keep them apart is that they fail differently. A signature tells you nothing about whether the shopper authorised the purchase. A well formed order through Stripe's documentation for the Agentic Commerce Protocol, an open standard it maintains with OpenAI and Meta, tells you the purchase was structured properly but not that the agent behind it is one you want to serve. Layer confusion is how a shop ends up believing it is protected by something that was never about protection.
The checks a verifying merchant runs
Visa's specification is unusually specific about the steps, which makes it a useful reference even for a shop that will never implement it directly. The sequence guards against two different attacks: an expired credential, and a captured one being replayed.
The eight minute window appears twice, and that repetition is deliberate. A signature whose validity period runs longer than eight minutes is rejected, and a nonce already seen inside that window is rejected too. Signing uses Ed25519 or PS256, and the public keys live at a well known address published by the payment scheme. None of this is exotic. It is the same shape as the checks that already sit behind card payments, moved one step earlier in the journey.
Should a one person shop block agents?
Probably not by default, and certainly not without knowing how much of your traffic they already are. A blanket block is a decision about revenue disguised as a decision about security, and it costs more now that browser agent checkout lets an assistant place the order outright.
Consider what an agent at your checkout represents. Someone asked an assistant to find a product and it found yours. Refusing that is refusing a referral you did not pay for. The argument for blocking is strongest where the agent is scraping prices for a competitor, and weakest where it is completing a purchase a named customer asked for. Those are different visitors and the whole value of a signature is that it lets you tell them apart, which is the same reasoning that applies when deciding which AI crawlers to allow on your shop.
There is a second reason to go carefully. Your payment processor may already be doing this work. Merchants on processors that support the card network schemes will find agent verification handled upstream, arriving as a flag on the transaction rather than as a project. Building your own check before you have looked at what your provider offers is how a small team spends a fortnight on something that was included.
What this changes for a small shop this month
Less than the headlines imply, and more than nothing. The honest answer is that this is a week to look at your logs, not a week to rebuild your checkout.
Start by finding out whether agent traffic is reaching you at all. Most shops have never looked, and the answer is usually either near zero or surprisingly not, and either result is worth knowing before you form a policy. If your host or CDN publishes a bot report, that report is now a commercial document rather than a technical one.
Then decide what you want to happen when an agent buys. This is where the question stops being abstract, because an agent order is still an order: it ships, it can be refunded, and it can be disputed. The mechanics of that transaction are covered in more depth in our explainer on how an agent completes a purchase at your checkout, and the question of who is bound by what the software agreed to is the subject of a separate piece on who carries the liability when an agent places an order. Neither of those changed this week. What changed is that refusing became a visible, exercised option.
The third thing is the one most shops skip. Check that your product data is good enough to be bought from. An agent reads a feed, not a photograph, and a listing with a missing size or an ambiguous unit is a listing an agent will pass over in favour of a clearer one. Shops running on a platform where you control the catalogue and the checkout code have an advantage here, which is part of the case for building an online store whose checkout and product feed you own outright rather than renting the decision from someone else.
Why the block worked where a lawsuit did not
Amazon has been here before. It went after Perplexity over the shopping agent in that company's Comet browser, and an appeals court dismissed the case in August. A month later it achieved the outcome it wanted against a far larger opponent in a single evening, without filing anything.
That contrast is the practical lesson buried in this story. Terms of service are enforced at the door or not at all. A merchant who writes an agent policy into a page nobody reads has written a wish. A merchant whose systems can detect and refuse an unidentified agent has written a rule. The gap between the two is the whole subject, and it is a gap that closes with configuration rather than with drafting.
What an agent needs from your catalogue
The merchant side of agentic commerce is smaller than the vocabulary suggests, and it is worth seeing the list before deciding it is a project. The protocol's building blocks are a checkout an agent can create and complete, a cart and a product feed it can read, a way to pass a payment token, delegated authorisation over OAuth 2.0, and webhooks that report confirmation, shipping, delivery and refunds.
Read that as a shop owner and most of it is already built. You have a checkout. You have a catalogue. You almost certainly emit order webhooks to something. What is usually missing is the feed in a shape a machine can read without ambiguity, and that gap is not really an agent problem. It is the same gap that makes your listings rank poorly and your marketplace exports fail. Work done there pays off whether or not a single agent ever arrives.
This is why the advice to prepare for agentic commerce so often sounds like advice you have heard before. The preparation is accurate product data, a checkout that does not depend on a human eye to interpret it, and honest stock numbers. An agent is simply a customer with no tolerance for a page that requires interpretation.
The part that will not age
Muse will be joined by others, Amazon's position may soften, and the specific popup a shopper saw on 20 September will be a footnote by spring. What survives is the principle both sides were arguing about, which is that a shop is entitled to know who is at the door before deciding whether to open it.
That principle has been quietly settled in the merchant's favour across every document referenced here. The card network specification gives you the right to refuse. The signature standard gives you the means to refuse accurately. The retailer's own terms gave it the grounds. A small shop inherits all three without having to win an argument, which is rare enough to be worth noticing.
What a merchant still owes itself is the decision. Agents are not a category you can defer thinking about until the traffic justifies it, because by the time the traffic justifies it the defaults will have been set by your platform, your processor and your CDN. Those defaults may be fine. They are still somebody else's choice about your customers, and this week showed what it looks like when a company declines to let that stand.