Amazon blocks Meta's Muse: a shopping agent holding a customer's password is still a third party

Ninety-nine names on the door, and none of them is Muse

Fetch amazon.com/robots.txt today and count the named crawlers. We did, on 21 September 2026: the file names 99 distinct user agents and gives every one of them the same instruction, Disallow: /. The list at amazon.co.uk/robots.txt is identical, name for name. It includes three of Meta's documented user agents (meta-externalagent, meta-externalfetcher and meta-webindexer), Google's GoogleAgent-Shopping and GoogleAgent-Mariner, OpenAI's ChatGPT-User and Perplexity's Perplexity-User.

It does not include Muse, the personal AI agent Meta launched in the US on 8 September. It could not: Meta has not published a user agent string for Muse, and its launch post says nothing about how Muse identifies itself to the sites it visits. On the evening of Sunday 20 September, 12 days after launch, Muse users trying to shop on Amazon.com were shown a pop-up instead of a checkout, according to GeekWire's report as carried by Engadget and others:

"Continued access by an unauthorized AI agent violates Amazon's Conditions of Use, to which our customers have agreed."

So the first thing the robots file establishes is also what it does not establish. A list of names can only turn away visitors that announce a name. It tells you nothing about how Amazon recognised Muse, whether it was by user agent, network origin, behaviour or account signals, and Amazon has not said. Nor does it tell you whether Muse ever read robots.txt at all. What it does show is the shape of the problem this briefing is about: retailers have a mature toolkit for bots that say who they are, and almost nothing settled for an agent that arrives logged in as a real customer, with that customer's password, and does not say it is an agent.

For UK security and e-commerce teams the question is not whether Amazon or Meta is right. It is the one Amazon has now answered for itself in its terms: when a customer delegates shopping to software, is that traffic the customer, or a third party? Your fraud controls, your contract and your bot policy each give an answer, and they may not agree.

What Amazon did, and on what stated grounds

We could not reach GeekWire's original report directly (the site returned a block page to our requests), so the account below rests on Engadget's report and on republications of GeekWire's text, cross-checked against each other. Amazon has not, as far as we could find, published a statement of its own on its news site. The reported spokesperson line is that third-party applications buying on behalf of customers "should operate openly and respect service provider decisions about whether or not to participate." Engadget reports the spokesperson compared the arrangement it wants to food delivery apps and the restaurants they take orders for.

According to the reports, Amazon's complaint has three parts: Meta did not tell Amazon that Muse would access its store; Muse does not identify itself when it browses; and it appears to capture and store customer login credentials, which Amazon says creates privacy and security risks. Amazon also says it first asked Meta to exclude Amazon from Muse voluntarily, and acted only when that failed.

What is on the record about Amazon's block, and what is not. Sources: Engadget and republished GeekWire reporting, 20 to 21 September 2026; Amazon Conditions of Use; Meta's Muse launch post.

Question	Stated on the record	Not stated
What users saw	A pop-up citing Amazon's Conditions of Use, reported from Sunday night, 20 September	Whether any orders were cancelled or accounts flagged
Grounds	No notice to Amazon; no self-identification; appears to capture and store credentials	The evidence behind "appears to"
Before the block	Amazon asked Meta to exclude Amazon voluntarily	When, how, or what Meta replied
Technical method	Amazon's terms reserve the right to limit agents "by technical measures"	Whether it keyed on user agent, IP ranges, fingerprinting or account signals
Legal action	None reported	Whether a cease and desist letter was sent, as it was to Perplexity
Where it applies	Amazon.com	Amazon.co.uk; Muse is US only
Meta's reply to the block	None found at the time of writing	Whether Meta will add an agent identifier or exclude Amazon

The contractual lever is new and specific. Amazon's US Conditions of Use, marked last updated 14 August 2026, contain an Agents section. It defines an agent as any software or service that takes autonomous or semi-autonomous action on behalf of, or at the instruction of, any person, and it says no agent may use Amazon's services unless it identifies itself at all times and meets four technical requirements:

