cloudflareJul 13, 2026

Introducing Precursor: detecting agentic behavior with continuous client-side signals (opens in new tab)

Precursor is Cloudflare’s new client-side, session-based system for detecting bots and agentic automation through continuous behavioral signals. Unlike one-time challenges, it evaluates interactions across an entire user journey, making automation harder to imitate while reducing friction for legitimate users. It complements Turnstile by extending behavioral detection beyond sensitive checkpoints such as login, signup, and checkout. ## The Visibility Gap in Bot Detection - Cloudflare analyzes more than 1 trillion requests daily across over 20% of the web. - Turnstile runs nearly 3 billion times per day and provides risk-based verification at important application endpoints. - However, point-in-time challenges offer limited insight into how users and bots behave throughout the rest of a session. - Precursor addresses this gap by continuously observing interactions across an application. ## Why Session Behavior Matters - Modern bots can execute JavaScript, operate real browsers, and pass individual CAPTCHAs. - Sustaining believable behavior over a complete session is substantially more difficult. - Precursor uses accumulated behavioral signals to improve detection precision. - This can reduce unnecessary challenges for legitimate users while increasing the cost and complexity of bot operations. ## Human and Automated Interaction Patterns - Human mouse movement reflects physical and cognitive constraints: - Wrist and forearm movement produce curved paths. - Clicking involves a delay after seeing an interface element. - Hand tremors create subtle physiological oscillations. - Automated interactions often reveal: - Straight-line movement or mathematically ideal curves. - Unusually precise clicks. - Repeated velocities, origins, timing, and movement rhythms. - Individual actions may appear plausible, but patterns across a full session can expose automation. ## How Precursor Works ### Injection and Data Collection - Cloudflare dynamically injects a compact, obfuscated JavaScript bundle into HTML responses passing through its network. - No additional configuration, third-party embedding, or network connection is required. - The script observes signals such as: - Pointer movement - Keyboard timing and activity - Focus changes - Page visibility - Events are serialized, buffered in memory, and periodically sent for analysis. ### Edge-Side Evaluation - Cloudflare deserializes the incoming data and runs multiple evaluators against the behavioral streams. - Evaluators cross-reference signals to identify inconsistencies. - Examples include checking whether: - Pointer activity matches page visibility duration. - Keyboard events occur while a text field is focused. - The results are consolidated into detection signals that influence bot scoring. ### Session Integration - Signals accumulate across the session rather than resetting with a page refresh or new challenge. - Session metadata also supports: - Shadow-mode heuristics - Session analysis - Predicted-versus-actual completion comparisons - Session delinquency heuristics - These observations help improve detection and adjust a session’s bot score. ## Privacy by Design - Precursor collects only information considered necessary for detecting automation and abuse. - Keyboard behavior is recorded as timing and rhythm, not the actual keys pressed. - Signals are evaluated as aggregate behavioral patterns. - Data is used internally by Cloudflare’s detection systems and is not exposed in customer dashboards or linked to accounts, identities, or persistent profiles. ## Session-Based Analytics - Cloudflare is introducing session-oriented views in Security Analytics alongside Precursor. - These views shift analysis from isolated requests to complete visitor journeys. - The provided article excerpt ends while beginning to describe these dashboards. Precursor is best understood as a complement to Turnstile: continuous, privacy-conscious session analysis can detect automation that passes individual challenges while reducing reliance on aggressive interruptions for genuine users.

security-analyticsjavascriptbot-managementbot-detection+3

cloudflareJun 8, 2026

Turning Cloudflare’s threat indicators into real-time WAF rules (opens in new tab)

