Meta’s Muse is exposing a new problem for the web: AI agents are increasingly acting as customers, but businesses may not know when automated traffic is legitimately representing a real person. Muse is one of a growing class of personal AI agents that can browse websites and carry out tasks on users’ behalf. On October 7, Cequence Security said it found traffic matching Muse at more than half of the customers it studied within two weeks of the agent’s September 8 launch—and said Muse did not identify itself as an AI agent, making its activity look like ordinary browser traffic to standard security tools.

That creates a difficult decision for businesses. Companies that simply block automated traffic may increasingly block legitimate customers using AI agents, while companies that accept agents without adequate identification and controls face security, privacy and fraud risks. Businesses therefore need to distinguish humans, authorized AI agents and other automated traffic because each may warrant different access, permissions and security controls.

A customer authorizing an AI agent to act for them and a business agreeing to interact with that agent are separate permission decisions. Amazon made that conflict explicit when it blocked Muse from shopping on Amazon.com in September, arguing that outside agents should identify themselves and that businesses should be able to decide whether and how those agents interact with their services.

That’s why the industry is now trying to build infrastructure for that new relationship. Visa has developed its Trusted Agent Protocol for agentic commerce, while Meta and Sierra are developing the broader Personal Agent Protocol to help businesses authenticate personal agents and determine what they may do. But no universal trust layer yet governs AI agents across the open web. And yet, businesses need more than simple bot detection. They need a trust layer that can establish which agent is present, whom it represents, what the customer authorized, what the business permits and whether a particular action should proceed.

Meta Muse shows that AI agents are creating a new category of web traffic: automated systems that can legitimately represent real customers but may not be recognizable to the businesses they interact with.

Muse began showing up across Cequence Security customers soon after launch, but it did not arrive with a clear signal telling those businesses that the visitor was an AI agent. Cequence said that within two weeks of Muse’s September 8 launch, it had detected traffic matching the agent at more than half of the customers it studied. Its analysis covered traffic from September 1 through September 24 across financial services, retail, travel, software and other sectors. Cequence said the volume of traffic it attributed to Muse grew quickly after the agent first appeared. For a typical site in its study, that Muse-attributed traffic was nearly six times higher about two weeks later.

That traffic was difficult to recognize in part because of how Muse reaches websites. Cequence says each Muse user gets their own agent, which operates through a real Chrome browser running in the cloud and routes its traffic through a consumer VPN. Muse does not sign its requests or identify itself as an AI agent, which made it difficult for websites to tell whether the Chrome browser was being used by a person or an AI agent.

Because Muse does not identify itself directly, Cequence looked for technical patterns that could distinguish its traffic from ordinary Chrome users. One clue was a Chrome version that went from appearing in none of the identified Muse traffic to more than 90% of it within days. Cequence said that synchronized change was consistent with the browsers being centrally managed, illustrating the kind of indirect clue businesses may need when an agent does not clearly identify itself.

And the browser is not the only signal that can make an agent look like a human customer. At financial institutions, Cequence said Muse successfully logged into customer accounts and completed multi-factor authentication on users’ behalf. That means signals businesses have traditionally associated with a verified human customer—including a successful MFA login—may no longer reveal whether the person is actively navigating the account or has authorized an AI agent to do it for them.

Shopping behavior creates a similar problem. Cequence observed Muse searching for products, comparing options, filling carts and moving through checkout. Most of those sessions browsed and left without completing a purchase—a pattern businesses have historically associated with bots. But an AI agent researching options for a real customer can behave the same way. Automated behavior and legitimate customer behavior are no longer necessarily opposites.

Together, those examples show why businesses can no longer rely on a simple human-versus-bot test. A real Chrome browser does not necessarily mean a human is using it. A successful MFA login does not necessarily mean that person is personally operating the account. And browsing without buying does not necessarily mean unwanted automation. Businesses increasingly need to distinguish among human visitors, authorized AI agents, ordinary automated traffic and malicious activity because each may warrant different access, permissions and security controls.

There is an important limitation to Cequence’s findings: they come from the company’s own customer traffic analysis and were released alongside the launch of its Agent Trust security product. The numbers therefore describe what Cequence observed across the customers it studied, not the prevalence of Muse or AI agents across the entire web. They do, however, show that traffic Cequence attributed to Muse appeared across many of the businesses it studied and grew quickly after it arrived.

Recognizing that an agent is present, however, only answers the first question. Businesses also need to know whether the customer actually authorized that agent—and what authority the customer gave it.

