Bot attacks have an economic edge. Adaptive Intelligence aims to reverse it

Modern bot threats are frequently the work of organized groups or commercial services, not lone individuals. These attackers often treat bypassing bot detection as their primary job, and AI has only lowered the barrier to entry for assembling complex attack configurations. This dynamic puts defenders at a structural disadvantage. Responding to new attacks requires care to avoid harming real users, while attackers face few constraints beyond their time, proxy supply, and infrastructure provider tolerance.

The core problem is the cost of adaptation. Attackers iterate continuously, deploying workarounds as often as needed. Most defenses, conversely, ship in discrete, managed releases. Cloudflare's daily analysis of over a trillion requests for signs of automated abuse shows just how quickly attackers change tactics—and the responsiveness gap is widening.

The industry's conventional approach relies on a hopeful assumption: build the wall high enough and attackers will stay out. In practice, a determined attacker always finds a path through. The relevant question is not whether they will get in, but what happens when they do. Rather than betting on an impenetrable wall, Adaptive Intelligence, launching today, starts from the opposite premise: make getting through so slow and costly that the attack ceases to be worth running.

Why deterministic detection favors the attacker

The most sophisticated attacks are designed to blend into ordinary traffic. An attacker might spread requests across a large residential proxy network, keep rates from each address low, and move patiently through login, checkout, or account-recovery flows. Every request arrives from a different address, often with a fresh user agent or bot fingerprint, making each one appear as a new visitor. No single source ever trips a rate limit.

This shape is difficult to stop. Tighten thresholds too aggressively and real customers get turned away—the very outcome you are trying to avoid. The attack lives in the gaps between individual requests, and a defense that scrutinizes each request in isolation will never see it.

Rule-based systems hand attackers a stationary target. These systems iterate in days while the model waits months for updates. The detection loop has always been: spot a new technique, write a rule to catch it, wait for the attacker to study that signal and circumvent it, then write another rule. Some advanced attackers have even built tooling to semi-automate this process.

This deterministic detection—where the same input always produces the same output—teaches attackers how to beat it. Automated probes return a clean yes or no, and across enough attempts, that feedback reveals the exact edges of the system. The economics are firmly in the attacker's favor.

Reversing the cost equation

Adaptive Intelligence aims to flip that calculation, but only if two conditions hold simultaneously. First, it must cost the defender less to react than it costs the attacker to work around. Second, attackers must be starved of the feedback they use to adapt. Get both right and the attacker's own loop turns against them: nothing learned stays true, and each new attempt costs more than the last.

Part of this involves giving attackers less to learn from. Adaptive Intelligence can recognize a bot from a signal without visibly reacting to it, so the attacker keeps relying on a tell they do not realize is visible. It treats detection as a statistical judgment rather than a fixed rule, making it non-deterministic. With many signals weighed at once, there is no single piece of logic for an attacker to isolate and defeat.

A new detection engine behind bot score

Bot scores already draw from several detection methods working together: machine learning, behavioral validation, JavaScript fingerprinting, heuristics, and checks that recognize known verifiable bots like search crawlers. Adaptive Intelligence is a new detection engine that sits behind that score. Where other systems accumulate rules to keep attackers out, this one assumes attackers will eventually get in and makes that attempt as costly as possible.

The engine has three planned components that are unique compared to traditional models: continuous self-improvement, disposable rule generation, and learning from the traffic it protects. Launching today is the first component: the machine learning at the center of bot score, now retraining continuously rather than shipping as a fixed version. It aggregates network signals from across Cloudflare's network and measures the probability of automated abuse for every request.

1. Improving itself

The engine retrains continuously on live traffic. As new bypass tools and bot frameworks emerge, it learns from them and folds that knowledge into the model behind bot score without waiting for a scheduled release. A technique appearing this week is one the engine can recognize this week. The score you already build on stays close to actual attacker behavior rather than drifting further from reality between updates.

2. Disposable rule generation

A disposable rule targets a specific attack, gets deployed and retired at random intervals, and is never left in place long enough to become a fixed target. Because these rules keep appearing and vanishing, they inject noise into the signal an attacker relies on to train against the defense. Attackers never get the steady yes-or-no that a static defense leaks. No single rule has to be perfect or unbeatable—it only has to last long enough to do its job before making way for the next. By the time an attacker reverse-engineers a pattern, the engine has already moved on.

3. Learning from protected traffic

The engine will also learn from patterns across millions of sites. When a customer flags a real visitor that was scored incorrectly, or internal measurement catches a miss, that correction becomes a training signal. Over time, the engine tunes to the problems Cloudflare's customers are actually facing, reflecting the current threat landscape rather than a snapshot of an older one.

