What do Amazon's Agent Terms require?
Amazon's definition is wide. An Agent, for the purposes of these terms, is "any software or service that takes autonomous or semi-autonomous action on behalf of, or at the instruction of, any person or entity". That covers a shopping assistant, a price scraper and a browser extension that clicks Buy Now, and it does not turn on whether a model is involved (Amazon Conditions of Use, retrieved 22 September 2026; the terms page is also tracked by ConductAtlas).
Three obligations follow. Transparency and consent: no Agent may access Amazon Services unless it identifies itself at all times, and none may continue once Amazon has asked it to stop. Limitation on access: Amazon may limit, at its sole discretion and including by technical measures, whether and how any Agent accesses, uses and interacts with Amazon Services. Then the technical requirements, which are the operative part and read as four rules:
- Identify the request. Every HTTP or HTTPS request must say it comes from an Agent and name it, by putting
Agent/[agent name]into the user agent string. Amazon's own worked example isAgent/AmazonAgent. - Do not hide. An Agent must not conceal or obfuscate that its activity is automated, which the terms spell out as not mimicking the speed or pattern of human keystrokes or page navigation, and not completing or circumventing CAPTCHAs.
- Answer honestly. An Agent must "respond truthfully to any question or prompt seeking to determine if interactions are coming from a human or a computer".
- Do not route around a block. An Agent must not circumvent or avoid any measure intended to block, limit, modify or control agent access.
The fourth rule carries most of the enforcement weight. Detecting an agent that lies about being an agent is technically hard, and a rule against routing around a block does not require detecting anything. Once Amazon has blocked an agent, evading the block is itself a breach of the contract the shopper agreed to.
Which agents does Amazon block today?
Most of the well-known ones, by name, in a file anyone can read. Amazon's robots.txt names several hundred crawler and assistant user agents and gives them a blanket Disallow: /, among them ChatGPT-User and GPTBot, ClaudeBot, Claude-User and Claude-SearchBot, PerplexityBot, Copilot, Bytespider, DeepSeekBot and Google-Extended. Separately, any bot that respects the file is kept out of the transactional endpoints regardless of name: /gp/cart, /gp/sign-in, /ap/signin and /wishlist/ are all disallowed (Amazon's robots.txt, retrieved 22 September 2026, and Cybernews, which reports that ChatGPT and Claude both say they cannot check Amazon prices directly).
Two things are worth reading off that list. The blocking is not reactive, since a name in robots.txt is a standing position rather than a response to an incident. And robots.txt is advisory, which is why the fourth technical requirement exists: it turns ignoring the file into a breach of terms rather than a matter of etiquette. Amazon's own shopping assistant, now consolidated under Alexa for Shopping, is not on the list.
Why did Amazon block Meta's Muse?
Muse launched in the United States on 8 September 2026. Amazon began blocking it from Amazon.com on the night of Sunday 20 September, twelve days later, and GeekWire reported it that night. Users who asked Muse to buy something got a message citing the Conditions of Use: "Continued access by an unauthorized AI agent violates Amazon's Conditions of Use, to which our customers have agreed" (GeekWire, SiliconANGLE).
Amazon gave three reasons, none of which concerns what Muse was buying. Meta did not tell Amazon that Muse would be operating in its store, and Amazon says it asked Meta to remove Amazon from the Muse experience before blocking. The agent does not identify itself when it browses, which is the first technical requirement failing on its own. And it appears to capture and store customer credentials. Put together, Amazon's position is that an undisclosed third party was moving through customer accounts, processing transactions and handling sensitive data without its knowledge or consent. Its statement, given to GeekWire, was that "third-party applications that offer to make purchases on behalf of customers from other businesses should operate openly and respect service provider decisions about whether or not to participate" (Cybernews carries the same statement and the removal request).
Meta did not respond publicly to the block. What it had already said speaks to the credentials objection rather than the first one: it is expanding Muse's data protection guardrails, and a Muse Confidential VM it is testing with a limited number of users, due later in 2026, would stop Meta itself seeing consumer data inside a Muse session. That constrains what Meta can see, which is not the disclosure Amazon asked for.
The two companies remain commercial partners elsewhere. Amazon products have been buyable inside Facebook and Instagram since 2023, and the dispute is a narrow one about the terms.
Did a court rule that Amazon cannot block agents?
It ruled something narrower. Amazon sued Perplexity in the Northern District of California over its Comet assistant and won a preliminary injunction. On 4 August 2026 the Ninth Circuit vacated it and remanded the case. Writing for the panel, Judge Milan D. Smith Jr. held that on the record before the court it was the user, not Perplexity, who accessed Amazon's computers, because the user directs the agent through their own browser and Perplexity's servers never talk to Amazon's. Amazon was therefore unlikely to succeed on the merits of its Computer Fraud and Abuse Act claim, or on the California analogue (Amazon.com Services, LLC v. Perplexity AI, Inc., No. 26-1444, Jones Day).
A footnote to the opinion says the outcome "does not impair Amazon's ability to regulate access to Amazon.com via private terms of service for its users", and that Amazon "is simply unlikely to succeed in its attempt to regulate access by invoking the CFAA and the CDAFA". The sequence of the year is suggestive, though Amazon has not tied the two together: the statutory route closed on 4 August, and the Conditions of Use were updated ten days later.
So a retailer's leverage over an agent is contractual and technical rather than statutory. A contract binds the shopper who agreed to it rather than the vendor who built the agent, which is a narrower reach, but enforcing it needs no court.
What should you do if you are building an agent?
Put Agent/[agent name] in the user agent string, today, on every request. It is free, it is the precise thing being asked for, and it is close to what the rest of the field is converging on: signed identification under Web Bot Auth, now an adopted IETF working-group draft; the same signatures plus scheme-registered agent keys under Visa's Trusted Agent Protocol, which is built on Web Bot Auth rather than competing with it; and, more loosely, a recommended User-Agent string naming the client under the Agentic Commerce Protocol's checkout specification (how merchants detect AI agents). An agent that declines to say what it is buys a few days and fails all of those schemes at once.
Credentials are the harder half, and they are where the Muse objection bit. An agent driving a logged-in session looks like the account holder in almost everything the server can see, which is why a retailer treats it as an unaudited third party inside its own customer's account. Better headers do not help there. What helps is the agent not holding the session at all, and carrying instead a scoped credential the merchant and the network can check, with a ceiling and an expiry attached to it (where a spending limit can actually live).
Those two jobs cost very different amounts. Identifying an agent is a header, and every published scheme now asks for one, though only some of them require it. Proving that a particular shopper approved a particular purchase takes an architecture most agents do not yet have, and until they do, a block remains the cheapest answer available to a retailer.