CAPTCHA used to be the default answer to bots. Draw a box around traffic lights, decipher warped letters, click "I'm not a robot." It was annoying, but it worked.
It doesn't work anymore — not really.
Modern bots run real browsers, rotate through residential IP addresses, and call CAPTCHA-solving services that cost fractions of a penny per challenge. LLM-powered scrapers and agentic tools go further: they navigate like humans, parse page context, and adapt when a site changes. The puzzle you show your users is now just a speed bump for attackers — and a conversion killer for everyone else.
At Phylaxa, we detect automation by reading behavior instead of issuing challenges. This article explains what that looks like in practice and how to evaluate it for your own product.
What's wrong with signature-based detection?
Traditional bot management relies on a familiar toolkit:
- IP reputation lists
- User-Agent strings
- JavaScript challenges
- Rate limits
- Static rules written by hand
These worked when bots were simple scripts. Today, a sophisticated attacker can mimic a Chrome browser on a residential IP, throttle requests to look human, and solve any challenge on demand. Rules become a game of whack-a-mole: every block is a cue for the attacker to adapt, and every adaptation requires another manual rule update from your team.
The result is a widening gap between what rules can catch and what actually hits your infrastructure. The traffic that worries you most — slow, distributed, context-aware automation — is precisely the traffic that sails past signatures.
Behavioral analysis: scoring the session, not the request
Instead of asking "does this request look suspicious?", we ask "does this session behave like a human?"
A real human session has structure:
- Variable pacing: reading time, backtracking, scrolling, pausing mid-form to check something.
- Noisy input: mouse trajectories and keystroke timing are irregular in ways that are hard to fake consistently.
- Goal-directed navigation: humans browse, compare, hesitate, and return; bots extract.
- Fingerprint consistency: real devices produce stable but imperfect signals across a session.
A bot session — even a smart one — tends to optimize for the outcome. It moves through forms efficiently. It doesn't dwell unless forced to. Its interaction entropy is either suspiciously regular or suspiciously random, because simulating the middle ground of genuine human messiness is still genuinely hard.
We capture 300+ passive signals per session — TLS and HTTP/2 fingerprints, canvas and runtime behavior, navigation patterns, input dynamics — and feed the sequence into a fine-tuned large language model that scores the entire session rather than any single request. The output is a risk verdict your application can act on: allow, monitor, throttle, or block.
Why an LLM?
A rules engine looks for known bad patterns. A fine-tuned language model learns what "normal" looks like across real traffic and flags deviations — including patterns no human analyst has explicitly defined or would think to write a rule for.
This matters because the adversary is also using AI. When attackers change tactics, a static ruleset waits for someone to notice, investigate, and ship an update. A model that is continuously retrained on fresh traffic adapts on its own. Behavioral sequences are, in a meaningful sense, a language — and sequence modeling is exactly what LLMs are good at.
There is a second, quieter benefit: visibility at the session level. Because the model evaluates the whole sequence, your team can review which behaviors pushed a session over the threshold, instead of staring at an opaque rule ID.
Edge deployment keeps latency invisible
Scoring has to be fast. If your bot check adds a visible network hop, you have already hurt user experience — the very problem you were trying to escape by moving away from CAPTCHAs.
We run the model inline at the edge, with a median scoring latency under 5 ms. There is no redirect, no interstitial challenge page, and no added friction: legitimate traffic passes through unchanged, with zero challenges shown to real users. Deployment fits your stack — lightweight server SDKs, native connectors for major CDN and edge platforms, or a regional cloud API — so the check happens wherever your traffic already terminates.
What this means for product teams
Behavioral detection changes what is practical to protect:
- Signup flows: stop fake accounts, referral abuse, and promo farming without adding friction that costs you real registrations.
- Login flows: blunt credential stuffing and account takeover without locking out customers who mistype a password.
- Public content: keep search engines and other good bots flowing while slowing down scrapers and unwanted training crawlers.
- Checkout flows: reduce carding and promo abuse without adding a puzzle between a paying customer and the "buy" button.
The common thread is that protection stops being a tax on your best users. The challenge budget goes to zero; the detection budget moves to signals attackers can't see.
A practical starting point
If you're evaluating bot detection today, start with three questions:
- What percentage of my traffic is automated?
- Where is it costing me money — infrastructure, fraud, support load, lost conversion?
- Can I block it without annoying real users?
If you don't have good answers, you're probably losing more than you think — our companion piece on the real cost of bot traffic walks through the math.
Phylaxa can help you answer the first two questions on your actual traffic, and for a limited time Phylaxa is free for teams under 100,000 monthly users. Apply for the free plan — every application is reviewed by an engineer, and most teams are live within one to two business days. See pricing for details.