I ran my online commerce through an agent for ten days. It worked, it needed nothing from any merchant, and the decision it created is going to land on security teams.
When I started Arkose Labs ten years ago, a bot was only ever a bad thing. Every conversation I had with a security team started there. For a decade that was the right place to start.
It isn't anymore.
Meta shipped Muse to North America consumers this month. Free tier, on iOS, Android, the web, and inside WhatsApp chats. Muse is a true consumer-grade agent from an already established household name, being advertised in the largest social media ecosystem there is.
I have used it as my only route to online commerce since. Groceries, flights, theater tickets, dog food. It works. I want to be fair about that, because this would be easy to read as a warning and nothing else. Muse is an impressive piece of engineering. So is Instinct, Grok Bot, Gemini Spark. This is a conversation about something that works incredibly well, and the impact it will have on how consumers transact going forward, which needs to be balanced with the security aspects of bot traffic online.
The bag of dog food
The errand I did this weekend involves my dog, Ruffles. My local pet store was closed, and we'd run out of dog food.
I sent Muse a photo of her bag of food and asked it to find the cheapest equivalent with the best shipping. It went and checked six retailers.
Though, at one it never got through the door. Bot protection stopped it before it could read a price, so that retailer wasn't in the comparison at all. The agent didn't appeal. It didn't retry, and it didn't tell me anything had gone wrong there. It moved on. From the merchant's side nothing happened: no attack worth noticing, no fraud prevented, but no order. A customer with a card and a settled intent to buy dog food went somewhere else, and nobody there will ever know.
In another shopping scenario, it tried to checkout and found no guest option. So it asked me a question. Should it pivot to a different retailer instead?
I happened to have credentials for that site, so I informed it of that and it finished the order. They kept the sale because of a login I was aware it already had. I doubt they'd call that a win if they knew how close it went.
Nothing about this was opt-in
It's worth being explicit about what none of it required.
The agent never declared itself. It followed no MCP protocol. Where a connector or a public API existed it used one, and where none did, it opened a browser in Meta's cloud, used the credentials I gave it, and completed the task through the same flow a person would. It negotiated nothing with any merchant. It was granted nothing.
I expected it to work on simple sites and fall apart on hard ones. It didn't. Sites I would have called highly resistant to automation handled it fine. This is why it technically disguises itself as much as it can, so it just works.
I wrote After Bots earlier this year arguing that agentic commerce wasn't going to wait for agent-facing APIs. The consensus then was that it would. Build the connectors, sign the partnerships, and agents come through the front door you designed for them.
What I described in the book was an agent changing population mid-errand. Ask it to book a flight on a carrier with an MCP integration and it calls the endpoint, authenticates properly, and the airline sees an agent that says so. Ask it to buy from a platform whose policy bans automated purchasing and disclosing gets it blocked, so the only path to finishing the job runs through not disclosing. Ask it to buy from a smaller airline with no integration at all and there's no protocol to authenticate against, so it reaches for the same web flows a person would. Same agent, same user, same five minutes, different populations.
The line I landed on was that population isn't a property of the agent. It's a property of the interaction.
What I got wrong was the ratio. I wrote that as the awkward edge case at the margins of a connector-first world. Muse inverts it. The web flow is the default and the connector is the exception. Even with multiple standards being worked on, these tools have so far decided that not following them allows them to fulfill their purpose even better.
Waymo is the analogy I keep coming back to now. Autonomous cars didn't get their own road network. They learned to drive the roads we already drive.
What merchants actually told me
I put this to a panel of merchants and risk leaders recently, and asked whether they were seeing agentic fraud.
No. Fraud rates have held. They weren't worried about fraud at all.
What they were worried about was whether the transaction workflow works for agents. Because it has to. People are going to use these things, and if a hundred million people are going to use something, you have to find a way to support it. It's the same conversation everyone had when ChatGPT turned up.
That is a commerce problem on its face. Companies are going to lose revenue if they can't identify agentic traffic, and they'll lose it quietly, in transactions that never complete and never show up in a report.
“
Companies are going to lose revenue if they can't identify agentic traffic, and they'll lose it quietly, in transactions that never complete and never show up in a report.
So you're going to get asked to allow it
Here's why I think this lands on security.
Somebody in your business is going to see those numbers, or read something like this, and come to you with a request. Let the agents through. It won't arrive as a security project. It'll arrive as a revenue conversation with a deadline attached, and the ask will be simple: stop blocking our customers' agents.
That request is reasonable. The dog food story is what it costs to refuse. But look at what you're being asked to build.
A privileged path, for traffic that cannot prove who it is.
No consumer agent self-identifies. None of them use the identity standards, because the standards aren't there. So whatever you build, you're granting preferential treatment on inference rather than on proof. Get that wrong in one direction and you're back to losing baskets. Get it wrong in the other and you've built something worth attacking.
If security doesn't own how that path gets constructed, it gets constructed anyway, by someone measured on conversion.
The half I'm less comfortable with
Everything above is a consumer win. I should still be straight about what I handed over to get it.
My agent reads my email and sees my notifications. So it completes multi-factor authentication on its own, start to finish, without me. The one-time code arrives in a channel it's able to read from.
It asks before anything irreversible (e.g. purchasing something), and Meta built those confirmation steps deliberately. They're the right design. But look at what that check is holding up. If it were ever bypassed, or if someone got into my account and approved on my behalf, they'd inherit an authenticated session at every site I use with the MFA problem already solved for them.
The obvious answer is passkeys, and it's half an answer. They're bound to a device, held in a platform authenticator, unlocked by a gesture. That design is exactly what makes them phishing-resistant, and it's the same design that makes them structurally incompatible with agentic access. An agent can't present a fingerprint. It can't hold a credential inside an authenticator it doesn't control.
The pattern the industry is converging on is a split. Passkeys for the human authentication moment, scoped and time-bound delegation tokens for the agent actions that follow. The human authenticates, consents to an agent acting for them, and the agent works from a token.
But it depends on the consent being meaningful, the scope being narrow, the token life being short, and the platform being able to tell when a valid token is in the wrong hands. OAuth authorizes. It doesn't classify. Passkeys can't cover that gap, because by the time the agent is acting, the human moment has already passed.
“
OAuth authorizes. It doesn't classify. Passkeys can't cover that gap, because by the time the agent is acting, the human moment has already passed.
Change the vertical and this stops being about a basket. Granting an agent access to a bank account takes a username, a password, and the ability to read notifications. That's the whole list. Banks aren't defenseless, transaction monitoring and payee checks still fire, but none of those controls know they're talking to an agent.
My view is the answer is per flow, and it follows from the interaction point above. Checking a balance, moving money between a customer's own accounts, paying an established payee: let the agent do it. Adding a new payee and sending money to them for the first time is where I want a human demonstrably in the loop.
Which also means classifying once at the door and routing the rest of the session on that verdict is the wrong shape. The same session can be fine at one endpoint and worth interrupting at the next.
Which makes the allow path a target
Now let's put the two halves together, commerce and security.
You build the path. Agentic traffic gets recognized and gets to complete. Great! You've fixed the commerce problem and your customers' agents stop bouncing off your checkout.
You've also created a lane worth forging credentials for.
I wrote about this in the book, in the narrow case. Malicious automation already spoofs the identities of legitimate agents, presenting user agent strings from known AI providers to claim preferential treatment. At the time that was about crawlers and it was mostly an annoyance. Apply the same move to consumer agents that carry credentials and payment methods and it stops being an annoyance.
Which is why the allow decision can't be a list. A vendor allow-list is a forgery target, and the moment it's worth something, someone will work out what to put in the headers. The decision has to be inferred per session, from device, network, behavioral, and email signals, and it has to keep being inferred as the session moves.
“
A vendor allow-list is a forgery target, and the moment it's worth something, someone will work out what to put in the headers.
So the two jobs turn out to be one job. A system that only enabled good agents would be trivial to abuse. A system that only blocked bad ones puts you back where the dog food went to a competitor. You need both, and you need them answering from the same evidence, because the good agent and the impersonator are arriving at the same endpoint looking identical.
Where Arkose Labs fits
For the first eight years or so we were hyper-specialized. Not on traffic generally, and not really on the bot question either. On the high-value moments: logging in, creating an account, buying, moving money, changing account details. The places where getting it wrong is expensive.
That shaped the product. We were never only asking whether something was autonomous. The question underneath has always been simpler. Is the intent of this thing arriving at you good or malicious. If it's malicious, deter it. If it's good, enable it.
For a decade the second half barely mattered, because nothing automated showing up at a login page was good. Now that has changed.
The good news is the machinery didn't need rebuilding. The same signals that expose a bad actor are the ones that identify and label a good agent. Arkose ID layers AI-driven similarity analysis on top of exact-match identification, so it recognizes the same device as fingerprints evolve. That matters more here than it sounds, because these agents deliberately keep state on their VMs. They want to be recognized as the same user next time rather than tripping fraud checks on every visit. Alongside it sit behavioral signals, email intelligence, network risk, and device spoofing detection, through a single API call.
Agent Trust Manager is the capability on Arkose Titan that separates the traffic: visibility, then classification, then control across Allow, Monitor, Challenge, Throttle, and Block. My colleague Shimon has written up how the classification works in more detail than I'm going into here.
And the adversarial half got harder this year too. AI harnesses are steering botnets around detection with real adaptation instead of blind retries, opening accounts at scale, running card fraud, and socially engineering human support agents. There's more sophisticated autonomous activity on the web today than at any point I've worked in this industry. None of that work slows down.
If you see this the same way
Most companies can't answer a simple question right now. How much of the traffic hitting your login, signup, and checkout flows today is agentic? Not a projection. The actual number, this week, on your own systems.
Almost nobody has it. That isn't a failure of anyone's security program. These agents don't announce themselves, none of them use the identity standards, and the drafts that were supposed to fix that expired. There was nothing to measure with.
I've spent ten years building the machinery to tell automated traffic apart from people. That work didn't change. The question did. It used to be whether something was a bot. Now it's whether this agent is authorized to do what it's trying to do, and whether the thing claiming to be your customer's agent actually is.
We built Arkose Titan to answer both. If you see where this is going the same way I do, I'd like you working on it with us.
