Why Amazon Blocked Meta's Muse AI Agent: It Logged In as the Customer

On Sunday night, September 20, 2026, people sending Meta's new Muse agent to shop on Amazon started getting a popup: "Continued access by an unauthorized AI agent violates Amazon's Conditions of Use, to which our customers have agreed." Most coverage read it as Amazon guarding its storefront, and there is some of that in it. But the popup does not say the payment failed or the card was declined. It says the wrong party was at the door. Amazon's objection is about how the agent arrived: logged in as the customer, without saying it was an agent.

What happened

Meta launched Muse on September 8. It is a personal agent that Meta says can handle tasks "like sending an email or booking travel," and that "can open a browser, fill out forms, and negotiate on their behalf." Where a service has no public interface for agents, Muse uses the website the way a person would.

Amazon told GeekWire that Meta never said Muse would be shopping on its store and never got permission. Amazon made three further complaints: Muse does not identify itself when it browses, it appears to capture and store customer credentials, and once pointed at an account it can reach account pages and order history. The spokesperson's statement was short:

"We think it's fairly straightforward 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."

Amazon added that agentic apps such as Muse "have the same obligations," and asked Meta to remove Amazon from the experience.

The competitive reading is fair. Amazon runs its own shopping agents, has sued Perplexity over its Comet browser, and has moved to block shopping agents from Google and OpenAI. Nobody should pretend the storefront is not part of this. The complaint still deserves to be taken at its word, because every merchant that sells online will face the same session soon, most of them without Amazon's lawyers.

Meta's answer is true, and it answers a different question

Meta's position is that the model never sees your password. From the launch post: "Muse has no visibility into people's passwords or payment methods. Any credentials a person shares go into secure storage, so Muse can use them without seeing them." Meta's security write-up goes further. A login you type is routed to a credentials store outside the agent's runtime, "is not visible to your main agent, but gets injected into the browser window at the point of need."

That is careful engineering, and it protects the customer from the model. It does nothing for the merchant, because the merchant was never looking at the model. It was looking at a browser session. In a passage about advertising, the same write-up says: "When Muse browses the internet, it will appear as your activity."

That sentence is Amazon's complaint. The store sees a customer. The customer is not there.

When the agent logs in as you, the merchant sees you

I published a book on this a week before the popup went up. Secrets and Agents came out on September 13, and Chapter 4 describes the move Muse makes: "So the industry reaches for the obvious workaround. Let the agent log in as its owner."

The same chapter looks at the improvements being made to that move and gives each its due. Vaults are one of them. Meta's version is better than the one the book describes, because the agent never holds the secret at all. The browser gets it at the last moment. But the password still leaves the vault, and it still goes to Amazon as the customer. Improving the vault changes who can see the secret. It does not change who the merchant thinks it is dealing with.

The cost of that falls on the customer as much as on the merchant. The book follows Callum, a football supporter in Glasgow who gives his agent his ticket-site login so it can buy away tickets the moment they go on sale. A seeded listing page talks the agent into buying four tickets for a different match and sending them to a different email. When he disputes it, every log on the site says he did it, because as far as the site could tell, he did. Chapter 10 puts it this way: "Every record on the merchant's side says the owner did it." The owner and the agent end up as one entry.

That is what Amazon is refusing, with a lot more at stake than four tickets. An account with years of order history and saved cards sits behind a session that says it is the customer. Hiding the password from the model does nothing about that.

What the merchant actually asked for

Read Amazon's statement again and it asks for two things. Operate openly. Respect the provider's decision about whether to take part. Neither asks for a better vault.

Chapter 10 of the book, "The Delegate," puts the merchant behind the counter and asks what it needs to know before an agent buys anything. It comes down to three questions:

• Is this an agent, and which one? Software with a name of its own that the merchant can point to afterward. A person typing quickly would not count.
• Is it authorized? By this owner, for this action, within these limits, right now.
• Are the owner's conditions met? The member price is for members. An agent can be real and properly sent while its owner still does not qualify.

