Amazon has blocked Meta’s Muse from shopping on its site for customers, according to a September 20 report by GeekWire. Amazon told the publication that Muse operated without an agreement or adequate agent identification, and raised concerns about the capture and storage of customer credentials. The report included an Amazon-supplied screenshot of the block. Meta had not responded by publication that Sunday night. Those are Amazon’s objections, not findings that a breach occurred. GeekWire’s original report
For a shopper, the interruption poses an awkward question. If you choose an assistant to compare products and place an order, how much of that choice survives the store’s decision about which assistants it accepts?
The answer will help determine whether shopping agents make it easier to compare businesses or confine customers to another set of approved partners. It also matters to smaller retailers, which may welcome a new source of orders while worrying about who will explain their products and handle a mistake. Customer delegation, store participation and payment approval each address a different part of the transaction.
A working payment connection still needs a willing shop
Meta introduced Muse on September 8 as a personal agent that can continue tasks in a dedicated cloud computer. Its launch description includes shopping and says consequential actions, including purchases, require approval. These are the company’s descriptions of the product, not results of testing by BIG CHANGE. Meta’s Muse announcement
Stripe supplies a more specific account of the payment connection. Its September 8 announcement says US consumers can connect Link to Muse. At businesses using Link, the agent can use the customer’s saved preferred method. Elsewhere, Link can issue a single-use virtual card scoped to the approved purchase. The customer approves the total in the conversation, and Muse does not receive the underlying payment details. Stripe’s integration announcement
A protected payment method can reduce what an agent needs to know to pay. It cannot, by itself, make a retailer accept the agent’s visit. Likewise, a shopper’s instruction to buy a particular item does not tell the store how to distinguish that request from unwanted automation. The systems need a way to recognize the shopper’s authority without assuming that every action the software attempts falls within it.
Our earlier analysis of payment permissions for AI agents examined the controls around spending. This dispute exposes an earlier dependency: the assistant needs access to enough of the shopping process to produce an order the customer can approve.
Consider a hypothetical request to buy a replacement appliance part, within a fixed budget, for delivery before a repair appointment. The assistant must find the exact compatible model, check stock and delivery, and reach checkout. An approved payment instruction is useful only after those conditions are satisfied. A block during the search can change which products the agent considers; a block at checkout can leave the customer repeating work already delegated.

