Amazon Blocks Meta's Muse Shopping Agent: The Identity Gap

Amazon has blocked Meta's Muse AI shopping agent from shopping on Amazon.com on customers' behalf. The phrase in its error message that caught my attention was “unauthorized AI agent.”

GeekWire reported the block on September 20, 2026. Amazon's warning identifies the agent as unauthorized and cites its Conditions of Use. A shopper may have asked Muse to make a purchase, but Amazon is rejecting the software carrying out that request.

An assistant can understand the task, find the right product, and follow the customer's instructions, then discover that the platform will not let it proceed. Improving the model does not resolve that refusal.

This is one reason we are building Mailrun Agent Identities for the communication side of this problem: email addresses and phone numbers for AI agents, controlled by your company.

Why Did Amazon Block Meta's Muse AI Agent?

According to GeekWire, Amazon says Meta did not disclose that Muse would access its store, the agent did not identify itself while browsing, and its handling of customer credentials raised privacy and security concerns. Amazon had asked Meta to remove Amazon from the experience before imposing the block.

In its Muse launch announcement, Meta says the agent asks for approval before sensitive actions and uses credentials held in secure storage without seeing them.

The disagreement exposes two separate permissions: the customer's instruction to act and the platform's acceptance of the agent doing the work. Muse could satisfy the shopper's instructions and still fail Amazon's requirements.

AI Agent Identity and Authorization Are Different Problems

An identity answers who is acting. Authorization determines what that actor is allowed to do in a particular system.

A recognizable agent identity gives a platform something it can evaluate. Amazon could know exactly which agent is making a request and still refuse access. A platform's willingness to participate also depends on its business interests; identity alone cannot settle that disagreement.

For agentic commerce to become dependable, businesses need to establish who operates an agent, whose instructions it is following, which actions are permitted, and how that permission can be withdrawn.

Consider a shopping assistant asked to reorder office supplies. Comparing prices, reading order history, and spending company money are different activities. A useful authorization system should be able to allow one without automatically allowing all three.

The same issue follows AI agents into customer support, scheduling, and email. Giving software a task does not settle which accounts it should use or how much authority it should have.

AI Email Agents Need a Business Identity

We encounter the communication side of this problem in email. An agent handling a business conversation needs an address people can reply to, a company responsible for that address, and a way to continue the conversation after the first message.

When an agent works through a company-controlled Microsoft 365 mailbox, the business has an account it can administer. That is a useful starting point for accountability, although it does not prove that every message is wanted or every action is authorized.

The account and permissions behind the message matter. Legitimate business email also travels through APIs, including Microsoft Graph. A real mailbox does not guarantee inbox placement, and using an API does not make a message spam.

For an AI email agent, I want to know: Which identity does it use? Who controls access? Where do replies go? What happens to that address when we change the model running the agent?

What We Are Building With Mailrun Agent Identities

We are building Mailrun Agent Identities to give your AI agent its own email address and phone number, with access your company controls through an API or the Model Context Protocol (MCP).

You bring the agent, its business knowledge, and its workflow. The communication identity stays with your business when you change the agent or model behind it.

For example, a customer inquiry agent could receive a question, send its answer, and retrieve a follow-up through the same identity. Mailrun carries the email and replies; your agent decides what to say. Replacing the underlying model should not mean asking customers to start over with a new contact.

A Mailrun identity does not grant access to Amazon or any other platform; each service still decides what it permits. Our focus is a persistent way for your agent to communicate while your business controls the workflow and approvals.

What Amazon Blocking Meta Means for Agent Adoption

The dispute between Amazon and Meta is a visible example of a problem businesses will encounter as they give agents more responsibility. A working demonstration can still depend on access that another company has never agreed to support.

I expect identity and authorization to determine which agents businesses can depend on over the next few years. Better reasoning will help an agent choose what to do. It will still need permission to carry out the decision and a business willing to take responsibility for it.

At Mailrun, we are starting with a place customers can reach your agent again: the same email address or phone number, even when you change the software behind it.

Request Access to Mailrun Agent Identities. Access is coming soon. Tell us which workflow you want your agent to handle.