The first question is "operate openly." The second is permission from the customer, given in a form the merchant can check without taking the agent's word for it. The third is the merchant's own rule, and that is where "respect service provider decisions" lives. A merchant that wants no agents at all can still say no, but now it is saying no to an agent that announced itself. Every one of the three is a question the merchant asks, on its own terms, before the sale.

Other systems could answer these questions too. In the one we built, each is answered from public state that anyone can read, so the merchant and the agent's provider never need a private arrangement with each other. An agent that registers itself in an on-chain registry is findable under its own number, tied to its own wallet. An owner who signs a delegation to that wallet, with a spending cap and an expiry, has left a permission anyone can read and the owner can cancel with one transaction. The owner's own wallet shows whether they hold the membership, the pass or the shares. The agent gives the merchant its owner's wallet address, which is public. It never hands over the owner's password, because it never had it.

The second question hides a fourth property: revocability. The merchant does not need to know that the owner once authorized this agent. It needs to know the agent is still authorized now. A password handed over last month cannot tell it that. A delegation read at the moment of sale can, and if the owner has cancelled it, the answer is no.

In that picture the owner and the agent stay two entries. If something goes wrong, the record shows which wallet acted, under whose permission, within which limits. Callum does not lose the argument.

The login was built for a different question

Every login on the web answers one question: which human account is this? For people, that was enough. The account and the person were the same thing, and a merchant could hold the person to whatever the account did.

An agent needs different questions answered. Which piece of software is this? Who authorized it, and to do what? Do the conditions for this purchase still hold right now? A login can answer none of them. It can only say which account the session belongs to, and when an agent logs in as you, the answer is you. Amazon and Meta are arguing over the space between those two sets of questions, and every merchant that sells online will end up in the same place.

This is running now, in a narrow form

I do not want to oversell this. Nothing here is a drop-in for Amazon's checkout, and nobody at Amazon asked for it. What exists is the shape, running live.

Wallet auth establishes the facts a merchant needs before an agent acts. It reads wallet state, evaluates it against conditions and returns a signed yes or no that anyone can check against a published key. All three questions above can go in as conditions in one request, and the answer is yes only if every one held. Agent registration checks the ERC-8004 identity registry on Base. Authorization checks an ERC-7710 delegation signed against the MetaMask Delegation Framework on Base (root delegations only, for now) and confirms it has not been revoked as of a named block. Because revocation is one transaction away, a signed answer that includes a delegation expires in five minutes rather than the usual thirty. The owner's holdings can be checked across 37 chains.

That is narrower than "every agent, every merchant." It is also concrete: a merchant can know "registered agent, authorized by this owner, owner qualifies" before the sale clears, and nobody hands a password to anyone.

The agent should arrive as itself

Keeping the password away from the model was the right call for users, but it was never going to satisfy the store, because the store never saw the model. It saw a customer who was not there. Fixing that does not need Amazon and Meta to agree on anything except that an agent should arrive as itself, carrying a permission instead of a password. Then the merchant can say yes or no in the open, which is what Amazon asked for on Sunday night.

Douglas

Sources: GeekWire, "Amazon blocks Meta's Muse AI assistant in new standoff over agentic shopping," September 20–21, 2026 (popup text, Amazon's statement and complaints); TechCrunch and The Register, September 21, 2026; Meta, "Introducing Muse," about.fb.com, September 2026; Meta, "Security and safety for AI agents: our approach with Muse," research.meta.ai, September 8, 2026. Quotations from Secrets and Agents (2026), Chapters 4 and 10.

The book behind this post

Secrets and Agents: Why AI Agents Cannot Hold Secrets, and How the Blockchain Becomes the Way They Prove Anything is Douglas Borthwick's third book. It argues that an agent carrying its owner's password is a leak waiting to happen, and that an agent carrying a permission it can prove has nothing worth stealing. Chapter 4 covers why an agent cannot keep a secret. Chapter 10 covers the delegate that never needs one. In paperback, hardcover and Kindle.

Get Secrets and Agents on Amazon →