Amazon vs Meta's Muse shopping agent: why session custody, not agent identity, is the line

My agents drive a real Chrome on my desktop. It is logged into work and client accounts, and when an agent opens a page there, the site on the other end gets my browser, my cookies, my session. Nothing in the traffic announces that an agent is at the wheel. It declares exactly what I declare when I browse myself.

That is the uncomfortable starting point for last week's news, because Amazon just walled off Meta's Muse, and one of its complaints was that Muse does not identify itself while browsing. Neither do my agents. By Amazon's stated standard, I run Muse at home.

What did Amazon actually object to in Meta's Muse agent?

Three things, according to what Amazon told GeekWire, as The Register reported on 21 September: Meta did not tell Amazon it planned to send Muse in and had not obtained authorization; Muse does not identify itself while browsing; and it appears to capture and store customer credentials, with reach into account data like order history. Muse users who try it get an error page saying access by an unauthorized AI agent violates Amazon's Conditions of Use. Meta's answer was about the credentials only: they are held in secure storage and used for authentication without being exposed to the model.

Muse launched on 8 September and had held the top spot in both US app stores since the 18th and 19th when TechCrunch checked on the 25th. Amazon has already blocked shopping agents from Google and OpenAI and sued Perplexity over Comet. It also runs its own agent, Buy for Me, which buys from other retailers' sites, identifies itself, and lets those retailers opt out. The Register puts Amazon's advertising revenue last year at over $68 billion, money that depends on people looking at Amazon's pages.

So two candidate lines are on the table. The agent says who it is. Or the credential never leaves the user's control. I think the first is not a safety line at all, and the second is drawn in the wrong place.

Does identifying an AI shopping agent protect the user?

It protects the site's ability to decide, which is a different thing. The court record says so directly. When the Ninth Circuit ruled on Amazon's case against Perplexity in August, it described the core of the dispute this way:

At the core of the dispute was Perplexity’s decision not
to use a “user-agent string,” a mechanism “that would
communicate that the user has activated an AI agent.” That
user-agent string would allow Amazon to block the
Assistant’s access to the Amazon store.

The identification Amazon wanted had a stated job, and the job was blocking. Buy for Me shows the same mechanism from the other side: it identifies itself so that other retailers can opt out. That is the veto working as designed, offered by the company that wants the same veto at its own door.

A plain user-agent string is also just a claim a client makes about itself, so the serious version is cryptographic. RFC 9421 defines HTTP Message Signatures, and an IETF working-group draft, Web Bot Auth, uses them so an automated client can sign its requests with a key its operator publishes. A server can then check that a request really came from the holder of that key. What the server does with that fact is a separate decision the protocol leaves to the site, and the obvious decisions are allow, block, or charge. Verified identity makes an agent accountable and billable. It says nothing about what the agent does to the user whose session it is sitting in.

The law points the same way, at least for now. The same opinion found that, on the record before the court, it is the user and not Perplexity who "accesses" Amazon's computers under the federal anti-hacking statute and California's equivalent, because Perplexity's servers never touch Amazon's and the agent works through the user's own browser. It was an appeal from a preliminary injunction, the injunction was vacated and the case sent back, and the court was explicit that different facts about how much control the provider has could come out differently. Amazon asked for rehearing, and on 10 September the court denied it without a single judge requesting a vote. In a footnote the panel added that its ruling "does not impair Amazon's ability to regulate access to Amazon.com via private terms of service for its users." My read, and it is only a read, is that the fight moves toward those terms, the same Conditions of Use that Muse users now see quoted on the error page.

Is "the model never sees the password" the line for AI agents?

It is the right kind of line in the wrong place. Meta's claim is narrow: the password string sits in secure storage and is used for authentication without passing through the model. Fine. But once the session is open, the agent can reach whatever the account can show: order history, addresses, saved payment details in whatever form the site displays them. How much of that actually lands in the model depends on the implementation. The password was only ever the key to the session.

