Amazon blocks Meta's Muse at checkout: the agent identity fight behind the tollgate

Overnight on September 20, Amazon started blocking Meta's Muse agent at the moment it tried to complete a purchase. Muse launched on September 8 with checkout going through Stripe Link, so the block lands squarely on the feature Meta advertised. Two things about this story are settled: the block exists, and the two companies describe it differently. Everything past that is a claim by one side or the other, and I'll label it that way.

Two accounts of the same block

Amazon's position, as reported by GeekWire and Forkast, is that Muse's access was never announced, that the agent does not identify itself as an agent, and that it apparently stores customers' login credentials. Any of those would violate Amazon's Conditions of Use, and the credential point is the serious one.

Meta denies it. Its line is that Muse has no visibility into passwords or payment methods, and that a login goes into secure storage which the agent reaches only indirectly. I haven't seen a technical description from either side of what that storage is or what "indirectly" means, and I haven't seen Amazon's evidence for "apparently". So I can't tell you who is right. Both statements can even be true at once, which I'll get to.

What I'd rather write about is the shape of the argument, because it will repeat with every retailer, bank and booking site an agent touches. It is not a fight about whether the agent can shop. It is a fight about who the agent is, and whose keys it is holding.

Why "indirect access" doesn't settle it

Suppose Meta is exactly right. The agent never sees the password, a vault holds it, and something injects it into a browser session. From Amazon's side of the wire that still looks like a login from a machine Amazon has never seen, driven by software that doesn't say what it is, using a session that belongs to a customer. My inference, not something either company said: a defence built on "we can't read your password" answers a question about custody, while Amazon's complaint may be about identification and consent. Those are different axes, and you can win the first while losing the second.

That distinction is what agent authentication is about. There are roughly three postures. The first is impersonation: the agent logs in as the user with the user's credentials and pretends to be them. It works today, everywhere, and it is exactly what a platform can't tell apart from account takeover. The second is delegation: the platform issues the agent a token of its own, scoped to a narrow action (add to cart, buy up to this amount, expire in an hour), tied to a user who granted it. The mechanics exist already in OAuth-style flows, and token exchange (RFC 8693) even has a way to say "this token acts on behalf of that user". The third is signed identity for the software itself, where the agent proves what it is on every request, for instance with HTTP message signatures (RFC 9421), so the site can allow it, rate-limit it or refuse it by name.

As far as I know, Amazon offers no public consumer-shopping API for third-party agents that would give Muse a delegated route. If that's right, Meta had one way in, which is the impersonation path, and Amazon has a legitimate reason to dislike it. If I'm wrong and there is such a route, then Meta skipped it. I'd want to know which.

Who holds checkout

Checkout is the last gate before money moves, and it has always been the owner's to lock. For years that was fine because the customer at the gate was a human with a browser. An agent that shops for you is a middleman inside the one step retailers guard hardest, and it asks them to trade a direct customer relationship for a promise that a third party is being careful.

Whoever can say no at checkout owns the customer, and an agent that can't prove what it is has no standing to argue.

So I expect a tollgate, and I think the price of admission will be identity: register your agent, sign your requests, take a scoped token, accept the platform's rules on what you may do with the session. That is annoying for agent builders, but it is also the version where users are protected. The alternative is a growing pile of agents driving logged-in sessions that platforms fight with bot detection, which punishes the well-behaved ones first.

There is a mirror image worth studying. Block's Buzz gives every agent its own keypair so an action is attributable to a specific signer, which is the same problem solved on the other side of the wire. And my earlier piece on Meta's Muse agent covered its always-on browser and hidden credentials, which is exactly the design that now meets a wall.

If you build agents on top of somebody else's platform, my practical advice is boring. Find out whether a delegated route exists before you write the browser automation. Never store a user's password if a scoped token is available. Identify the agent in every request even when nobody asks you to. The unresolved question is whether Amazon opens a door for agents like Muse or only closes the current one, and I don't think anyone outside Amazon knows yet.