In 5 seconds
Meta’s Muse is running into websites that block or challenge automated traffic. The ecommerce lesson is bigger than Muse: merchants need a way to distinguish a customer-authorized AI shopper from scraping, abuse, fraud, and unidentified bots.
AI shopping agents have reached a practical problem that ordinary ecommerce websites were never designed to solve.
How does a website know whether automated traffic represents a legitimate customer?
Recent reporting based on Jefferies analysis says Meta’s Muse is being blocked entirely by roughly one-third of tested travel, commerce, and reservation sites, challenged by another third, and allowed through seamlessly by the remaining third.
Amazon has also blocked Muse from its consumer shopping environment.
That does not mean those websites are “anti-AI.”
It means the modern web already has defenses against automated traffic, scraping, credential abuse, fraud, and bots—and a personal shopping agent can look uncomfortably similar to those things when it arrives without a clear identity or supported access path.
The website cannot safely infer intent from automation alone
A merchant may see two automated sessions that look technically similar:
- one is a legitimate AI agent acting at the request of a real customer;
- the other is a scraper collecting prices or content without permission.
Or:
- one agent is trying to check an order for an authenticated customer;
- another is attempting credential abuse.
The business needs more than “this browser is automated.”
It needs context:
Who is the agent? Who authorized it? What is it trying to do? What may it access?
Blocking everything is not a durable commerce strategy
Merchants have legitimate reasons to defend their sites.
But if personal agents become a meaningful shopping channel, blocking every automated visitor can eventually mean blocking customers who chose to shop through an agent.
The opposite extreme is not attractive either.
Blindly allowing every bot because it claims to represent a shopper creates obvious security and abuse risks.
The industry therefore needs something between:
block all automation
and
trust all automation.
This is the problem Poppy is trying to solve
The new draft Personal Agent Protocol, nicknamed Poppy, proposes an explicit way for personal agents to identify themselves and for customers to authenticate and authorize access.
Instead of an agent silently navigating a human interface under the customer’s identity, a business can recognize the agent relationship and give it defined access.
That does not eliminate bot protection.
It gives the merchant a better signal for distinguishing supported agent traffic from unknown automation.
Structured commerce interfaces avoid some of the browser problem
Shopify is moving in this direction too.
Its WebMCP work gives compatible agents structured tools for storefront and checkout interactions instead of forcing them to guess which page element to click.
Shopify is also opening its broader catalog to more AI agents. Read Shopify Is Opening Its Product Catalog to AI Agents. Is Your Store Ready to Be Shopped by Software?
Amazon’s seller-side approach is another version of the same idea. Amazon blocked Muse on the consumer side while offering an approved Selling Partner plugin for seller tools such as Claude. We explained that distinction in Amazon Blocked Meta’s AI Agent. Now It’s Opening Seller Tools to Claude. Here’s the Difference.
The recurring pattern is:
structured, identified, permissioned access is easier to govern than improvised browser access.
Merchants should not try to “beat” their own bot protection
The answer is not to weaken anti-bot controls until every agent can get through.
That creates a different security problem.
Instead, merchants should think in layers.
1. Public product discovery
Decide what public catalog information legitimate agents should be able to discover.
2. Authenticated customer data
Orders, addresses, subscriptions, loyalty data, and support history should require a trustworthy customer-authentication path.
3. Consequential actions
Purchases, cancellations, refunds, account changes, and other writes need explicit authority and often fresh approval.
4. Unknown automation
Traffic with no trustworthy identity or authorization signal can continue to be challenged or blocked according to the merchant’s security policy.
Agent identity does not replace fraud controls
An identified agent can still be compromised. A legitimate customer account can still be taken over. A request can still be malformed or outside normal behavior.
So a trusted agent identity should be one security signal—not a universal bypass.
Normal controls still matter:
- authentication;
- rate limits;
- transaction limits;
- payment verification;
- risk checks;
- approval gates;
- and anomaly detection.
What should an ecommerce operator do today?
Most independent sellers do not need to implement a new protocol tomorrow.
But they can prepare their policy now.
- Decide which public information agents may access. Product facts and policies are different from customer records.
- Separate browsing from authenticated access. Do not let a shopping agent’s public discovery needs become a reason to expose account data.
- Define approval-required actions. An authenticated agent still should not automatically gain unlimited authority.
- Keep unknown automation subject to security controls. Do not disable bot defenses just to accommodate agentic commerce.
- Prefer supported agent interfaces when available. Structured APIs, plugins, protocols, and platform tools are easier to govern than brittle browser impersonation.
- Log agent-mediated actions. You should be able to tell what the agent requested and what the business actually changed.
This changes the meaning of “customer traffic”
Historically, ecommerce analytics treated a session as a person using a browser.
That assumption is weakening.
The customer may still be the economic buyer while software performs much of the discovery and interaction.
That means merchants will increasingly need to distinguish:
- human sessions;
- search crawlers;
- merchant-approved integrations;
- customer-authorized personal agents;
- and unidentified automation.
Those are not all the same thing, even if they produce HTTP requests that look similar at first.
Use the right Nyansa Hub resource for the job
If you need a quick decision about whether an AI agent should be connected to a live system, start with the 12-Point AI Agent Safety Checklist.
If you already have connected automation and need to review control gaps, use the Ecommerce Automation Safety Audit.
For recurring agent access, permissions, approvals, monitoring, and recovery, use the Safe Ecommerce Automation Toolkit. If you are implementing the controls technically, use the Safe Ecommerce Automation Coding Build Kit.
The bigger lesson
Muse’s blocking problem is not just a Meta problem.
It is evidence that the human web and the agentic web are colliding.
Merchants need bot defenses. Customers increasingly want agents. Both can be true.
The long-term solution is likely to be better identity and explicit authorization—not making agents better at disguising themselves as humans.
Sources and context: Investors Business Daily’s October 2026 reporting on Jefferies analysis of Muse access across travel, commerce, and reservation websites; Amazon’s earlier decision to block Muse; Sierra’s Personal Agent Protocol draft; and Shopify’s structured agent-commerce work. The one-third blocking/challenge/allow figures are analyst findings reported by IBD, not a universal measurement of the web.