I learned that from my own agents, and not in the browser. Agents I run pulled client email into per-client folders, and the filtering was loose enough that one client's thread could land in another client's folder. I caught it and moved to strict per-client labels plus name validation. The failure did not need a credential to leak. The agent was already inside, legitimately, and the risk was how far it could reach once there. I have argued that what a tool can reach and what it actually touches are separate facts, and this is the same split one layer up: a session grants reach, and nothing asks again what the agent does with it.

So the honest test for any agent holding a session is whether the user can see what it does in there and take the access back. Neither company's statement answers that for Muse. Meta described how the password is held; Amazon described what it fears. Neither said what a Muse user can inspect or revoke.

Why isn't a personal browser agent the same thing as Meta's Muse?

At the network edge it may not be distinguishable, and that is the point: whatever separates an honest agent from a careless one is not in what it declares. The difference is custody, and custody is only as good as the controls behind it.

Mine are boring on purpose. The browser profile holds work and client accounts and nothing personal: no bank, no personal mail, so the session itself is scoped before any agent touches it. An agent opens its own new tab and never navigates one I already have open, because a tab I have open is a live client session and the damage from hijacking it would be silent. Bulk searching never goes through that profile; it goes through a separate API, or the account gets flagged. Where a real API key exists, the agent uses the key rather than the browser, and some keys are held to read-only by policy even where they could write. The agent never types a password. If it hits a login wall, it stops and asks me.

Honestly, most of that is rules, not enforced isolation: a new tab in the same profile can still reach every account in that profile, and read-only by policy is not a read-only credential. What I do have is location and revocation. The sessions are mine, opened by me, on my machine, and I can see and kill any of it. A hosted agent can meet the same test by different means: a log of what it did inside the session that the user can read, a scope the user sets, a revoke that actually works. My desktop is one way to pass the test, not the test itself.

Which also means this line is not one a site can draw. Amazon cannot see custody from its side of the connection. Users and the people building agents have to draw it. The site's line is somewhere else.

Is Amazon protecting users or its ad business by blocking Muse?

Both. Credential handling by a third party is a real risk, and it is the true part Amazon uses to justify the other part. When your revenue is attention on the page, sponsored slots and ad auctions included, an agent that reads the page and skips the ads is not a visitor. It is a competitor standing in your checkout line.

My own site is the opposite of a wall, and I don't pretend that is a principle Amazon is violating. robots.txt says yes to training, search and AI input; there are skill files and an API catalog so an agent does not have to guess. Partly I built that to score well on an agent-readiness scanner, and I will admit it. Mostly it costs me nothing. The site sells nothing and runs no ads, so every agent that reads it is distribution, and a person who reaches me through an assistant is still a reader. That is the economics of a site with nothing on the page to protect.

What should a site owner do about AI agent traffic?

Publish a policy and let agents read your public pages, as long as the page itself is not your product. Say in machine-readable form what they may do and where your API is. Put the walls on actions: checkout, account changes, anything that spends the user's money. Private data needs its own scope controls whether or not money moves, which is the whole lesson of that mail folder. Reading public pages is cheap to allow; spending and exposure are not. It is the same rule I hold my own agents to: the gate that holds is keyed to what an action can reach.

By that rule Amazon's case is strongest exactly where Muse spends money and touches the account, and weakest at the wall in front of everything else. A gate at checkout would be hard to argue with. The error page Muse users get stands in front of the whole store.

And if your business is the ad inventory on the page, say so alongside the security reasons. Charge for access, the way pay-per-crawl schemes are starting to price each crawler request. That does require the agent to identify itself, signed, and that is fine. It is exactly what identification is for: permission and billing. It was never a safety property.

Amazon cannot tell a careful agent from a careless one, and a declared name would not help it. What separates us sits on my side of the connection, where Amazon cannot look, and that is where the user has to look too.