What is bot detection?
Bot detection is the practice of separating automated traffic from real human users. It covers scrapers, credential stuffing tools, click bots, spam scripts, and, increasingly, AI agents that drive full browsers. The output is a classification per session (human, bot, or acceptable automation) that downstream systems use to block, challenge, or allow the request.
How it works
Bots exist because automation is cheap and manual work is not. A scraper can pull a pricing catalog thousands of times a day. A credential stuffing tool can test a million leaked passwords overnight. A registration bot can create the raw accounts behind a fake account farm. Each of these attacks only pays off at volume, and volume is exactly what detection systems look for.
Traditional detection works in layers. The first layer inspects the client environment for automation framework markers: navigator.webdriver set to true, Selenium or Puppeteer artifacts in the JavaScript runtime, and the stripped-down feature set of headless builds. The second layer checks consistency through browser fingerprinting: a client claiming to be an iPhone should not report a SwiftShader WebGL renderer. The third layer watches behavior over time, because even a bot with a perfect fingerprint still has to act, and acting at machine speed is hard to hide.
AI agents changed the economics of this fight. An LLM-driven agent runs a real Chrome instance with a real rendering engine, real fonts, and often a residential IP. Nothing about it is headless, so naive checks pass cleanly. The problem also stopped being purely adversarial: an agent booking a flight or renewing a subscription for a paying customer is traffic many businesses want to serve. That shifts the goal from "block everything automated" to "know what is automated, then decide."
How to detect it
Practitioners layer signals rather than trusting any single one.
On the device side, look for navigator.webdriver, Chrome DevTools Protocol artifacts, and overridden native functions whose toString() output no longer reads [native code]. Headless builds also ship with missing media codecs, empty plugin arrays, and permission APIs that answer too fast or too uniformly.
On the network side, datacenter ASNs, hosting-provider IP ranges, and known proxy or VPN exits carry weight. So do volume patterns: dozens of new accounts registered from one device, one account touched from hundreds of IPs, or request rates no human could produce from a single connection.
Behavioral timing is the hardest signal to fake at scale. Forms completed in under a second, pointer traces that are perfectly linear or absent entirely, uniform intervals between requests, and navigation that skips every intermediate page all point to a script. LLM agents invert some of these tells: they can be slower than a human on individual actions but oddly consistent across sessions, and they often act through the accessibility tree or scripted selectors instead of a mouse.
Challenge escalation ties the signals together. Low-risk sessions pass invisibly, borderline sessions get a lightweight proof-of-work or interaction check, and high-risk sessions face verification that costs real effort to clear. A standalone CAPTCHA is no longer a reliable gate on its own; solver services are cheap and multimodal models handle most visual puzzles, so the challenge has to be one layer among several rather than the whole defense.
How Rupt handles it
Rupt runs these layers as one pipeline: environment checks, fingerprint consistency, network reputation, and behavioral scoring feed a single verdict per session, with challenges that escalate only when risk warrants it. The bot detection page covers the signal set, and the fraud detection API is how you wire verdicts into your own signup, login, and checkout flows.