Amazon Blocked Muse. The Request Had No Name on It.
Starting Sunday, September 20, people who asked Meta's Muse agent to shop on Amazon got a refusal addressed to the machine: "Continued access by an unauthorized AI agent violates Amazon's Conditions of Use, to which our customers have agreed." GeekWire broke the story. Meta's launch post says Muse "has no visibility into people's passwords or payment methods." Amazon says the agent "appears to capture and store customer credentials." Both sentences can be true at once, and the distance between them is the most useful thing to understand about consumer agents this month.
What Meta built
Muse launched on September 8 in the US on iOS, Android, and muse.ai. The architecture is stated plainly in the announcement. Each person gets a "Muse Secure VM, a dedicated, virtual machine (VM) that houses both the agent and a person's data." A second process, the Sentinel, "runs on that same machine, kept apart from Muse at the system level," and "nothing Muse does reaches the internet unless the Sentinel approves it." Passwords and payment methods sit in secure storage so that "Muse can use them without seeing them." Meta says a Confidential VM, encrypted with a key only the user holds, is coming. The integrations at launch are WhatsApp, email, browser automation, and checkout through Stripe Link, with Shop Pay and 1Password listed as next.
People wanted it. Sensor Tower's numbers, via CNBC, put Muse at 730,000 downloads in the first five days, ahead of ChatGPT as the top free iOS app in the US on Friday, September 18, and past 2.5 million downloads by Monday. The app is free, with $20 and $100 monthly tiers for heavier use.
Read the design as an engineer and it is a serious containment model, and every part of it faces the user. The VM keeps the agent's files, browser, and scratch work off your phone. The Sentinel keeps the agent from doing things on the internet you did not ask for. The secure storage keeps the model from reading your password, so a prompt injected into some web page cannot make the model recite it into a chat. All three protect the person who installed Muse from Muse. None of them says anything to the website on the other end of the connection.
What the storefront sees
Now stand on the other side of the wire. A Muse shopping session arrives at a store as a browser session opened from a machine in Meta's cloud. At some point it fills in the real customer's real password on the real login form, because browser automation is how Muse reaches a site that offers nothing else. From then on the session cookie that proves "this is the customer" lives in a VM the store has never heard of, and requests for order history and checkout come from it.
That is where the two sentences meet. "Use them without seeing them" is a statement about the model: the language model never has the password in its context. It says nothing about custody. The credential is stored somewhere the agent's browser can fetch it, which, from the store's point of view, is a customer password held in a third party's data center. Meta and Amazon are describing the same vault from opposite doors.
The second complaint is that Muse "doesn't identify itself when browsing," per GeekWire's summary of Amazon's position. Browser automation drives an ordinary browser, and an ordinary browser sends ordinary headers. A site has three ways to sort a request into "customer" or "machine," and only one of them is cheap:
- Where it comes from. Network reputation. A residential ISP address looks like a person; a datacenter address looks like a server. Customers on VPNs, cloud desktops, and corporate proxies look like servers too.
- How it behaves. Timing, pointer movement, fingerprint consistency. This works until the automation gets better, and then it is an arms race the store pays for forever.
- What it says. A declared identity. The User-Agent string is a declaration anyone can type, so on its own it proves nothing. A signed declaration is different, and that is the part of this story that has an engineering answer.
GeekWire notes that Amazon's own shopping agent, Buy for Me, "identifies itself and lets brands opt out." Amazon's spokesperson put the demand in one sentence: "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." Strip the corporate interest out of it and that is a request for two protocol properties: declare yourself, and accept a refusal.
One checkout request from three senders. Pick a sender to read what arrives at the store, then set the store's policy. The board underneath scores all three senders against the same policy.
store policy
Illustrative request to shop.example. Header names and the signature parameters follow draft-ietf-webbotauth-httpsig-protocol-00 (September 1, 2026); the signature value is truncated. The delegated token on the signed agent is what a declared path could carry, not a feature any large store offers consumers today.
Two outcomes on that board are worth sitting with. With behavior detection off, the undeclared agent is accepted and the store believes it served the customer, which is the case Amazon is objecting to. And with the store's agent policy switched off, the declared agent is refused while the undeclared one may still slip through. Declaring yourself gets you a clear refusal. Hiding gets you an arms race you might win for a while. That incentive is backwards, and a site can only fix it by making the declared path worth taking: faster, more reliable, and not blocked by default.
The flip side is what a store gains. A store that can recognize an agent can make a decision about it: allow it, rate-limit it, send it to an API, or refuse it with a reason. A store that cannot recognize agents has one lever, blocking everything that smells automated, and that lever also hits the customer on a VPN. Declaration turns a detection problem into a policy.
How an agent says who it is
The declared path already has a draft standard. The IETF's webbotauth working group adopted HTTP Message Signatures for Automated Traffic, published as working group draft 00 on September 1, 2026. It is built on RFC 9421 HTTP message signatures and does three things.
First, the operator of an agent publishes its public keys as a JWKS-style key directory at a well-known path, /.well-known/http-message-signatures-directory, served as application/http-message-signatures-directory+json. Second, every request carries a Signature-Agent header that points at that directory, so the server can discover the key in-band. Third, the request is signed. The Signature-Input header lists what is covered, at minimum the @authority the request is going to, and carries four required parameters: created, expires, a keyid that is the base64url SHA-256 thumbprint of the key, and tag="web-bot-auth". The draft recommends an expiry of no more than 24 hours. Its own Ed25519 test vector looks like this:
Signature-Agent: agent2="https://signature-agent.test"
Signature-Input: sig2=("@authority" "signature-agent";key="agent2")
;created=1735689600;keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U"
;alg="ed25519";expires=4889289600;tag="web-bot-auth"
Signature: sig2=:RdNFx5Bj6au3YgAMQL/RzmUlZE8QZLIaXGRpw985hWnwPfM...==:The server fetches the directory, checks the key thumbprint, verifies the signature over the covered components, and checks the timestamps. If all of that passes, it knows one thing with confidence: this request was signed by whoever controls the keys at that directory. Replaying a captured signature to a different host fails, because the host is in the signed components, and replaying it next week fails because it has expired.
Notice what the signature does not prove. It names the operator, Meta or Amazon or a startup, not the person. It says nothing about whether the customer whose account is about to be used agreed to this purchase. Web Bot Auth answers "which agent," and a store also needs to know "on whose behalf, allowed to do what." That is a second, separate mechanism.
Who the agent is acting for
There are two ways an agent can act for a person at a website. It can become the person, by holding their password and logging in as them. Or it can remain itself and carry a grant from the person, a token that names the agent, the person, and the actions allowed. The first is what browser automation does on a site that offers nothing else. The second is how the enterprise side of the industry has been building agent access this summer.
WorkOS shipped Agent Auth on September 2: you "define blueprints for what an agent is allowed to do, and it gets short-lived, tightly scoped tokens every time it runs," and each token identifies "the agent, the user or org it's acting for, and its own permissions." Sessions can be revoked instantly. On September 22, Browserbase joined Okta's Cross App Access ecosystem, which gives browser agents "dynamic, identity-based tokens that are scoped to exactly what the agent needs for each task, issued in real time through the user's active Okta identity," in place of static keys. Cross App Access is formally the Identity Assertion Authorization Grant, an OAuth extension that MCP has also adopted as an authorization extension.
Those are workforce tools. A consumer storefront's login form does not mint agent tokens, so a consumer agent that wants to buy something from a store that has not built a delegated path has exactly one option: the password. That is why the credential argument is not really about Meta's vault engineering. It is about custody. Whoever holds the password holds the whole account, and the difference shows up the moment something goes wrong.
Same agent, two custody models. Pick an incident and watch each model handle it. The exposure window is computed from the two sliders: how long until someone notices, and how long a delegated token lives.
password in the agent's vault
delegated agent token
Illustrative model. The token row follows the properties WorkOS and Okta describe for their agent tokens (short-lived, scoped, naming the agent and the principal, revocable); the $50 checkout cap is an example scope. Bars share one scale, 30 days.
Every incident in the drill comes out the same way, for the same reason. A password is a bearer credential for the entire account with no expiry and no name of its own, so everything that goes wrong with the agent goes wrong with the customer's whole account, and the only fix is the blunt one. A delegated token is a credential for a slice of the account with a clock and a name on it. The agent's mistakes stay inside the slice, and the store can finally address the agent separately from the person.
Two gates facing opposite directions
Put the two halves together and Muse has one gate and the store has another, and they guard different things. The Sentinel answers "does the user want this?" It sits inside Meta's VM, on Meta's side of the wire. The store's policy answers "does the store accept this?" It sits on the store's side. Neither can see the other. A purchase the Sentinel approved arrives at the store with no trace of that approval, and a store's refusal reaches the Sentinel as nothing more than a failed page load.
An errand of six outbound actions. Each passes the Sentinel first, set by the user, then the store, set by the store. Change the rules on either side and the stamps recompute.
Illustrative errand. The Sentinel's existence and its approve-before-egress role are from Meta's September 8 announcement; its actual rule settings are not public, so the three rules here are examples. "Unaware" means the store accepted the request believing the customer sent it.
The interesting row is the store that opted out. When the agent declares itself there, the store refuses it at the first request and the user learns immediately that this store is off-limits. When the agent stays undeclared, the same store accepts everything and never knows. The design that is safest for the agent's user, a Sentinel checking every outbound step, is compatible with either behavior toward the store. Meta chose which one Muse shows Amazon, and Amazon chose to answer it with a block.
Other stores chose the opposite. Shopify's CEO Tobias Lütke announced on September 21 that Shopify is working with Meta so Muse can do agentic checkout in Shopify stores, which is the "store opted in" button in real life: a declared, negotiated path instead of a scraped one. The law is less settled than the engineering. Amazon sued Perplexity over its Comet browser agent; according to GeekWire, a judge blocked Comet in March 2026 and the Ninth Circuit reversed that decision in August. What a site may demand of an agent is being argued in court. What an agent can prove about itself is a solved piece of HTTP.
What to build
If you build agents that act on the open web:
- Sign your requests. Publish a key directory and send Web Bot Auth signatures. It costs one Ed25519 signature per request and it gives every site the option to say yes to you specifically.
- Prefer grants to passwords. Where a site offers OAuth, an API, or an agent token, use it. Where it offers only a login form, treat stored passwords as the most dangerous thing in your system, and consider stopping to hand the step back to the person instead.
- Treat a refusal as an answer. A declared agent that gets a 403 and then retries undeclared has turned a policy disagreement into an evasion story. The retry is the part that ends up in the press.
- Keep your Sentinel's decisions attributable. An approval log that ties each outbound action to a user decision is what lets you defend a purchase when the store, the bank, or the customer asks.
If you run a site that agents will visit:
- Publish a policy an agent can read, and verify signatures before you run heuristics, so declared agents never land in the bot-detection pile.
- Offer a delegated path. A scoped token for search, cart, and capped checkout is cheaper to support than a permanent detection war, and it lets you revoke one agent without touching the customer.
- Separate "which agent" from "for whom." The signature answers the first; your authorization layer answers the second. Neither substitutes for the other.
Muse is a careful piece of work on the axis Meta optimized for: keeping one person's agent from hurting that person. The Amazon block is what happens when a system with a well-built inward gate meets a counterparty that cannot see it. What closes that gap sits on the wire between them: a name on the request and a grant in place of the password. Both already exist, in an IETF draft and in two identity changelogs from this month.
Keep reading