../

Agent Swarms and the Bot-Detection Gap

Introduction

Bot defense can’t be won by detection alone. It can be won by making each fake identity and each abusive action cost more than it earns.

On September 22, 2026, Nikita Bier, who ran product at X until August, wrote that bot detection and human verification “will be one of the most urgent demands for businesses over the coming years,” and that agent swarms would “suffocate every website and form.” Bier said X found no vendor that combined the latest techniques, so it built its own.

C (@unreleased), a reverse engineer, answered bluntly: “This isn’t a solvable problem.” He added that there’s “not a single antibot on the market that doesn’t have a reversed solution you can’t buy for a few beans on a discord server.”

Both are partly right. Bier is right about the demand. C is right that no vendor can reliably spot a sophisticated bot by inspecting the client. The mistake is treating detection as the goal.

What anti-bot vendors actually sell

Commercial bot defense stacks four layers, and attackers can inspect three of them. The examples below come from my own static and offline analysis of about 20 anti-bot/detection products.

LayerExample from my notesWhat it tells the defender
Browser fingerprinting scriptDataDome JS tag 5.1.13 checks 118 window properties, lists 1,231 global names, and cross-checks values inside a Web Worker and hidden iframes“This environment looks like a real Chrome”
Obfuscated virtual machineKasada and Shape/F5 run their logic in custom bytecode interpreters; Shape reshuffles its opcodes per sessionRaises the cost of understanding the checks
Mobile SDK and hardware keysAkamai’s mobile SDK runs in native ARM code; Forter’s checkout SDK requests hardware-backed keys and key attestation on mobile“This is a real, unmodified device”
Server-side scoringIP reputation, request history, account age, behavioral models“This identity has behaved well before”
Three layers, the fingerprinting script, the obfuscated VM, and the mobile SDK, run on the attacker's machine and are readable. Server-side scoring runs on the vendor's servers and is opaque.
Everything above the line ships to the attacker. Only the scoring stays home.

The first three layers run on hardware the attacker controls. A fingerprinting script is just code asking the browser questions. Here are a few that DataDome’s tag asks, reconstructed from my deobfuscation of version 5.1.13 (the short field names are the tag’s own):

DataDome 5.1.13, reconstructed
// legacy automation frameworks leave globals behind
awe = !!window.awesomium      // Awesomium
phe = !!window.callPhantom    // PhantomJS
dat = !!window.domAutomation  // DOM Automation
nm  = !!window.__nightmare    // Nightmare

// is this iframe a real, separate window, or a fake one?
wdifrm = iframeWindow === window ||
         iframeWindow.decodeURI === window.decodeURI

// a Web Worker re-reads userAgent, platform, languages,
// GPU renderer, and timezone; any mismatch is reported as wwl

Every one of these checks has a known correct answer, and a patched browser can give it. That’s C’s argument in miniature. Commercial solver APIs already sell Akamai sensor generation as a plain HTTP API. I went deeper on the VM layer in Client-Side Virtual Machines in Modern Bot Defense.

The fourth layer is different. Nobody outside the vendor sees the scoring model or the reputation data. The community phrase for this is reversing is not defeating. Anubis, a proof-of-work gate, publishes its source code, so there’s nothing to reverse. It still costs attackers at scale, because every request has to burn CPU.

The view from the automation side

People who build bots for a living don’t think detection is hard. They think it’s impossible.

C’s argument is that “everything can be emulated at a higher level.” Patch the browser, replay recorded human input, lift the VM. Every layer the defender adds runs on a machine the attacker owns.

He also points out that sophisticated bots aren’t a future threat. They already scalp shoes, tickets, and Pokémon cards, run fake social and dating profiles, and resell visa and driving-test appointments. His summary: “stopping sophisticated bots is impossible. i will die on this hill.”

Tudor Patroi (@TPatroi) offered the usual rebuttal: move the check into hardware, such as phone biometrics or a laptop’s security chip. C’s reply is the sharpest point in the thread: hardware “is still only proving that they own a device, not their intent.”

Device attestation answers “is this a real phone?” It can’t answer “is a person choosing to do this?”

A rack of real, unmodified phones driven by automation still passes it.

What AI agents change, and what they don’t

Agents don’t make bots harder to detect. They make it cheap to attack sites nobody bothered to build a bot for.

Today’s serious ecommerce bots mostly skip the browser, whether they buy sneakers, concert tickets, trading cards, graphics cards, or restaurant reservations. They send raw HTTP requests and fill in the anti-bot token with a reverse-engineered generator. That’s cheap per request, but each vendor, and often each script version, takes weeks of specialist work. It only pays off on high-value targets.

An agent driving a real browser skips that work, because the real browser produces a genuine fingerprint. Agents built on automation protocols like Playwright still leave traces, as I covered in Why Stealth Browsers Still Get Detected. Agents that see the screen and send operating-system input leave far fewer.

Request-level bots need weeks of reverse engineering per vendor, take milliseconds per request, and target limited drops, tickets, and checkouts. Browser agents need no reverse engineering, take seconds per page, and target forms, appointments, small shops, and reviews.
Agents trade setup cost for per-action cost, which moves the pressure onto sites that were never worth a custom solver.

The catch is per-action cost: seconds and model calls per page instead of milliseconds. So agents probably won’t replace request-level bots on a drop that sells out in 30 seconds. They’re more likely to hit the long tail: permit forms, appointment systems, small shops, and review sites. That’s the defensible part of Bier’s warning.

What agents don’t make cheaper are the inputs every operator already buys: clean residential IPs, SMS-verified phone numbers, payment cards, aged accounts, and, when an app demands attestation, real devices. The expensive part of a successful run is rarely the solver.

