Amazon opened the back office and closed the storefront in the same week

At a glance

Two decisions, two days apart, from the same company about the same technology.

What actually happened

The block

Meta introduced Muse, a personal agent for everyday tasks including shopping, earlier in September. Amazon asked Meta to exclude Amazon.com from the experience; Meta declined; Amazon started blocking on Sunday night. Shoppers who pointed Muse at the store got a pop-up telling them that "continued access by an unauthorized AI agent violates Amazon's Conditions of Use, to which our customers have agreed."

Amazon gave three reasons, and they are worth separating because each one names a missing mechanism rather than a missing permission: Meta did not tell Amazon that Muse would be shopping there; the agent does not identify itself when it browses; and, in Amazon's characterisation, it captures and stores customer credentials. This was not Amazon's first: it had already shut out Perplexity's Comet, with a court order in March 2026, and ChatGPT's shopping features before that. eBay went further in February 2026 and wrote the prohibition into its user agreement.

The opening

Two days later, at Accelerate, Amazon shipped the opposite. Seller Assistant — the agent it already offered sellers, running on Bedrock with Amazon Nova and Claude — gained persistent memory and always-on workflows, and, more importantly for this argument, a Selling Partner plugin that exposes its capabilities to outside AI clients. Sellers in the US beta can manage inventory, prices, listings and analytics from Amazon's own Quick assistant or from Claude, without opening Seller Central at all. That is a third-party agent taking commercial actions inside Amazon's systems, shipped the same week Amazon was writing pop-ups about unauthorised agents.

The variable is the delegation, not the agent

Both decisions fall out of one question: when this agent acts, can Amazon tell whose authority it carries, bound to what, and can Amazon take that authority away without harming the person who granted it? On the seller side every part of that has an answer, and has had one since long before agents existed.

• There is a named counterparty. A selling account belongs to a business that signed an agreement. If its agent misbehaves, there is somebody to suspend and somebody to sue.
• The credential is not the human's. Partner API access is issued to an application, scoped to operations, and revocable on its own — pulling it does not lock the seller out of their own account.
• The grant is per-seller and visible. Each seller authorises the plugin for their own account, which means both parties can see the delegation and either can end it.
• The incentives point the same way. A seller whose agent reprices faster sells more, and Amazon takes its cut either way. Automation on the supply side deepens the relationship; it does not threaten the revenue model.

On the buyer side, none of the first three exist. A third-party shopping agent has exactly one way to act as you: your login. Amazon cannot tell it from you, cannot scope it to "buy this one item", and cannot revoke it without locking out its own customer. The asymmetry has nothing to do with how good the agent is. It is that one side of the market has a delegation primitive and the other has credential sharing wearing a nicer coat — the distinction agent identity and permissions turns on, and the reason the principal–agent problem shows up here as an engineering constraint rather than a philosophy seminar.

The fourth point is the one that gets overstated in commentary. Yes, Amazon's storefront is where discovery is monetised, and an agent that skips the carousel skips the advertising; that is a real motive and it is not the load-bearing one. eBay's ban and Amazon's block both cite identity and terms, not ad revenue, and Walmart and Target — who also sell advertising — went the other way while Shopify opened its catalogue outright. Incentives explain who moves first. The mechanism explains what they can safely do at all.

Read Amazon's three complaints as a specification

Each complaint maps onto a control that does not exist for consumer agents yet, and the mapping is the most useful thing in this story:

• "They did not tell us" → there is no registration. A seller-side integration is a known application with an entry in a partner programme. A consumer agent arrives as traffic. Registration is what makes an access decision possible at all, and it is what the bot verification and agent access work is for.
• "It does not identify itself" → there is no verifiable operator identity. A user-agent string is a claim, not a credential. Signed requests fix this half — the operator becomes checkable — and they are already in production at several CDNs, which is why this is the nearest of the three to solved.
• "It captures and stores credentials" → there is no mandate. This is the hard one and the one no amount of good behaviour by the agent vendor can fix. What is missing is a token the user issues, scoped to an act, carrying proof they authorised it, that the retailer can validate and expire. That is precisely what the agentic-commerce protocols are specifying; see AP2 and agent commerce.

Which is why the third row of the table at the top matters more than either headline. Amazon joined the UCP Tech Council in April 2026, five months before blocking Muse, alongside Meta — whose agent it has now blocked. Google launched that standard with Shopify in January; Etsy, Target and Wayfair were founding members; Shopify's Spring '26 Edition shipped the catalogue and universal cart that let agents transact across merchants. Amazon is not opposed to agents buying things. It is opposed to agents buying things through a channel where nobody can say who authorised what — and it has a seat in the room where that channel is being defined.

What this means if you are building an agent

The practical lesson is a reordering of the first question you ask about any integration. Not "is there an API", and not "can we drive the UI", but: what can the counterparty verify about my authority to act here, and how do they revoke it? If the honest answer is "they can't, because we hold the user's password", you are building on the side of the line that gets blocked, and the block will arrive as a terms-of-service action rather than a technical one, which means no amount of engineering will route around it.

• Prefer the side with a partner programme. Every marketplace, ad platform, CRM and ERP has one, it issues scoped credentials, and it is where agent access is being granted first because the delegation was already built. This is unglamorous and it is where the deployable work is.
• Identify yourself even where nobody demands it. A stable operator identity and signed requests cost little and are the precondition for being allowlisted rather than fingerprinted. The alternative posture — blending in — is the one Amazon named as a reason to cut you off.
• Never take the user's credential when a token exists. Storing a customer's retail password is the single fact that turned a commercial disagreement into a security objection, and it converts every future negotiation into one about your breach exposure.
• Assume admission is per-platform and revocable. The shape arriving is not an open web for agents; it is allowlists, betas and council seats. Build for an integration that can be switched off by someone else, and instrument what your agent does when it is — the third-party tool drift problem, with a legal trigger.

And if you operate the site rather than the agent, the symmetric lesson: you will be asked to decide about agent traffic before the standards land, so decide by mechanism. Publish what a registered agent gets, require an identity for it, and keep the refusal for anyone arriving with a customer's password. That is a policy you can defend in both directions, and it is materially cheaper than trying to detect agents by behaviour.

The part that generalises past retail

Strip out the shopping and the pattern is the one every agent deployment hits at its edges. Two systems, a human with an account on both, and an agent that needs to act on one for the benefit of the other. Inside a company you solve this with an identity provider and on-behalf-of tokens and consider it plumbing. Across a company boundary, between a consumer and a retailer, that plumbing does not exist — and so the first generation of consumer agents did the only thing available, which was to hold the credential and browse as the human.

That was always a transitional arrangement, and September is roughly when the transition started being enforced. The interesting question for the next year is not which retailers block which agents. It is whether the buyer-side mandate ships as an open mechanism that any agent can present, or as a membership benefit administered by a council of the ten largest companies in commerce. Both are consistent with everything Amazon did this week.

Further reading

On this wiki:

• Agent identity and permissions — whose authority an agent carries, and why the answer decides the access.
• Bot verification and agent access — how sites are deciding which agents get in.
• AP2 and agent commerce — the mandate layer the buyer side is missing.
• Shopping and checkout agents — building on the side of the line that is open.
• Delegated access and consent records — keeping proof of what a human authorised.

Sources:

• TechCrunch — Meta's AI agent has been blocked from using Amazon.com
• Amazon — Seller Assistant plugin for Amazon Quick and Claude
• Google Developers Blog — Under the hood: Universal Commerce Protocol
• Shopify — Agentic commerce for every developer, Spring '26 Edition