Within a day of each other, two companies took two paths to handling personal agents.
On September 20, two weeks after Meta released Muse, Amazon blocked the agent from its website.¹ The next morning, Shopify CEO Tobi Lütke announced that Muse could check out through Shop Pay at every Shopify store.
Amazon took issue with Muse’s mannerisms. Meta never told Amazon the agent was coming, and Muse browses without giving its name, so Amazon saw what looked like a signed-in customer racing to checkout faster than any person could.
Shopify, on the other hand, has been working with Meta since Muse launched. Under their new deal, Muse checks out through Shop Pay, where merchants can see when an agent is buying, and Shopify gets the payment volume.
Apptopia estimates Muse drew 1.8 million iOS downloads in its first 12 days in the US and Canada, ahead of ChatGPT’s 1.3 million at launch.² Meanwhile, Instinct CEO Noah Shinn says his startup is approaching $1 billion in annual transactions, about half of it travel.³
As those numbers climb, more merchants will face the same call, and Sardine’s customers have already started asking how to handle agent transactions. Whichever way they go, fraud teams need to know which agent is on the site and who sent it, since a fraudster with stolen credentials can send a perfectly real agent shopping on someone else’s account.
Key takeaways
- A personal AI agent shops with its owner’s credentials. A fraudster with a stolen credential can send a perfectly functional agent shopping on their behalf, and the transaction looks legitimate at every layer.
- Cloud agents like Meta Muse arrive from data center infrastructure far from the customer who sent them, while local agents run on the customer’s own device and network. The two present very different fraud signals and require different detection logic.
- Blocking all agent traffic costs legitimate sales. Allowing all agent traffic opens the door to AI agent prompt injection fraud, account takeover, and payout fraud. Neither blanket approach works for merchants who want agent volume without agent risk.
- Sardine evaluates each agent session across three dimensions. It asks whether software is driving the session and which agent it is, whether the agent matches the account’s known history, and whether what the agent is attempting falls within the account’s normal behavior.
- The Visa Trusted Agent Protocol gives agents a way to sign their requests and identify themselves to merchants, but a signed request identifies who built the agent, not who sent it. Merchants still need to verify the owner and evaluate what the agent is doing.
What a personal AI agent looks like from the merchant’s side
A personal agent shops the way its owner would. It logs in with the customer’s credentials and clicks through product pages until it finds what it was sent for, then checks out like any returning shopper.
Merchants see different things depending on where the agent runs. Muse and OpenAI’s ChatGPT agent drive browsers on their makers’ servers, and Meta gives every Muse user an isolated cloud machine running an up-to-date Chromium browser.⁴
Perplexity’s Comet, an AI browser, runs on the customer’s own computer instead. A cloud agent’s session comes from a data center miles from the customer who asked for it, while a local agent’s session comes from the customer’s usual device and network, which makes it look even more like the customer, because in a sense it is.
Either way, the agent leaves traces. Cloud agents tend to arrive from the same data centers alongside near-identical sessions, and agents of both kinds programmatically move through pages in ways that no person would. Signals like those let Sardine catch automated sessions, including agents like Muse and Instinct, even when their traffic passes for an ordinary shopper.
Cloud agent Muse, ChatGPT agent | Local agent Perplexity’s Comet | |
Where it runs | A browser on the maker’s servers. Muse gives each user an isolated cloud machine. | An AI browser on the customer’s own computer. |
Where the session comes from | A data center, miles from the customer who asked for it. | The customer’s usual device and network. |
What it looks like | A session that never shows the customer’s own device. | Even more like the customer, because in a sense it is. |
Traces it leaves | The same data centers, near-identical sessions, and page movement no person would make. | Page movement no person would make. |
Why allow-or-block stops working for agents
Blocking every agent is the simplest fix. Amazon stops any attacker using Muse, and it also turns away every customer who sent Muse there to buy something. While a company as large and diversified as Amazon can afford to take the short-term hit, other companies can’t simply give a blanket “no.”
Those companies can’t wave every agent through either. If an attacker uses prompt injection, they can plant instructions on a page the agent reads while shopping, telling it to change the account’s shipping address before checkout. The merchant ships the order to the attacker, and when the real customer disputes the charge, the merchant eats the chargeback.
Neither extreme suits a merchant that wants agent sales without the fraud that can ride along. That merchant needs to judge each agent session on who’s behind it and what it’s doing, and Sardine breaks that judgment into three questions.
How Sardine detects personal AI agents and decides how far to trust them
AI agent traffic detection and AI agent session verification
First, Sardine works out whether software is driving the session and, where it can, which agent it is. Sardine’s bot detection looks for behavioral patterns common to AI agents, distinctive technical fingerprints, implementation characteristics, and geographic signals. Agents that announce themselves make the job easy. OpenAI’s ChatGPT agent signs its requests, so Sardine can name it from its headers alone. For agents that don’t sign, Sardine relies on those other signals.
Verifying the customer behind the AI agent
An agent’s name says nothing about who sent it, so Sardine checks the agent against the account it’s using. Account history counts for even more with cloud agents, where the customer can disappear behind the agent entirely. A customer who takes over a cloud agent’s browser to type in a card number is still working on the agent’s machine, so the session never shows their own device.
When Sardine has watched the same agent on the same account and device for months, the customer is probably the one sending it on errands. Sardine flags a first-time agent from unfamiliar infrastructure, arriving right after a password reset, for a closer look. That sequence looks like someone changed the locks and let themselves in.
Checking what the AI agent is trying to do
Even a customer’s own agent can try something the customer never would, so Sardine weighs what the agent is attempting. People hand agents chores like a weekly grocery reorder all the time. Few would send one to change a payout account or wire $50,000, and Sardine treats requests like those as red flags.
Each business draws that line for itself. A grocery app and a crypto exchange will trust agents with very different jobs, and each one can write its own limits into Sardine’s rules engine. A merchant can pair the agent’s name with the account’s history, for example, and let a known agent on a familiar account through checkout without treating it like any other bot.