Muse is not simply an autonomous program roaming the web on its own. Meta launched it on September 8 as a personal AI agent designed to take actions on a user’s behalf. A person can ask Muse to open websites, fill out forms, negotiate, send emails, book travel or make purchases, and the agent can continue working after the user closes the app.

But giving an AI agent that much authority also creates obvious security questions. Meta’s answer is to put several controls between the agent and the outside world. Each Muse runs inside a dedicated virtual machine in the cloud with its own browser. A separate Sentinel agent, isolated from Muse at the system level, reviews what Muse attempts to send to the internet and requests the user’s permission when required. Meta also says Muse cannot directly see the passwords or payment methods connected to it. Those credentials are stored separately so the agent can use them without viewing the underlying information.

The user also retains control over what Muse is allowed to do. Meta says Muse checks with the person before sensitive actions such as sending an email or making a purchase and provides an audit trail showing what it has already done and what it plans to do. Users choose which services Muse can connect to and can set different levels of access—for example, allowing it to read email without giving it permission to send messages. That access can later be changed or revoked entirely.

Stripe extends that authorization model into shopping. U.S. consumers can connect their Link accounts to Muse, allowing the agent to check out at more than one million businesses that accept Link using a payment method the consumer has already saved. When a business does not accept Link directly, Stripe can instead issue Muse a single-use virtual card limited to the approved purchase. For every purchase, Stripe says the consumer must approve the transaction total in the chat, while Muse never receives the person’s underlying payment details.

Those protections do not eliminate every risk associated with allowing an AI agent to act for someone. They do, however, establish an important distinction. Automated does not necessarily mean unauthorized. In many Muse interactions, the customer may have deliberately connected the relevant account, granted the agent access and approved the sensitive action it is attempting to complete.

That is also why simply detecting automation is no longer enough. If a business discovers that software rather than a person is operating the browser, it still needs to determine whether that software is legitimately representing one of its customers. A business cannot simply block all automation, but it also cannot safely let every agent in. Identification has to help businesses distinguish customer-authorized representatives from automation they do not want or trust.

But customer authorization answers only half of the permission question. A person can give Muse permission to act on their behalf, including asking it to visit a website, access an account or make a purchase. That authorization does not require the business on the other side to accept the agent or allow it to take those actions through its systems. The business gets a separate decision—and Amazon made that distinction explicit when it blocked Muse.

Amazon’s response to Muse shows why customer authorization cannot settle the entire relationship. Amazon had already taken the position in March 2026 that third-party AI agents should identify themselves and respect a business’s decision about whether they may access its services. When Muse began shopping on Amazon.com, Amazon said Meta had not asked permission for the agent to access the site and Muse did not identify itself while browsing. Amazon said it then tried unsuccessfully to get Meta to voluntarily exclude Amazon from the Muse experience before blocking the agent on September 20.

That became more consequential when Muse entered a customer’s Amazon account. Amazon said that, when directed by a user, Muse could reach account pages and order histories. Because Amazon could not tell that an outside AI agent was operating within the account, the company argued that it could be handling transactions and sensitive customer information without Amazon’s knowledge or consent. For Amazon, that creates a security problem as well as a permission problem: the company still has to protect customer accounts from unauthorized access, fraudulent purchases and misuse, even when an automated system appears to be acting through a legitimate customer login.

The disagreement therefore was not necessarily about whether the customer wanted Muse there. As the previous section established, a customer may have deliberately instructed Muse to shop, connected the necessary accounts and approved the purchase. Amazon’s position was that customer permission did not also give Meta permission to send its agent through Amazon’s systems.

Amazon’s own approach to agentic shopping adds useful context. Its Buy for Me feature also sends an AI agent to outside merchants to make purchases on a customer’s behalf. But Amazon says that agent identifies itself and allows participating brands to opt out. That makes Amazon’s stated objection to Muse more specific than opposition to AI-assisted shopping itself: the business should know that an agent is present and retain a choice about whether to interact with it.

This creates two separate permission decisions. The customer can say, “I authorize this agent to act for me.” The business can independently say, “We will—or will not—allow that agent to act through our systems.” User authorization establishes the relationship between the person and the agent; it does not automatically establish the terms of the relationship between the agent and every business it reaches.

Amazon chose to block Muse deliberately. But that is only one side of the emerging problem. Some businesses actually want customers to reach them through AI agents—and their existing anti-bot systems can still get in the way.

Amazon deliberately decided that Muse should not access its site. But other businesses are running into the opposite problem: they want customers to use AI agents, while security systems built to stop bots can prevent those agents from getting through.

