Written by Jeremy Souffir Founder, JTS Tech Services
The short version. On the night of 20 to 21 September, Amazon started blocking Muse, the personal agent Meta launched on 8 September, from shopping on Amazon.com. Users who tried saw a pop-up saying continued access by an unauthorized AI agent violates Amazon's Conditions of Use. Amazon gave two reasons: Muse does not identify itself while browsing, and it captures and stores customer credentials so it can move through customer accounts and order history. Meta says the credentials sit in secure storage the agent cannot read, and that purchases need the user's approval. The fight between two giants is not your fight. The visitor at the centre of it is: a real customer of yours, signed in with their own password, operated by software on a computer they do not own. That visitor is going to reach your store whether or not Amazon lets it into theirs, and the question it raises is not whether you are visible to AI. It is what your store should let a delegated agent do inside a customer's account.
What actually happened?
- 8 September: Meta launched Muse in the US on iOS, Android and the web. Meta's pitch is an agent that keeps working after you close the app, sends emails, books travel, fills in forms and shops, running on a dedicated secure virtual machine with its own browser.
- How it gets into your accounts, per Meta: credentials you connect are held in a separate store the model cannot read, where a service has an API it uses that, and where it does not, it uses the site through a browser "the way you would". Meta says Muse checks with the person before sensitive actions such as sending an email or making a purchase.
- 18 September: GeekWire reports Muse reached the top of the free charts on Apple's US App Store.
- 20 to 21 September: Amazon began blocking it. Amazon told GeekWire it was not told in advance, had not authorised the activity, and asked Meta to remove the bot before acting. Its stated concerns are that the agent does not identify itself, that it captures and stores customer credentials, and that it amounts to an undisclosed third party moving through customer accounts.
- This is not a one-off. Amazon has already moved against Google's and OpenAI's shopping agents and sued Perplexity over its Comet browser in 2025. Its own shopping agent that visits other brands' sites, Buy for Me, identifies itself and lets brands opt out, which is the standard Amazon is now holding everyone else to.
Whose claims these are
Amazon's reasons are Amazon's, given to reporters by a spokesperson, and Amazon is not a neutral party: it runs its own shopping assistants and one of the largest ad businesses in retail, which depends on shoppers seeing its pages. Meta's description of how Muse handles passwords is Meta describing its own product, and nobody outside Meta has audited it. Both can be partly right at once. An agent can keep a password out of the model's sight and still be an unannounced visitor inside someone else's customer accounts. That is the part worth your attention, because it does not depend on who wins this argument.
Why is Amazon doing this through its terms instead of the courts?
Because the courts just took the obvious route away. Amazon won a preliminary injunction against Perplexity in March, arguing that Comet's agent hacked its way in by using customer accounts Amazon had not authorised it to use. On 4 August the Ninth Circuit vacated it, reasoning that when a user tells an agent running through their own browser to shop, it is the user who accesses Amazon's computers, not the AI company. The anti-hacking theory stalled, so Amazon reached for the tools that remain: its Conditions of Use, which ContentGrip reports were updated on 14 August with a section requiring agents to identify themselves, and a technical block.
One nuance, and this is our reading rather than any court's. The Ninth Circuit's logic leaned on how Comet worked: the browser sat on the user's own machine. Muse runs on a computer Meta operates. Law firm commentary on the ruling flags exactly that kind of server-to-server architecture as an open question. So the legal status of an agent that logs into a store from its vendor's cloud is less settled than August's headlines suggested, and it will probably be settled by a large company with a large legal budget. Not by you, and not this year.
What does this look like on a store our readers run?
Leave the legal question with the giants and look at what arrives at your login page. A customer asks their agent to reorder the same coffee filters as last time, or to check whether an order has shipped, or to return something. The agent signs in with that customer's real email and password, from a cloud machine in a data centre the customer has never been near, on a browser your store has never seen for that account, and moves faster and more directly than a person would. Then it goes to order history, or the saved addresses page, or checkout.
Read that list back and it is, almost line for line, the description of an account takeover. New device, new location, data centre network, confident navigation straight to the account pages. Whatever fraud and bot protection your store runs was written, sensibly, to treat that pattern with suspicion. So one of two things happens. Either your rules challenge or block the agent, and your customer, who did nothing wrong, has a worse experience at your store than they had yesterday. Or your rules let it through, and you have quietly lost the ability to tell your customer's agent apart from someone who stole your customer's password. Neither outcome is a decision anyone made. Both are what the defaults decide for you.
The two conclusions that both get this wrong
The first wrong conclusion is to copy Amazon. Amazon can block a popular agent because it has its own, because customers who hit a wall there mostly shrug and come back, and because it has the lawyers to defend the terms it wrote. A mid-sized store that blocks its customers' agents is not protecting a moat. It is making itself the one shop the agent cannot finish the errand at, and the agent will simply finish it somewhere else. The second wrong conclusion is that none of this matters yet because Muse is US-only and Amazon locked it out anyway. Your US customers are already its users, Muse is one agent among several with the same design, and the thing Amazon objected to, an unannounced agent inside customer accounts, is the normal behaviour of the whole category. Waiting does not mean the traffic does not arrive. It means your fraud rules decide how to treat it, without anyone having asked them to.
What would we actually decide?
Not whether to allow agents. That framing is Amazon's, and it fits Amazon. The useful question for everyone else is which actions inside a customer account are fine for a delegated agent to take, and which ones need the human to step back in.
- Sort account actions into tiers and write them down. Browsing, building a cart, checking order status and reordering something already bought are low risk, and a customer's agent doing them is what good service looks like. Changing the email, password, shipping address or saved payment method, or redeeming loyalty points and gift card balances, is exactly what an account takeover does first. Those should ask the human directly, by a code or a link to a channel the agent does not control, however the visitor signed in.
- Ask what your fraud and bot tools currently do with a login from a data centre network on a new device. You probably do not know, and the answer is the policy you are running today. If the answer is a hard block, some of your real customers are already meeting it.
- Reward agents that say who they are. Shopify asked bots and agents to sign their requests with Web Bot Auth from 30 May, with the most restrictive limits reserved for those that do not. An agent that identifies itself can be given a smoother path, and an unidentified one making account changes can be given more friction. That is the permissioned model Amazon applies to its own Buy for Me agent, applied proportionately rather than as a wall.
- Read your own terms of service with a lawyer. Most store terms say nothing about software acting for a customer. Amazon's whole enforcement rests on a clause it added in August. You do not need Amazon's clause, but you should know whether yours says anything at all, and whether you would want to rely on it.
- Tell support what they are about to hear. "I didn't place that order, my assistant did" and "your site keeps blocking my assistant" will both reach your inbox. A two-line answer agreed in advance beats a new policy invented by whoever picks up the ticket.
- Watch for it in your logs before deciding it does not happen. Sign-ins from cloud networks that go straight to order history or checkout, with no product browsing first, are worth a look this month. You are looking for the shape of the traffic, not for any one agent by name.
The genuinely encouraging part
The two things Amazon demanded, that agents identify themselves and that nobody moves through customer accounts undisclosed, are both reasonable, and they are becoming the default rather than something every store has to negotiate alone. Shopify already asks agents to sign their requests. Cloudflare is issuing agents verifiable identities. Meta's own design puts purchases behind a human approval step. None of this requires you to pick a side between two companies you will never meet. It requires one written page: what an agent may do in a customer account at your store, what needs the human, and what your tools do about the difference. A store that has that page can welcome delegated shoppers as good customers, which they mostly are, and still stop the attacker who looks like one.
Where we fit
The reason this is hard is not technical. The decision touches fraud rules, account security, checkout, your terms, your support scripts and your marketing, and in most businesses each of those has a different owner who has never been asked about AI agents at all. That is the job of our Fractional Head of AI and Digital work: one senior person who owns the question across all of them. For this specific issue that means mapping what your store currently does with a delegated sign-in, writing the tiered policy with you, getting the high-risk actions behind a customer step-up, checking your platform and fraud settings match it, and giving support the answer before the first confused ticket. It is a few weeks of decisions, not a project, and it means the next headline about an agent being locked out of somewhere is news you read rather than a problem you have.
Sources
- TechCrunch — Meta's AI agent has been blocked from using Amazon.com (21 September; the pop-up wording shown to users, and Amazon's likely reasons)
- GeekWire — Amazon blocks Meta's Muse AI assistant in new standoff over agentic shopping (the timeline, Amazon's stated objections about identification and stored credentials, Meta's reply, Buy for Me's identify-and-opt-out design, and Amazon's earlier moves against other agents)
- Meta — Introducing Muse (8 September; what Muse does, the secure environment and browser, credential storage and the approval step before purchases)
- MarkTechPost — Meta introduces Muse, a personal AI agent that runs on its own dedicated secure cloud computer (the per-user virtual machine and the separate credential service)
- ContentGrip — Amazon blocks Meta Muse shopping access (the 14 August update to Amazon's Conditions of Use and its agent identification requirement)
- United States Court of Appeals for the Ninth Circuit — Amazon v. Perplexity opinion (4 August; the holding that the user, not the AI company, accessed Amazon's computers)
- Cooley — Ninth Circuit rules on AI agent access to third-party websites under CFAA (what the ruling leaves open, including terms-of-service claims and agents that run on the vendor's servers)
- Eric Goldman, Technology & Marketing Law Blog — Ninth Circuit lifts restrictions on agentic AI accessing Amazon (independent legal analysis of the Perplexity ruling)
- Shopify developer changelog — Bots and agents should identify themselves via Web Bot Auth (7 May, effective 30 May; signed requests for better access, the tightest limits for agents that do not identify)
- JTS Tech Services — Agents are getting verified IDs and funded wallets (12 August; the agents that carry their own identity, the other half of this picture)
- JTS Tech Services — Your bot protection is blocking AI shoppers (3 August; the edge settings that turn anonymous agents away from your public pages)
