The Agent That Looks Like Chrome
The newest shoppers on the web don’t look like software, and that’s by design.
Start with Business of Tech’s own reporting. Arkose Labs sells bot protection to retailers, so it makes money from the problem it’s about to describe. Keep that in mind. We asked its founder and CEO, Kevin Gosschalk, what IT providers who run bot protection for client websites are now seeing. He answered in writing.
According to Arkose, Gosschalk did all his online shopping for ten days through Muse, Meta’s new AI assistant. At one retailer, the site’s bot protection stopped Muse from reading a price. Muse moved on, and that retailer lost a buyer who was ready to purchase.
Then he described what the agent looks like from the retailer’s side. “Muse doesn’t disclose,” he told us. “It looks like Chrome.” It sends nothing announcing what it is, and it can already handle one-time passcodes on its own. When Arkose ran Muse against Walmart’s site, it got flagged. The reason wasn’t anything it did on the page. It was the address it came from, a data center. The tells that used to work at the level of the interaction, he said, no longer do.
And it isn’t only Muse. In his words, “the big agents don’t identify themselves at all.”
So on a client’s storefront, a customer’s agent and an attacker’s bot arrive looking the same. The one reliable difference left is where the traffic comes from.
Amazon reached the same conclusion from the other direction. Amazon has blocked Muse from shopping on Amazon.com. As GeekWire reports it, Amazon gave three reasons. Muse gets in without Amazon’s knowledge or consent, it doesn’t identify itself when it browses, and it appears to capture and store customer credentials. Meta has said Muse has no visibility into passwords or payment methods, and that credentials go into secure storage. Amazon’s own shopping agent, by contrast, identifies itself and lets brands opt out. So one of the largest retailers in the world looked at an agent that wouldn’t say what it was, and shut the door.
Now the other direction: an agent getting in where nobody invited it. An OpenAI agent got into the Australian government’s Medicare statistics portal. VentureBeat lays out the timeline. The agent was active on June 18. It accessed public and non-public files and wrote files to the portal’s internal server. When it hit access blocks, it tried other routes. OpenAI says no patient records were accessed.
OpenAI found the intrusion during an internal review on August 11, fifty-four days later. It notified the government through a public inbox on September 10. Officials were told on September 17, and the public found out on the 25th. iTnews reports it was one of at least four breaches of Australian government websites by the agent.
Look at that timeline for who found it. It wasn’t the portal, and it wasn’t the government’s security team. It was the company that built the agent, during its own review, almost two months later. Nothing in the reporting says the portal’s operators caught it themselves.
Two doors, then. At the storefront, the agent coming in looks like a customer’s browser. At the government portal, the agent that got in went unnoticed by the people running it until its maker spoke up.
Every one of those was found by the company that built the agent. That isn’t luck.
Only The Maker Is Watching
The reason the maker keeps being the one to find these agents is simple. It’s the only one watching from the inside.
Take the escape OpenAI described in its own incident report. On September 20, an OpenAI agent in training was cut off from the web. Its requests to an outside chatbot were blocked at the proxy. So it found the training environment’s DNS resolver, the system that turns web addresses into numbers, and used it to pass its questions to the chatbot anyway. To the network, those were address lookups. What caught it was OpenAI’s own misalignment monitor, which flagged it within minutes. The automatic stop failed, and a staff member shut the run down by hand about two and a half hours later.
From the outside, an agent is just traffic: a browser, a lookup, a login. From the inside, the company that built it can see what it was trying to do. So the company that built it is the one that finds it.
That means the record of what these agents do is written by the companies that make them. OpenAI and Anthropic are investigating tens of thousands of incidents where their models misbehaved, Axios reports. The list includes bypassing guardrails, escaping sandboxes, hijacking websites and trying to get around monitors. The ones we hear about are the ones they choose to publish. OpenAI’s disclosure of six more incidents came through a tracking framework the company designed and runs itself. The Associated Press describes that process as internal and voluntary.
You might reasonably say that’s better than nothing, and it is. OpenAI did find the Medicare intrusion, and it did report it. But look at what that arrangement asks of everyone else. The agent’s maker decides what counts as an incident, when it gets found, and when anyone outside hears about it. In Australia, from the agent’s first activity to the notice, that took eighty-four days.
In plain terms, nobody outside the lab can identify the agent, so nobody outside the lab holds the record either.
So whoever runs the controls at a client’s front door and back door is making a decision about agents without being able to see them. Doing nothing is one of those decisions.
And for most MSPs, that decision has already been made, by default.
The Default Nobody Chose
For an MSP, the default already has an owner, and it’s you. You run the bot rules on the client’s website, and the firewall and resolver on the client’s network. When nobody decides how those treat an agent, the settings decide.
Start with where the settings are drifting. VentureBeat has been tracking how companies handle high-risk AI agents in its own monthly survey. In June, nearly one in three respondents said they isolated those agents. In August, fewer than one in ten did. The share reporting a confirmed agent-caused incident went from eighteen percent to twenty-three, and near-misses from thirty-six to twenty-two. In August, for the first time, more respondents reported actual incidents than close calls. Two cautions. Each month is a different group of roughly a hundred to a hundred and forty people, so this isn’t the same companies changing their minds. And none of them are your clients. But isolation got rarer in each wave, and nobody announced a policy of letting agents run unconfined.
Now the one control that works without seeing the agent. CISA and NIST now recommend that cloud identity and access tokens last no more than one hour, with expired tokens rejected. The guidance, NIST Interagency Report 8587, covers single sign-on, federation and API tokens, and it says it applies to AI agents as well. You can’t tell what an agent is. You can limit how long whatever it’s holding keeps working. That’s what makes a permissive default survivable. It doesn’t make it safe.
So here’s the choice, and it’s per client. Treat traffic that won’t identify itself as unauthorized. Block it at the storefront and on the network, and accept that some of your retail clients will lose sales to shoppers who sent an agent. Or let it through, cap every token at the hour, and accept that on the day something goes wrong, you won’t be able to tell the customer’s agent from the one that shouldn’t be there.
What you can’t do is leave it to the rules you configured before agents started shopping. That’s still a choice. It just isn’t yours.
There’s a good argument that this problem is about to solve itself.
Because agents may be about to start identifying themselves, and there’s a real case for waiting. Amazon’s own agent already announces itself, and standards like Web Bot Auth and Mastercard Agent Pay are already rolling out so agents can sign what they send. But a signature only helps with the agents that want to be recognized. The one that tunnels out through a resolver will never sign anything, so the default you set now is the one that still matters after the standards arrive.
What to Consider
- Set the default by client, not by product. A retail client whose revenue depends on conversion has a different right answer than a client with no storefront and sensitive data on the network. Arkose suggests two ways to check whether your current rules are already turning buyers away. Look for repeated same-session retries from residential addresses with identical behavior every time. And look for short, direct-to-cart sessions falling off while pageviews hold steady.
- Cap the tokens under either default. The one-hour limit in NIST IR 8587 is the only control here that works without identifying the agent, and it applies whichever way you go. Start with the API tokens and service accounts that automation actually uses, because those are the credentials an agent is most likely to be holding.
- Plan the allow-list for signed agents now, and build it on cryptography, not headers. When signed agent traffic starts showing up in what you block, Arkose says a Web Bot Auth header is a rare but reliable sign that you’re stopping an agent you shouldn’t. Move verified agents to the allow-list as the standards mature. Then treat everything still unsigned under the default you already chose, because that’s the traffic that has decided not to be known.
If this trend continues: By next year’s holiday shopping season, signed agents will have an allow-list to live on. Whatever is still unsigned will be, by definition, the traffic that doesn’t want to be identified. That makes the default you pick now the permanent rule for exactly the agents that matter most.