1. Include Agent/[agent name] in the user agent string of every HTTP or HTTPS request (Amazon's example is Agent/AmazonAgent).
2. Do not conceal that the traffic is from an agent, for example by mimicking human keystroke speed or navigation, or by completing or circumventing CAPTCHAs.
3. Answer truthfully when asked whether the interaction is human or machine.
4. Do not circumvent measures Amazon uses to block, limit or control agents.

The same section adds that no agent may continue once Amazon has asked it to stop, and that Amazon may limit agents at its sole discretion. That is the clause the pop-up points at: the customer agreed to the Conditions of Use, so the customer's agent is bound by them.

What Meta says Muse is, and how it has responded

Meta's launch post of 8 September is the primary description of Muse, and it answers one of the questions this story turns on: where the agent runs. It does not run in the user's browser. Meta says Muse runs on Muse Secure VM, which it describes as a dedicated computer in the cloud that houses both the agent and the person's data. From there Muse "can open a browser, fill out forms, and negotiate" on the user's behalf. Meta does not say whose cloud hosts these machines. (Meta did sign a multibillion-dollar agreement with AWS in April 2026 for agentic AI workloads on Graviton processors, but Amazon's announcement of that deal does not mention Muse, and we have no evidence Muse runs on it.)

On credentials, the post is specific. Credentials a person shares "go into secure storage", and Meta says Muse "has no visibility into people's passwords or payment methods", including passwords a person types into the browser themselves. A separate Sentinel agent on the same machine must approve anything Muse sends to the internet. Muse asks before sensitive actions such as a purchase. For payment it can use Stripe's Link, whose agent wallet generates a one-time card number; Shop Pay and 1Password support are described as coming soon. Muse is available to US users on iOS, Android and muse.ai.

As for a response to the block, reports say Meta did not respond to requests for comment on Sunday night, and we found no Meta statement addressing it by the afternoon of 21 September. Meta's public position is therefore its launch-post claims, which answer Amazon's credential concern in part but not its identification concern.

Why it matters where the agent runs

Amazon has fought this fight before, in court, and lost the first round on a point that turns on architecture. In November 2025 it sued Perplexity over the agent in its Comet browser. Judge Maxine Chesney of the Northern District of California granted a preliminary injunction in an order dated 9 March 2026, finding Amazon likely to succeed under the US Computer Fraud and Abuse Act (CFAA) because Comet accessed customers' password-protected accounts "with the Amazon user's permission but without authorization by Amazon".

The Ninth Circuit vacated that injunction on 4 August 2026 (No. 26-1444). Its reasoning rests on how Comet works: the browser runs locally on the user's machine, the Assistant sends screenshots to Perplexity's servers and receives navigation instructions back, and Perplexity's own servers never talk to Amazon's. On those facts, the panel held, it is the user who accesses Amazon, using the Assistant as a tool. The court was careful about what it was not deciding. It did not address whether, on other facts, a provider could control an agent "in such a way as to gain entry to Amazon's servers", and it said the outcome does not impair Amazon's ability to regulate access through its terms of service. The full court declined to rehear the case on 10 September, ten days before the Muse block.

The opinion also records the detail at the heart of both disputes: Perplexity chose not to send a user agent string that would tell Amazon an agent was active, which would have let Amazon block it. The parties dispute whether Perplexity altered the string after Amazon first managed to block it.

Comet and Muse compared on the points that decide who is at the door. Sources: Ninth Circuit opinion No. 26-1444; Meta, Introducing Muse, 8 September 2026.

Question	Comet (court record)	Muse (Meta's post)
Where the agent's browser runs	On the customer's own computer	On a dedicated cloud machine built by Meta
Who sends requests to the retailer	The customer's machine	The cloud machine
Where credentials sit	In the customer's browser	In secure storage on the cloud machine
Declares itself as an agent	No; chose not to send an agent user agent	Not stated; no Muse user agent published
Legal position in the US	CFAA injunction vacated; user held to be the one accessing	Untested; the court left this pattern open

Inference, labelled as such: Muse's design sits on the side of the line the Ninth Circuit declined to rule on. When a Meta-built machine in a data centre sends the requests, holds the session and types the password, the argument that "the user accessed Amazon, with a tool" is harder to make than it was for a browser on the user's own laptop. That is why Amazon's pop-up cites contract, not the CFAA. Whether contract alone will hold, and against whom (the customer who agreed to the terms, or Meta, which did not), no court has yet decided.

Comfortable labels on both sides

Every party to this dispute uses reassuring names. None of them is a control a retailer can verify from its side of the connection.

Friendly names in the Muse dispute, and what each does and does not tell a retailer. Sources: Meta launch post; Amazon Conditions of Use; reported Amazon statement.

Label	What it tells a retailer	What it does not
"Muse Secure VM"	The agent runs in an isolated machine per user	Where requests come from, or how to tell them from an attacker's cloud host
"Sentinel" approval	A second agent gates outbound traffic	What policy it applies to a retailer's terms or robots.txt
"Secure storage" for credentials	The model cannot read the password	That the password stays with the customer; it is held by Meta's infrastructure
Link "purchase protections"	The buyer has recourse through Stripe	Anything about account takeover risk on the merchant's side
"Unauthorized AI agent"	Amazon has not authorised it	That the customer has not; the customer did

The last row matters most. "Unauthorized" in Amazon's pop-up means unauthorised by Amazon. The customer plainly did authorise Muse, which is why Amazon has to argue that the customer's authority does not extend to a third party the retailer has not approved. That is a legitimate position, and it is also a commercial one: Amazon runs its own shopping agents (the Ninth Circuit notes it launched agentic AI products in 2025), and an outside agent that goes straight to checkout bypasses the pages where Amazon sells advertising. Security reasoning and commercial interest point the same way here. Both deserve to be named, and neither cancels the other.

The security and fraud side: what the retailer actually sees

Strip away the brands and look at the login from the retailer's side. A correct username and password arrive, possibly followed by a one-time code, from a machine in a cloud provider's address space rather than the customer's home broadband or mobile network. The session then browses, fills a basket and reaches checkout at machine speed. That is also the signature of account takeover by credential stuffing. Inference: unless the agent declares itself in a way the retailer can verify, the fraud stack has no principled way to tell "the customer's agent" from "someone who has the customer's password", and it is designed to treat the second as an attack.

Four specific risks follow, whichever company you side with:

• Credential custody. Whatever the model can or cannot see, a third party now holds a reusable secret for the customer's retail account. A breach or misuse of that store is a breach of the retailer's customers, and the retailer never agreed to the arrangement. Amazon's UK Conditions of Use already make the customer responsible for keeping the password confidential and for "all activities" under the account, to the extent the law allows.
• Second factors become relayable. If the agent can complete a login that needs a one-time code, the code is being passed through the agent's infrastructure. That weakens the assumption behind step-up authentication: that the person approving is the person present.
• Payment authorisation. Meta's Link integration issues a one-time card, which protects the customer's card number. It does not tell the merchant whether the customer approved this specific basket, and on a site where the account already holds a saved card, the one-time card may not be the payment used at all. That point is not addressed in Meta's post.
• Bot detection by evasion. Amazon's terms name the two techniques that make agents invisible: mimicking human keystroke and navigation patterns, and solving CAPTCHAs. An agent that does either is indistinguishable from a sophisticated bot by design. The Ninth Circuit record shows the practical result: Amazon spent, in the district court's words, "numerous hours" building tools to block Comet and detect it again.

Does any of this apply in the UK?

Directly, not yet. Meta says Muse is rolling out in the US, and the reports describe the block on Amazon.com only. We found nothing saying whether Amazon has applied the same block on Amazon.co.uk.

But the contractual basis is already in place here. The Amazon.co.uk Conditions of Use & Sale, marked last updated 28 November 2025, contain the same Agents section, word for word on the substance: the same definition, the same four technical requirements, the same Agent/[agent name] user agent rule. The UK robots file names the same 99 agents. Those UK conditions are governed by Luxembourg law, with UK consumers keeping the protection of the mandatory law of their country of residence.

On the criminal side, UK law frames authorisation differently from the US statute the Ninth Circuit read. Under section 17(5) of the Computer Misuse Act 1990, access is unauthorised if the person is not entitled to control it and does not have consent "from any person who is so entitled". Inference, not legal advice: the customer is entitled to control access to their account in one sense, but not to Amazon's systems, which sharpens the question of whose consent counts. No UK court has considered an AI shopping agent under the Act, and we would not predict the outcome.

For UK website owners, contract law has its own limit. Under the Consumer Rights Act 2015, an unfair term in a consumer contract does not bind the consumer (section 62), and written terms must be transparent, expressed in plain and intelligible language (section 68). An agent clause buried in terms most customers never read, and enforced against the customer, is exactly the kind of term that invites that test. Take advice before you rely on one.

Identifying agents: what exists, and what is still a draft

The honest position is that there is no finished standard for an agent to prove, to a website, who operates it and that a named customer delegated a specific task to it. There are three partial tools.

User agent strings. Amazon's Agent/[name] convention and published lists such as Meta's crawler documentation are useful for honest agents and useless against dishonest ones: a string is a claim anyone can copy. Meta's own documentation says its Meta-ExternalFetcher, which fetches links at a user's request and helps "AI navigate websites to complete tasks for users", "may bypass robots.txt rules". Meta recommends allowlisting its crawlers by IP address rather than user agent where possible, which is sound advice for crawlers and no help for a customer's agent logging into a customer's account.

Web Bot Auth. The IETF chartered the Web Bot Auth working group on 23 October 2025 to standardise cryptographic authentication for automated clients. Its first milestone, a standards track authentication specification sent to the IESG by 30 April 2026, has passed without that step; the working group's protocol draft reached revision 00 as a working group document on 1 September 2026. The draft, by authors from Cloudflare and Google, has clients sign requests with HTTP Message Signatures and publish their keys at a well-known URI, identified by a Signature-Agent header. It even includes an example of an agent using a remote browser, which is Muse's pattern. But it is explicit about its limits: it "does not authenticate human users" and does not define authorization or delegation. It can tell you which operator sent a request. It cannot tell you that your customer asked for it.

Payment network schemes. Visa describes a Trusted Agent Protocol that would let merchants recognise Visa-trusted agents and carry consumer and payment signals with time-bound signatures. Visa's own page describes it as being in development and deployment. Card networks have an obvious commercial interest in being the trust layer for agent payments, which does not make the idea wrong, but it does make it a vendor proposal rather than a standard.

Tools for identifying agents, and what each does not establish. Sources: Amazon Conditions of Use; IETF datatracker and draft-ietf-webbotauth-httpsig-protocol-00; Meta crawler documentation; Visa developer page.

Tool	What it establishes	What it does not establish
User agent string	What the client claims to be	Anything; it can be copied
Published IP ranges	Traffic came from the operator's network	Which customer, or whether a cloud tenant is the operator
Web Bot Auth signature (draft)	Which operator's key signed the request	Human identity, consent, or delegation
Payment network agent schemes	Scheme-vetted agent and payment signals	A settled open standard; still in development

Governance for UK website owners: deciding which agents to serve

Most UK sites are not Amazon and cannot afford to block every agent. Customers will increasingly arrive through them, and turning them all away may simply send the sale elsewhere. The work is to make a deliberate decision per class of agent, write it down, and make your controls, terms and customer messages say the same thing.

It helps to separate three classes that robots.txt tends to blur:

• Crawlers that index or train (for example GPTBot, meta-externalagent). robots.txt is the right tool, with the caveat that it is advisory.
• User-triggered fetchers that read a page because a person asked (for example ChatGPT-User, Perplexity-User, meta-externalfetcher). Some operators say these may ignore robots.txt. Decide whether you mind being read, and rate-limit rather than block if not.
• Transacting agents that log in and buy as a customer. robots.txt is irrelevant to these: Amazon's own wildcard rules already disallow /ap/signin and /gp/cart for every crawler, yet Amazon's reported concern is that Muse could reach account pages and order history when prompted. The block came from Amazon's own controls, not from the robots file. This class needs account security and contract, not crawler etiquette.

The question that exposes the gap

Amazon's answer is now written into its Conditions of Use on both sides of the Atlantic: an agent is a third party, it must say so in every request, and the retailer decides whether to serve it. Meta's design answers the security objection with isolation and hidden credentials, but not the identification objection. The Ninth Circuit answered only for an agent that runs in the customer's own browser, and said so.

That leaves every UK site owner with the same question, and it is worth putting to your fraud team this week: when a correct password for one of your customers arrives from a cloud data centre, can you tell whether it is that customer's agent or an attacker, and does your contract say which of the two you are prepared to serve? If the answer to the first half is no, the second half is the only control you have.

Key facts