Walmart provides one of the clearest examples. The retailer is a Muse partner and told TechCrunch that it wants to be available wherever its customers choose to interact, including through AI-agent experiences. Yet Walmart’s human-verification systems have still interfered with some Muse sessions. TechCrunch reported that Walmart can present a button requiring the visitor to verify that it is human; if that verification experience is interrupted, the check can fail and the agent can be removed from the site before completing the purchase. Those systems can evaluate more than whether the visitor successfully clicks a button. Bot-detection technologies may also analyze behavioral signals such as mouse movement and other interaction patterns, which can differ when software rather than a person is controlling the browser. The result is an unusual mismatch: Walmart wants customers to reach it through AI agents, while security infrastructure designed to distinguish humans from automated traffic can still prevent those agents from completing the task.

That problem extends beyond retail. Travel booking is one of the tasks personal AI agents are being promoted to handle because comparing routes, schedules, prices and other options can require significant time and repetitive work. But airlines are also deciding how, or whether, outside agents should interact with their systems.

Delta told TechCrunch that it currently has no partnership or integration that allows third-party AI agents to shop for or book Delta flights on customers’ behalf through its digital platforms. The airline said it is continuing to evaluate external AI agents and would approach any future access with security and the customer experience in mind. United, meanwhile, pointed TechCrunch to terms prohibiting automated access for unauthorized purposes without prior written permission, although the airline did not confirm whether it was specifically blocking Muse.

Those different responses show why the traditional human-versus-bot model is becoming less useful. A business may encounter a human customer, an authorized agent representing that customer, unwanted automated traffic or malicious automation. Treating everything that is not human as the same category risks blocking activity the business actually wants, while treating every customer-authorized agent as trusted would remove controls businesses may still need.

The question therefore is no longer simply whether a website allows bots. For businesses that want to serve customers through AI agents, it becomes: How do we recognize an authorized software representative, distinguish it from other automation and give it the appropriate level of access?

The industry had begun working on that problem even before Muse appeared. In 2025, Visa introduced a protocol designed in part to help legitimate AI agents identify themselves to merchants rather than being mistaken for unwanted bots.

The difficulty businesses are now having with Muse was not entirely unexpected. Nearly a year before Muse launched, Visa was already working on a way for legitimate AI agents to identify themselves to merchants instead of being mistaken for unwanted bots. Visa introduced its Trusted Agent Protocol on October 14, 2025, developed with Cloudflare, specifically as infrastructure for agentic commerce.

The protocol is designed for a situation much like the one businesses are beginning to face now: an AI agent arrives at a merchant that may not already know or recognize it. Rather than forcing the merchant to infer what the visitor is from browser behavior alone, the agent can send cryptographically signed credentials with its requests. In practical terms, those signatures give the merchant a way to verify that the agent is participating in an approved program and that the request has not been altered along the way.

Visa’s protocol can communicate more than the agent’s identity. It can indicate that the agent has a legitimate commerce purpose, such as gathering product information or attempting a purchase. It can also include information that helps the merchant determine whether it recognizes the consumer the agent represents. That begins to answer two questions businesses could not answer from Muse’s ordinary browser traffic alone: What agent is this, and whose customer is it acting for?

Importantly, successful identification does not require the merchant to accept everything the agent wants to do. Visa’s specification says merchants can use those signals to control, limit or supplement the interaction. A verified identity therefore gives the business more information for making an access decision; it does not remove the business’s ability to make that decision.

But Trusted Agent Protocol also illustrates why creating an agent identity system is not the same as creating a universal identity layer for the web. Adoption is voluntary. Visa’s specification explicitly says merchants that have not adopted the mechanism can simply ignore the agent’s signatures. And Visa said its initial specifications apply to the Visa network rather than the web as a whole.

Visa itself acknowledges that limitation. The company says safe agentic commerce will require a broader, ecosystem-wide approach and is working with standards organizations and other commerce protocols on interoperability. An agent can therefore have a technically valid way to identify itself without every business on the internet necessarily recognizing or accepting that identity.

Muse did not create this problem; it made the problem easier to see in real-world use. Visa had already anticipated that legitimate automated shoppers could be mistaken for malicious bots. What Muse adds is evidence that businesses are now encountering that distinction in practice.

And identification is only part of the problem. Even after a business knows which agent has arrived and which customer it represents, it still needs to know what the customer authorized and what the business itself will allow. That is the broader relationship Meta and Sierra are now trying to address with the Personal Agent Protocol.