Password storage and model visibility are different questions
Meta’s technical account says credentials are stored in a secure service inside the user’s virtual machine, outside the main agent’s runtime. The browser receives them when needed; the main agent does not see them. A separate supervisory component checks actions and can require approval. Meta also says its current operational controls do not technically prevent the company from accessing the virtual machine when needed to operate the service. Its proposed confidential-computing version is a future step. Meta’s security and safety design
Keeping a password out of the model’s context can limit one route through which it might be exposed. The service still needs to store or use credentials somewhere. Readers should ask who can access that storage, what account permissions the session grants, and how access can be revoked. A claim about one component cannot answer all those questions.
Nor does a technical design document independently establish how safely a deployed system behaves. A useful assessment would examine what an agent can do after login, how it reacts to misleading page content, and whether the customer can reconstruct an unexpected action. That is a broader inquiry than checking whether the model saw a password.
Amazon’s commercial interest in retaining the shopping relationship does not make its security concerns false. Meta’s account of protections needs independent examination. Evidence about actual access and failures would be more useful than either company’s preferred description of the other.
Amazon also wants agents to shop beyond its own store
Amazon’s published description of Buy for Me explains a service that purchases from external brand websites through its shopping app. The customer confirms the order; the brand handles delivery, returns and customer service. Amazon says brands can choose whether to participate. The page describes its beta introduction, so it should not be read as a current inventory of every supported store. Amazon’s Buy for Me description
The arrangement shows why the terms of participation deserve scrutiny. A retailer may welcome automated orders when it knows the intermediary and has an agreed way to resolve problems. The same retailer may object to an unfamiliar agent using customer accounts through a general browser. Differences in implementation can justify different treatment.
They also create room for selective treatment that benefits a powerful intermediary. If every large retailer requires a separate partnership, an assistant’s reach may depend on commercial agreements that shoppers cannot see. A small developer with a sound product could struggle to obtain the same access as a large platform. A merchant could gain new customers while becoming dependent on the assistant that recommends it.
Our view is that access rules should be specific enough to examine. Requirements for identification, limited permissions and a reliable complaint process are easier to assess than a general assurance that approved partners are safe. Where comparable agents receive different treatment, retailers should explain the operational difference. That would let customers distinguish a measurable protection from a preference for a particular business relationship.
The Comet ruling leaves the Muse dispute open
An August 4 Ninth Circuit opinion vacated a preliminary injunction against Perplexity and returned the case for further proceedings. On that record, the court found Amazon unlikely to establish the required access element under the federal Computer Fraud and Abuse Act and its California counterpart. Comet’s browser ran on the user’s machine; the court treated the user as accessing Amazon with an AI tool. It expressly preserved Amazon’s ability to regulate users through private terms of service. The original appellate opinion
Muse uses a hosted virtual machine and browser, a materially different setup from the one described in that case. The opinion did not decide Muse’s position or establish a universal entitlement for shopping agents to enter websites. Its narrow reasoning is a reason to examine the implementation before predicting a legal outcome.
For businesses planning an agent-based service, a favorable decision involving another product is therefore a poor substitute for understanding their own access arrangements. A customer-facing promise should describe where the service actually works and what happens when permission is disputed.
“Best available” needs a visible search boundary
The strongest customer case for shopping agents is the reduction of repetitive work. A person should be able to specify what matters once, compare suitable offers and retain control over the final purchase. Someone who finds forms difficult, or who has little time to research an exact replacement, could benefit substantially from dependable assistance.
That benefit depends on an honest account of the search. If an agent cannot use an important store, its recommendation may still be useful, but the missing coverage changes what it can claim. The cheapest accessible offer is not necessarily the cheapest offer the customer could obtain directly.
For the hypothetical appliance-part purchase, a useful result would show which stores were checked, which could not be reached, and the total delivered price. If the best candidate requires a manual visit, the assistant should preserve the product reference and explain the unfinished step. Quietly substituting an accessible merchant could cost the customer money or miss the repair deadline.
The same clarity should carry through to order status. A buyer needs to distinguish a prepared basket, an approved payment and a confirmed order. After a failure, the assistant should make clear whether anything was purchased before suggesting a retry. These are proposed standards for a useful service, not capabilities we verified in Muse.
A polished conversational answer can conceal a restricted search more easily than a visible list of stores. Our earlier examination of Muse’s business incentives considered who benefits from the assistant’s recommendations. Access restrictions add another influence: some sellers may never enter the comparison at all.
Retailers need evidence from completed orders
A smaller merchant deciding whether to accept agents should start with a narrow, observable use case. An assistant could help customers find the correct item and prepare an order while leaving consequential changes to an explicit confirmation. The merchant could then examine completed purchases, incorrect items and support time, including cases where the assistant abandoned the task.
Counting agent visits would say little about whether the channel helps. More traffic could produce more paid orders, or more confused customers asking staff to resolve what an intermediary promised. Returns need to be counted alongside conversions. The merchant should also know whether the agent represents delivery and refund conditions accurately and whether the customer can find the responsible seller after checkout.
Customers could gain a choice of useful assistants, with merchants accepting them under intelligible, proportionate rules. But if access depends on a series of exclusive arrangements, shoppers could end up in restricted networks, each presenting a partial set of offers as convenient personal advice.
The reported block gives customers a concrete question to ask before delegating their next purchase: which stores will this assistant check, and what will it tell me when one refuses access? A service that answers clearly can remain useful even with limited coverage. Concealing that limit would make its recommendation harder to trust.