An automated loop: observe, train, deploy, validate

BLOG-3439 2.png

Observe. The engine aggregates Cloudflare network signals, such as JA4 TLS fingerprints, request structures, challenge outcomes, session behavior, network reputation, and higher-level meta signals, alongside client-side telemetry from Turnstile and Precursor. A client that looks ordinary on any single request but moves like a script across a whole session is caught by its behavior over time, even when each request looks legitimate.

Train. We retrain the ML system continuously on live traffic, including the newest bypass tools and bot frameworks as they appear in the wild. The training set is refreshed often, so the system can react much faster to new attack techniques.

Deploy. New model weights roll out across the network on their own. There is no version to choose and no upgrade to schedule, and once you are on it, nothing for you to do. The model scoring your traffic reflects the threats we are seeing right now.

Validate. Before a new version becomes your primary defense, it runs in shadow mode alongside the current one, scoring live traffic without affecting a single visitor. We compare the two and watch signals like challenge solve rates. If a new version would score real people worse, it does not go live.

Cloudflare has run this type of automated loop against DDoS attacks for years: sample traffic, fingerprint patterns behind an attack, push protections across the network, and keep measuring for adjustment or retirement. Bots are a harder version because signals are quieter and the story emerges over time. Any single signal can look perfectly normal in isolation. The relationships between signals, and the company they keep, reveal bots hiding in normal traffic.

Adaptive Intelligence evaluates traffic across several time windows simultaneously. A short window catches a sudden burst as it develops. A longer window reveals behavior repeating across thousands of addresses, clients, and sessions that have no reason to behave alike—tying scattered requests back to a single source. The same engine that spots an obvious scraping spike also surfaces a slow, distributed credential-stuffing attack sending only a handful of requests from each address.

Building new detections automatically

As the next components come online, mining systems will search recent, labeled traffic for signal combinations that separate an emerging attack from real users. Often a detection comes from the relationship between known signals rather than a brand-new one. A client might claim to be one browser while producing the network or JavaScript signals of another. A request might look normal alone but form an odd sequence alongside the rest of the session. Automated mining allows many combinations to be tested, with the strongest becoming candidate detections.

These candidates are deliberately narrow. They do not need to catch every bot on the internet, or even every request in the current attack. That makes them quick to build and easy to replace when tactics change.

Remembering past attacks

Attackers do not attack once—they pause, retool, and return. Retiring a detection does not mean forgetting the pattern behind it. The engine keeps a memory of past attacks even after their detections stop firing, preventing attackers from escaping by flipping between two profiles and betting the second looks new. This memory gives the system a head start when a familiar attack returns or a related one appears. A detection can expire when it stops earning its place while the evidence behind it remains available. Nothing piles up as stale rules in production, and old attacks never need to be learned from scratch.

Deploying safely

Constant change only helps if every change is safe, and the bar is high. Customers can tolerate the occasional bot slipping through, but wrongly turning away a real visitor is the failure that matters. Each candidate detection is tested against recent real traffic, measuring how much known automation it catches and how often it would flag a genuine visitor by mistake. It rolls out gradually as an input to bot score while distributions, challenge outcomes, and customer feedback are monitored. Updates can be paused or rolled back before reaching the whole network. Every update must prove it is at least as good as the one it replaces on precision and recall measures.

One vision with Precursor

This engine does not work alone. Precursor, introduced last month, is a continuous behavioral validation engine for bot management built with privacy in mind. It measures automated abuse based on how a visitor behaves once in the browser: timing, movement, and small human signals that automation struggles to fake. Precursor and Adaptive Intelligence were built as two parts of one idea. Precursor measures continuous session behavior; Adaptive Intelligence learns from bot detection signals across the whole network. Signals from one make the other harder to fool.

What comes next

Continuous retraining is the foundation. From here, the engine expands with automatic detection generation for bots, a more connected view across the network, challenge, and browser into a single session view, and more ways to act on what the engine finds.

Accepting that no defense will keep every determined attacker out allows for something more useful: making each attempt short-lived while costing the attacker more than it returns. Adaptive Intelligence reacts faster to new techniques and gives attackers less to learn from with each change. For attackers who never quit, the defense is different every time they return—and persistence stops paying off.

Enabling Adaptive Intelligence

Enterprise customers activate Adaptive Intelligence by enabling "Auto Update Machine Learning" in the Bot Management dashboard. No migration or configuration is required — the feature is applied automatically, and the existing bot score continues to work without any changes.

If you are unsure whether this setting is already on, verify it in the dashboard to ensure you are protected immediately.