Visa’s Trusted Agent Protocol helps address the identity problem in commerce. But businesses also need a way to determine what an identified agent is actually allowed to do. On October 6, Meta and Sierra announced that they are developing Personal Agent Protocol, or PAP, with partners including Genesys, Instinct, Rocket, Shopify, Stripe and Walmart. The proposed open standard is intended to help businesses recognize personal agents, understand whom they represent and decide how those agents may interact with their systems.

The central idea separates the two permission decisions that surfaced in the Amazon dispute. Consumers decide what access to give their personal agents, while businesses set the boundaries for what those agents can do on their side. In other words, a customer may authorize an agent to represent them without automatically giving that agent unrestricted access to every business it reaches.

Those permissions do not have to be all or nothing. Under Sierra’s description of PAP, an agent could initially interact with a business as a guest—for example, checking whether a product is available or asking about a return policy. If the task later requires access to the customer’s account, the person could sign in through the business or use credentials already configured with the personal agent. The customer could then grant the agent read-only access, such as viewing information in the account, or write access that allows it to make changes.

That creates different levels of access within the same interaction. An agent might be able to check inventory or ask about a return policy without the business knowing which customer it represents. If the agent then needs to view that customer’s order, the business would need to authenticate the customer and recognize that the agent is authorized to act for them. Changing or canceling the order could require an additional level of permission. The amount of access can therefore increase as the task becomes more sensitive.

The business also decides how it wants agents to interact with its systems. Sierra says a company could allow personal agents to use its regular website, connect through APIs or communicate with an AI agent operated by the business itself.

PAP is designed to keep that relationship connected as the interaction changes. Sierra says sessions would use OAuth-based authorization, a common method that lets one service receive limited permission to interact with another without requiring the user to hand over their password. The authorization could persist across different parts of the interaction, allowing an agent to begin with a general question, later authenticate to the customer’s account and continue the task without starting over.

But PAP is still a proposal rather than a finished standard. Sierra plans to publish the v0.1 specification later in October, followed by design workshops and a reference implementation. Some of the more detailed capabilities are also still planned for future versions. Sierra says those could include more specific controls over individual actions and business-to-agent push notifications, allowing a company to proactively tell an agent, for example, that a customer’s flight was delayed or an order had shipped. Future versions could also support payment extensions that allow an agent to complete purchases without sharing the customer’s card information.

PAP therefore expands the problem beyond simply identifying whether an AI agent is present. A business increasingly needs to answer several separate questions: Which agent is this? Whom does it represent? What did the customer authorize? What will the business permit? PAP is being designed to help establish that relationship, but the standard and some of its most granular controls are still being developed.

And even if those questions can eventually be answered reliably, one more remains. A legitimate agent with valid permission can still make a request that a business should not accept.

Knowing which AI agent has arrived, whom it represents and what permissions it has is an important part of establishing trust. But those answers still do not mean that every request from that agent should automatically be allowed.

One reason is that a legitimate agent’s credentials can potentially be stolen and reused by someone else. Cequence says traffic from a real agent can look similar to traffic from an attacker replaying a stolen agent credential. A business therefore cannot rely on identity alone to determine whether every request actually came from the trusted agent or whether the request fits its normal behavior.

Cequence argues that businesses need to combine agent identity with behavioral monitoring. Its Agent Trust system keeps a request-by-request record of what an agent does and builds a behavioral profile intended to distinguish the legitimate agent from an impostor using stolen credentials. That adds another question to the trust decision: Does this particular request make sense for this agent and this interaction?

The business can then respond to the individual action instead of making an all-or-nothing decision about the agent. Cequence says its system can block, rate-limit or challenge a specific request while continuing to allow the agent itself to operate. It gives the example of an agent that normally checks a customer’s order status suddenly beginning to pull pricing and inventory information for every product. The business could stop that scraping behavior without preventing the agent from continuing other legitimate work for its customer.

Cequence said one of its travel and hospitality customers used that kind of request-level control with Muse in late September. The customer’s security team blocked nearly one in five Muse requests that it considered abnormal while continuing to allow Muse itself and the remainder of its traffic through. The example comes from Cequence’s own customer analysis, but it shows what action-level controls are intended to accomplish: accepting an authorized agent does not require a business to accept everything that agent attempts to do.

Those controls add another layer to the trust decision. Identity asks whether this is really the agent it claims to be. Representation asks whom it is acting for. Customer authorization establishes what that person permitted. Business permission determines what the company will allow. Action-level trust asks whether this specific request should proceed.

Even a recognized agent acting for an authorized customer may make a request that the business considers abnormal, outside its permitted scope or otherwise unacceptable. Businesses are therefore confronting personal AI agents before the infrastructure for identifying, authorizing and governing them has fully standardized.

