Guillaume Lebedel · · 7 min 
AI agent access: why Amazon blocked Muse and let Claude in
Table of Contents
Amazon blocked Meta’s Muse on 20 September 2026 because the agent browsed Amazon.com without identifying itself and appeared to capture and store customer credentials. On 23 September Amazon launched the Amazon Selling Partner plugin, which lets Claude and Amazon Quick act on seller accounts through a connection Amazon runs, with access limits, seller approval and audit trails.
One company handled AI agent access in two opposite ways inside a week. The difference between them is the question an IT team has to answer for every AI tool it approves, app by app: does the agent reach the app through a grant the app owner can see, scope and revoke, or does it sign in as the user? Every fact below was checked against its source on 28 September 2026.
Why did Amazon block Meta’s Muse agent?
Amazon says Meta never told it Muse would shop on Amazon.com, that the agent does not identify itself when it browses, and that it appears to capture and store customer credentials. From Sunday night, 20 September, Muse users trying to shop saw a popup saying continued access by an unauthorized AI agent violates Amazon’s Conditions of Use.
According to GeekWire’s report on the Muse block, Amazon’s objection is that Muse can open account pages and order history when a customer asks it to. Because the agent does not announce itself, Amazon sees an undisclosed third party moving through customer accounts.
Meta disputes the credential part. Its Muse launch post from 8 September says credentials go into secure storage, so Muse can use them without seeing them. Meta also put a lot of safety work into Muse: a dedicated VM, a separate Sentinel agent that must approve anything Muse sends to the internet, a check with the user before purchases, and an audit trail the user can read. Muse uses a service’s public API where one exists, and a browser “the way you would” where it does not.
The legal backdrop explains why Amazon reached for its terms of service. Amazon sued Perplexity over its Comet browser agent and won a preliminary injunction in March. The Ninth Circuit vacated it on 4 August, ruling that the user, not the AI company, was the one accessing Amazon’s computers under federal anti-hacking law. In the court’s reading, an agent signed in as the customer is the customer, and the app on the other end has no separate party to hold to account.
What did the Muse zero-day let an attacker do?
On 21 September Patrick Wardle showed that any unprivileged process on a Mac could change an undocumented Muse setting that controls where dictation audio goes, point it at an attacker’s server, and take the account token. Ars Technica’s write-up of the Muse 0-day called it the token that gives complete control over the Muse account.
This is a local attack. It needs code already running as the user, from malware or a malicious app, as Malwarebytes points out. Meta shipped a hotfix the next morning, and The Verge reported that Meta rated the practical risk as low for exactly that reason.
The fix closed one bug. The part that matters for access design is what the token carried: whatever the user had connected Muse to. iTnews summarised Wardle’s proof of concept as allowing captured prompts, prompt injection into the assistant and theft of its authentication material. Every control Meta built sits on the agent’s side. Once someone else holds the agent’s token, the apps behind it keep seeing the same customer they always saw.
How does Amazon’s Selling Partner plugin give agents access differently?
The Amazon Selling Partner plugin connects a seller’s Amazon data and Seller Assistant to Amazon Quick, and to Claude in beta, through a connection Amazon builds and runs. Amazon’s announcement says every plugin interaction has clear boundaries on what it can access, human approval on actions and complete audit trails.
GeekWire’s coverage of the plugin launch adds the working detail: sellers choose which types of data the plugin can reach and approve each action before Amazon carries it out. It is available in beta for sellers in Amazon’s US stores, and Amazon says it connects in about 60 seconds with no code.
Amazon is not a neutral referee here. It is a major investor in Anthropic, Claude models already power Seller Assistant, and Amazon now decides which agents get a door. That commercial interest is real, and it does not change the mechanism. Claude reaches seller data through a connection the app owner defined, and Muse reached customer accounts through a login the app owner never agreed to.
How does an API grant differ from an agent logging in as the user?
With an API grant, the app owner issues a scoped, revocable credential to a named client, so the app knows which agent is calling and can limit or cut it off. When an agent logs in as the user, it holds the user’s own password or session, and the app sees only the user, whatever the agent does.
| Muse on Amazon.com (signs in as the customer) | Selling Partner plugin (sanctioned connection) | |
|---|---|---|
| Who holds the credential | Muse’s VM, in Meta’s secure storage | A connection Amazon issues and runs |
| What Amazon sees | An unidentified browser in the customer’s account (Amazon’s claim) | A named plugin from Claude or Quick |
| Who sets the scope | The user, inside Muse | The seller, within limits Amazon defines |
| Who approves actions | The user, when Muse asks before a purchase | The seller, before each action |
| Who keeps the audit trail | Meta, shown to the user in Muse | Amazon, for every plugin interaction |
| Amazon’s lever when something goes wrong | Block the agent for every customer (20 September) | Change or withdraw the plugin it operates |
Who holds the audit trail and approvals in each model?
Both routes promise approvals and an audit trail, so the useful question is who holds them. In the Muse model, Meta holds both and shows them to the user, while Amazon holds neither. In the plugin model, the seller approves and Amazon keeps the log, so the party that owns the data can see what happened to it.
Approval prompts on their own are a weak control. We wrote about an agent that asked permission before running up a $6,531 AWS bill, and got it. An approval is worth more when the system that owns the data enforces the scope underneath it.
How does StackOne handle AI agent access to business apps?
We built StackOne’s connectors around the grant route. Where an app uses OAuth, the customer registers one OAuth app with the provider and each user authorizes it, so the agent acts through the app’s API with access the admin can revoke. Our post on how OAuth works for AI agents walks through that setup, and StackOne’s managed authentication holds the tokens.
On top of that, our tool gateway writes a record for every call that names the verified user and the assistant that made it: what was requested, what was allowed and what came back. The comparison of an MCP gateway and a tool gateway covers that record in detail. It is the per-agent attribution Amazon said it could not get from Muse.
What should IT ask an AI vendor before approving an agent for staff?
Ask each vendor, for each app the agent will touch, whether it connects through that app’s API with a grant the app owner can scope and revoke, or signs in with the user’s password or browser session. The answer decides who can see the agent, who can stop it, and what a stolen token is worth.
Five questions a CIO or Head of AI can put in the approval form:
- For this app, does the agent use an API grant, or the user’s password or browser session?
- Does the app see the agent as a named client, separate from the employee?
- Who can narrow or revoke that access: our app admin, the employee, or only the vendor?
- Where does the audit log live, and does each entry name both the employee and the agent?
- If the agent’s token leaked tomorrow, what could an attacker reach, and how fast could we cut it off?
Not every app has an API that covers what staff need, and browser agents fill real gaps. A workable policy is to allow the browser route only where the app’s owner has agreed to it and the account holds nothing you could not afford to lose. More app owners are likely to follow Amazon and offer sanctioned connections while blocking unannounced agents, though Amazon had commercial reasons of its own, and this is one company’s week of evidence.
If your team is working out how the AI tools your staff use should reach HR, CRM or finance apps, the StackOne docs on connecting agents show how each connector authenticates and what gets logged per action.