Setting your own terms for agent traffic
Today’s agents get around the web the hard way. Developers built websites for people, so Muse and its peers click through product pages and fill in checkout forms just like a shopper would. Visa is betting that won’t last. In October 2025, it released the Trusted Agent Protocol with Cloudflare, which lets approved agents sign their requests so merchants can verify who’s knocking.⁵
Once more agents sign their traffic, merchants will have an easier time telling which agent showed up. A signature identifies who built the agent and says nothing about whose errand it’s running, so merchants still have to decide which agents they’ll accept and what those agents may do. A travel site, for example, might let agents book and rebook flights while asking the customer to confirm any change to a loyalty account.
A merchant that can tell a customer’s long-standing agent from a stranger can approve the familiar agent’s purchases outright and save its review queue for the sessions that look like a break-in.
Personal agents will keep logging in with their owners’ passwords, and more of them will start introducing themselves along the way. The merchants who can tell which owner sent each one will get the sales and leave the account takeovers at the door.
To dive deeper into how fraud teams can manage agent-driven transactions as a distinct channel, read Rethinking Fraud Prevention for Agentic Commerce. If you want to talk through how Sardine’s detection and rules engine handles agent sessions on your platform specifically, reach out to the team.
Frequently asked questions
What is a personal AI agent in the context of commerce?
A personal AI agent is software that shops, books, or transacts on behalf of a specific user. It uses that user’s credentials and acts on their instructions. Examples include Meta’s Muse and OpenAI’s ChatGPT shopping agent. From the merchant’s perspective, the agent logs in, navigates pages, and checks out the way the account holder normally would, but the session is driven by software rather than a person sitting at a screen.
What is the difference between a cloud AI agent and a local AI agent?
A cloud AI agent runs on the agent maker’s servers, meaning the IP address and device fingerprint come from a data center that has nothing to do with the customer’s home or phone. A local AI agent runs on the customer’s own device and arrives from their usual network and hardware, which makes it look far more like the customer. Cloud agents tend to show data center provenance and near-identical session patterns, while local agents blend into normal customer traffic. That distinction changes how you read the fraud signals.
What is AI agent prompt injection fraud?
Prompt injection fraud is when an attacker embeds hidden instructions on a web page that an AI agent reads while browsing. The agent follows those instructions instead of the customer’s original request. In a commerce context, this can redirect a shipping address before checkout, change a payout account, or trigger other actions the real customer never authorized. The merchant ships the order to the attacker and the real customer disputes the charge.
How does an AI agent session differ from a normal bot attack?
A normal bot attack is automated abuse with no legitimate user behind it. Credential stuffing, card testing, and scraping are typical examples. A personal AI agent is automation with a legitimate user behind it, operating on that user’s real account with their real credentials. Blanket bot blocking catches both and costs the merchant legitimate sales. Effective AI agent session verification separates sessions with a real owner from sessions that are either unauthorized or being abused.
What should merchants flag as high-risk AI agent activity?
High-risk signals include an agent arriving from unfamiliar infrastructure on a first-time session immediately after a password reset, an agent attempting to change a payout account or initiate a high-value wire, an agent navigating directly to sensitive account settings without following the usual browsing path, and an agent on an account that has no prior history of agent activity. Each business draws its own line. A grocery app and a crypto exchange will define acceptable agent behavior very differently.