Cloudflare now lets security teams turn live Threat Events intelligence into proactive WAF rules. Instead of manually blocking known malicious IPs, organizations can filter traffic by threat actor, targeted industry or country, attack type, and recency. The integration separates always-on detection from mitigation, allowing teams to validate intelligence before enforcing blocks without sacrificing visibility. ## Always-on Threat Detection - The system builds on Cloudflare’s always-on Attack Signature Detection framework. - Threat intelligence runs continuously in the background and enriches HTTP requests with metadata before a WAF action is taken. - This removes the traditional “log versus block” trade-off: teams can observe detections in analytics and later create blocking rules. - Cloudforce One subscribers can review threat actors, targeted industries, and traffic patterns before enabling mitigation. - Detection is designed to add negligible latency. - The initial release supports IP-based matching, with planned support for JA3 fingerprints and domain-based indicators to identify attackers who rotate IP addresses. ## New WAF Intelligence Fields Cloudflare exposes threat context through fields that can be used in WAF custom rules and rate-limiting policies: - `cf.intel.ip.attacker_names`: Known threat groups, such as `CRAVENFLEA`. - `cf.intel.ip.target_industries`: Industries previously targeted by the IP. - `cf.intel.ip.attacker_countries`: Countries associated with the threat event. - `cf.intel.ip.target_countries`: Countries targeted by the event. - `cf.intel.ip.datasets`: Intelligence sources or attack categories, such as `ddos` and `waf`. Because an IP may have multiple associated actors, industries, or datasets, these values are arrays. Rules use `any()` with the `[*]` wildcard to match individual values. ## Example WAF Rules - Block IPs involved in DDoS activity against France: ```text any(cf.intel.ip.target_countries[*] == "FR") and any(cf.intel.ip.datasets[*] == "ddos") ``` - Block BLACKBASTA-associated traffic targeting banking and financial services: ```text any(cf.intel.ip.target_industries[*] == "Banking & Financial Services") and any(cf.intel.ip.attacker_names[*] == "BLACKBASTA") ``` - Apply broad protection against traffic originating from Iran: ```text any(cf.intel.ip.attacker_countries[*] == "IR") ``` ## Deployment Through Existing Workflows - The fields are available in the WAF rule builder for custom rules and rate limiting. - Teams can configure them through the Cloudflare API or Terraform. - Rules can be automated across individual domains or an entire account. - Security Analytics records matches, including the triggered rule and the specific intelligence indicator involved. - Threat Events users can create Saved Views—such as IPs targeting the financial sector within the last seven days—and convert them into WAF rules with one click. ## Global Distribution and Performance - Cloudflare compresses threat intelligence datasets into a high-performance format. - The data is distributed to Cloudflare data centers worldwide. - The WAF can therefore evaluate threat indicators at the edge without requiring local IP lists or introducing significant request latency. - The post begins to describe this lookup process as O(1), but the provided content ends before explaining the implementation in detail. Cloudflare’s integration gives teams a practical path from threat intelligence to enforcement: investigate indicators, validate them in analytics, and deploy precise WAF or rate-limiting rules through the UI, API, or Terraform. Teams should use the always-on visibility to tune criteria before blocking, while preparing for future indicators such as JA3 fingerprints and malicious domains.

security-analyticsterraforminfrastructure-as-codethreat-intelligence+3

cloudflareMar 4, 2026

Always-on detections: eliminating the WAF “log versus block” trade-off (opens in new tab)

Traditional WAFs force teams to choose between broad visibility in logging mode and active protection in blocking mode. Cloudflare’s new always-on detection model separates attack detection from mitigation, allowing every signature to inspect traffic and provide metadata without immediately blocking requests. Attack Signature Detection is available in Early Access, while Full-Transaction Detection is planned to improve accuracy by analyzing both requests and responses. ## The Always-On Framework - Detection signatures run on every proxied request for opted-in customers. - Results appear in Security Analytics and are added to request metadata usable by custom security rules. - Detection is separated from mitigation: - Signatures identify suspicious traffic. - Security rules decide whether to block, challenge, or otherwise handle it. - This preserves visibility into all matching signatures, even when one detection leads to a mitigation action. - Initially, detections can run after the request is sent to the origin, avoiding added latency. - Once a blocking rule depends on a detection, that detection runs inline and may add latency based on the application’s traffic profile. - Bot Score and Attack Score already use this detection model. ## Attack Signature Detection - The system uses the same analytical heuristics as Cloudflare Managed Rules but does not directly apply traffic actions. - It covers attack types such as: - SQL injection - Cross-site scripting - Remote code execution - Specific CVEs - Cloudflare’s Managed Ruleset contains more than 700 active rules, with new rules generally released weekly and emergency rules released for major vulnerabilities. - Each signature has: - A unique Ref ID - One confidence level - One or more attack categories - Confidence levels indicate expected false-positive risk: - **High:** Designed for high true-positive rates and low false positives; comparable to default Managed Rules behavior. - **Medium:** More likely to cause application-specific false positives and should be assessed before blocking. ## Detection Metadata Attack Signature Detection exposes three fields in Security Analytics and the Edge Rules Engine: - `cf.waf.signature.request.confidence` - An array of confidence values for matching signatures. - `cf.waf.signature.request.categories` - An array of matched attack categories, such as SQLi or XSS. - `cf.waf.signature.request.ref` - An array of up to 10 matching signature Ref IDs. These fields let teams create precise policies based on observed traffic rather than relying on broad, manually tuned rules. ## Using Security Analytics for Onboarding - Detection begins collecting data as soon as an application is proxied through Cloudflare. - Teams can review aggregate matches by signature and attack category. - Analysts can compare matches against request outcomes, including: - Blocked requests - Cached responses - Requests delivered to the origin - If malicious traffic reaches the origin, teams can quickly create appropriate security rules. - Analytics also helps identify false positives and determine where exceptions are needed. ## Full-Transaction Detection - The planned system will analyze the complete HTTP transaction, including both request and response. - Correlating both sides should reduce false positives compared with request-only engines. - It may detect threats that request analysis misses, including: - Reflective SQL injection - Subtle data-exfiltration behavior - Dangerous misconfigurations visible only in responses The practical recommendation is to enable Attack Signature Detection during application onboarding, use its metadata and analytics to understand real traffic, and then create targeted mitigation rules. This preserves continuous visibility while allowing teams to deploy blocking protections with greater confidence.

security-analyticsweb-application-firewallcross-site-scriptingsql-injection+4