Case study: Amazon blocks Muse

The weekend before Bier’s post, Amazon showed what fighting a legitimate agent looks like. Around September 20, it blocked Muse, Meta’s new AI agent, from shopping on Amazon.com.

Muse launched on September 8 and passed 730,000 downloads in its first five days, more than ChatGPT and Claude. Each user gets a “secure virtual machine” with its own browser, which Muse uses on sites without an API (GeekWire). Muse users who tried to shop on Amazon got this message:

“Continued access by an unauthorized AI agent violates Amazon’s Conditions of Use, to which our customers have agreed.”

Amazon’s complaints were about accountability, not fingerprints. Meta didn’t tell Amazon that Muse would access its store. Muse doesn’t identify itself in its HTTP requests, as Amazon’s terms require. It also moves through customer accounts; Meta says it never sees passwords or payment methods.

Three things stand out:

  1. It’s not a bot-versus-human question. A real customer asked for every Muse purchase. Amazon blocked it anyway, because the question was who may act for that customer.
  2. It’s business as much as security. Amazon earned more than $68 billion in ad revenue last year, which depends on people browsing its pages. An agent that buys without browsing skips the sponsored products. Amazon’s own Buy for Me agent identifies itself and lets brands opt out.
  3. Legitimate agents can hide technically, but not commercially. As the Comet story below shows, an agent can dodge a technical block within a day. But a public product from a public company can also be pressured through terms, the press, and the courts. A scalping operation has none of those weak points, so self-identification rules can govern agents like Muse but are unlikely to touch the bots C describes.
A declared agent like Buy for Me lets the store set the rules. An undeclared agent from a public company like Muse gets blocked and pressured through terms, press, and courts. A hidden bot operation has no company to pressure, so only raising the cost of each identity works.
Rules and lawsuits work on agents with a company behind them. Hidden bots only respond to cost.

Elon’s objection

Elon Musk replied to the news:

“Amazon won’t be able to tell whether the buyer is a human or an AI acting on their behalf if access is via the user’s IP address & cookies”

It’s an odd position for the owner of X, whose former head of product just said X had to build its own bot detection.

Musk is right about the mechanism and wrong about the conclusion. IP address and cookies are two of the strongest signals a defense has. An agent inside the user’s own logged-in browser inherits both, which makes each request much harder to flag. But:

  • Muse doesn’t work that way. It runs in Meta’s own virtual machine, not the user’s browser, so its traffic doesn’t come from the user’s home connection.
  • The setup Musk describes already exists, and Amazon still caught it. Perplexity’s Comet runs on the user’s own machine. Amazon said it disguised itself as a regular Chrome session and blocked it in August 2025. Perplexity shipped an update that got around the block within 24 hours: C’s cat-and-mouse game in one exchange.
  • Detection didn’t settle it anyway. A judge barred Comet from Amazon in March 2026. On August 4, the Ninth Circuit vacated that injunction, ruling that under federal anti-hacking law the user, not Perplexity, accesses Amazon. It left terms-of-service and contract claims open. The fight moved from fingerprints to contracts.

Where defense is heading

The useful question is no longer “is this a bot?” It’s “who is accountable for this traffic, and how much have they already used?”

A defender doesn’t need to know intent. They need the 1,000th fake account to cost roughly 1,000 times as much as the first. Three approaches aim at that, and all are already shipping.

1. Agents that identify themselves

Web Bot Auth lets an agent platform sign every HTTP request with a published key, and Cloudflare began verifying these “signed agents” in August 2025. Visa’s Trusted Agent Protocol (October 2025) applies the same idea to checkout. Abusive bots won’t sign, but they don’t need to: once legitimate agents declare themselves, sites can treat anonymous automation more strictly. That’s the rule Amazon says Muse broke.

2. Rate limits tied to something scarce

Private Access Tokens and Cloudflare’s anonymous rate-limited credentials let a device or account prove it’s under a quota without revealing who it is. This doesn’t stop a phone farm. It caps the farm’s output at what its hardware allows.

Operators buy IPs, phone numbers, cards, aged accounts, and devices. With a fixed quota per input, one device gets one quota and one hundred devices get one hundred quotas, not unlimited access.
100 phones buy 100 phones’ worth of quota. Abuse still works, but now it has a price.

3. Economic friction

Proof-of-work gates make every request burn CPU. Draws, purchase limits, and payment holds change what winning costs. When brands moved hyped sneaker drops from first-come checkout to raffles, speed stopped mattering, but bots didn’t disappear. They switched to mass-producing raffle entries, which is why “entering raffles” is on C’s list. More on drop mechanics in Modeling a Hype Drop as a Distributed Systems Problem.

For small sites, the gap isn’t new detection technology. It’s packaging. Nobody running a county permit portal will tune bot rules, so these defenses need to be on by default in their CDN, commerce platform, or identity provider.

So is there a gap in the market?

Yes, but not the one Bier describes. Another vendor with a better fingerprinting script will get reversed and resold like the rest.

The real gaps are packaging for the long tail and identity-level trust for platforms like X. The second depends on account history and social-graph data only the platform has, which explains why X built its own. Vendors can’t sell data they don’t have.

C gets to keep his hill: a well-funded operator can’t be reliably detected. But the contest has moved to cost. Watch the price of a clean residential IP, an SMS-verified phone number, and an aged account. Whether those prices rise is a better test of defense than any detection rate.

Sources


Related: VM antibots Part 1 · Why Stealth Browsers Still Get Detected · nate.log