Customer-authorized AI agents are changing what automated web traffic represents. Most consumers may never care which identity protocol or authorization system makes an AI agent work. They will care when an agent they authorized cannot complete a purchase, access an account or book a trip—or when software is allowed to do something they did not intend. For businesses, the immediate challenge is deciding which automated visitors legitimately represent customers and what those agents should be allowed to do.

Those decisions cannot realistically depend on people reviewing agent activity one request at a time. AI agents can operate continuously and move through websites far faster than a human security team could evaluate each interaction. Businesses will therefore need machine-readable identity, authorization and behavioral signals tied to automated policies that determine what an agent can access, what actions it can take and when a request should be challenged or blocked.

Parts of that system are already emerging, but they do not yet form one universal trust layer. Visa is developing a way for merchants to recognize trusted commerce agents, PAP is being designed around consumer and business permissions, and security systems can evaluate individual agent behavior. Until those approaches become more interoperable and widely adopted, businesses may have to combine different tools and policies while deciding how much agent traffic they are willing to accept.

That makes agent identity necessary infrastructure, but not the final answer. Businesses ultimately need systems capable of recognizing who the agent is, whom it represents, what authority it has and whether the action it is attempting should proceed—without requiring a person to make that decision every time.

If AI agents are going to operate at machine speed, the trust systems governing them will have to operate at machine speed too.

Q: What problem is Meta Muse exposing for websites?
A: Meta Muse shows that automated web traffic can now legitimately represent a real customer. Because an AI agent may browse through a normal browser, log into accounts and complete tasks with the customer’s permission, businesses can no longer assume that automated activity is unwanted or malicious. They increasingly need to distinguish authorized customer agents from ordinary bots and harmful automation.

Q: Why did Amazon block Meta Muse?
A: Amazon blocked Muse because it said Muse did not identify itself as an AI agent and Meta had not received Amazon’s permission for the agent to access its services. Amazon had already established rules requiring third-party agents to identify themselves and respect its access decisions. The dispute showed that a customer can authorize an AI agent to act for them while the business can separately decide whether it will allow that agent to use its systems.

Q: Can websites accidentally block legitimate AI agents?
A: Yes. Anti-bot and human-verification systems can interfere with AI agents even when a business wants those agents as a customer channel. Walmart, a Muse partner, has had human-verification systems interrupt some Muse sessions. The problem is that security tools designed to separate humans from bots may still classify an authorized AI agent as automation that should be challenged or blocked.

Q: How can businesses tell a legitimate AI agent from an ordinary bot?
A: Businesses increasingly need machine-readable signals that identify the agent, show whom it represents and establish what authority it has. Behavioral monitoring can add another layer by evaluating whether individual requests match the expected activity of that agent. No single system currently provides all of those capabilities across the open web.

Q: What is Visa’s Trusted Agent Protocol?
A: Visa’s Trusted Agent Protocol is a system designed to help merchants recognize legitimate AI agents involved in commerce instead of mistaking them for unwanted bots. It uses signed credentials that can identify approved agents, communicate commerce intent and help merchants recognize the customer an agent represents. Adoption is voluntary, however, and the protocol is not a universal web standard.

Q: What is Personal Agent Protocol, or PAP?
A: Personal Agent Protocol is an emerging standard being developed by Meta and Sierra to help businesses authenticate personal AI agents and manage permissions between the customer, agent and business. Its central idea is that customers decide what access to give their agents while businesses separately decide what those agents may do on their systems. The first specification is still under development.

Q: Why isn’t identifying an AI agent enough?
A: Knowing an agent’s identity does not mean every request from that agent should automatically be trusted. Credentials can potentially be stolen, an authorized agent can behave unexpectedly, or a particular action may fall outside what the customer or business intended to permit. Businesses therefore also need authorization, business-side permissions and controls that can challenge or block individual actions.

Q: What should businesses do while AI agent standards are still developing?
A: Businesses may need to combine agent-identification methods, authorization controls, behavioral monitoring and their own access policies while broader standards remain fragmented. Those decisions will also need to become increasingly automated because AI agents can operate continuously and generate requests faster than human teams can review them individually. If agents operate at machine speed, the systems deciding whether to trust them will need to operate at machine speed too.

Editor’s Note: This article was created by Alicia Shapiro, CMO of AiNews.com, with writing support, AEO/GEO/SEO optimization, image concept development, and editorial structuring support from ChatGPT, an AI assistant. All final editorial decisions, perspectives, and publishing choices were made by Alicia Shapiro.