Cloudflare's BotBase and Precursor: Continuous Trust Evaluation for the Agentic Internet

Cloudflare just published the plumbing behind their shift from snapshot bot detection to continuous trust evaluation. The core change: instead of asking “is this request risky?” at a single moment, they now ask “how does this session behave over time?” Two named systems handle the work. BotBase builds behavioral fingerprints across sessions. Precursor analyzes cursor movement trajectories to distinguish humans from automation.

This matters because agentic tools blur the traditional bot/human boundary. Browser automation, RPA scripts, and AI agents all generate traffic that looks suspicious in a snapshot but legitimate over time. CDN providers need new detection primitives that don’t break good automation while still catching fraud, account takeover, and payment abuse.

The Architectural Shift

Traditional bot detection runs at request time. A CAPTCHA challenge fires when a single request crosses a threshold. The decision is binary: pass or block. State persists only as a short-lived cookie or IP reputation score.

Cloudflare’s new model separates detection from enforcement and introduces continuous scoring:

• BotBase maintains behavioral fingerprints per session, tracking patterns like request timing, header consistency, and interaction sequences.
• Precursor extracts features from cursor movement data (velocity, acceleration, pause patterns, trajectory smoothness).
• Trust scores update continuously as new signals arrive, feeding into rate limiting, challenge serving, and allow-listing decisions.

The API contract between detection and enforcement becomes stateful. Instead of “block this request,” the signal is “this session has a trust score of 0.42, apply policy tier 3.”

BotBase: Behavioral Fingerprinting Over Time

BotBase doesn’t look at individual requests. It builds a profile:

• Session continuity: Does the client maintain consistent TLS fingerprints, HTTP/2 settings, and header ordering across requests?
• Timing patterns: Are requests evenly spaced (bot-like) or irregular (human-like)?
• Interaction sequences: Does the session navigate like a browser (fetch HTML, then CSS/JS/images) or like a scraper (direct API calls)?

State persists in Cloudflare’s edge KV store, keyed by a combination of client fingerprint and session token. Each request updates the profile. The trust score adjusts based on deviation from expected human behavior.

Key difference from CAPTCHA: A single suspicious request doesn’t trigger a challenge. The system waits to see if the pattern continues. Legitimate automation tools (accessibility software, browser extensions, testing frameworks) often send one or two odd requests but then settle into predictable behavior. BotBase learns to tolerate those outliers.

Precursor: Cursor Movement as a Trust Signal

Precursor analyzes mouse trajectories. Cloudflare published an interactive demo (Precursor Trace simulation) where you can move your cursor and see how the system scores it.

Signals extracted:

• Velocity distribution: Humans accelerate and decelerate smoothly. Bots often move at constant speed or jump instantly.
• Pause patterns: Humans pause to read or think. Bots rarely pause unless explicitly programmed to.
• Trajectory smoothness: Human movements follow Bezier-like curves. Scripted movements often follow straight lines or grid patterns.
• Micro-corrections: Humans overshoot and correct. Bots hit targets precisely.

Precursor runs client-side JavaScript to capture cursor events, then sends compressed trajectory data to the edge. The edge service extracts features and updates the session’s trust score.

Handling legitimate automation: Precursor doesn’t auto-block low scores. Instead, it flags sessions for additional verification. A headless browser running Playwright might score low on cursor movement but high on BotBase’s session continuity checks. The combined score determines the enforcement action.

Integration with Enforcement Layers

Detection and enforcement are decoupled. Trust scores feed into multiple decision points:

Enforcement Layer	Low Trust Action	Medium Trust Action	High Trust Action
Rate Limiting	10 req/min	100 req/min	1000 req/min
Challenge Serving	Interactive CAPTCHA	Passive JS challenge	No challenge
Allow-Listing	Never cache	Cache for 60s	Cache for 3600s
API Access	Block POST/PUT	Allow GET only	Full access

The API contract is simple. Detection services publish trust scores to a shared state store. Enforcement rules subscribe to score updates and apply policies. This separation means you can tune detection sensitivity without redeploying enforcement logic.

Example flow for a suspicious session:

1. First request arrives with no history. BotBase assigns default trust score (0.5).
2. Precursor JavaScript loads, captures cursor data, sends trajectory.
3. Precursor scores trajectory as 0.2 (bot-like). Combined score drops to 0.35.
4. Rate limiter applies tier 2 policy: 100 req/min, passive JS challenge.
5. Session continues. BotBase sees consistent headers and timing. Score rises to 0.45.
6. After 50 requests with no violations, score reaches 0.6. Challenge removed.

State Management and Observability

BotBase and Precursor rely on edge-local state with eventual consistency:

• Session state: Stored in Cloudflare Workers KV, replicated across edge locations. TTL is 24 hours by default.
• Trust score updates: Computed locally at each edge node. Scores sync every 5 seconds to a global view.
• Observability: Trust scores, signal breakdowns, and enforcement actions log to Cloudflare’s analytics pipeline. Customers see aggregated metrics in the dashboard.

Failure modes:

• KV replication lag: A session might get different trust scores at different edge nodes for a few seconds. Enforcement policies handle this by using the most recent score available.
• Client-side JavaScript blocked: Precursor can’t run. BotBase still functions. Trust score relies entirely on server-side signals.
• State loss: If KV evicts a session early, the next request starts fresh. This is indistinguishable from a new session, so the system defaults to medium trust and rebuilds the profile.

Code: Simplified Trust Score Calculation

This is not Cloudflare’s actual implementation, but it shows the pattern:

// Edge worker pseudocode
async function handleRequest(request, env) {
  const sessionId = extractSessionId(request);
  const state = await env.KV.get(sessionId, { type: 'json' }) || { score: 0.5, signals: {} };

  // BotBase signals
  const headerConsistency = checkHeaderConsistency(request, state.signals.lastHeaders);
  const timingPattern = analyzeRequestTiming(request, state.signals.lastRequestTime);

  // Precursor signals (if available)
  const cursorData = request.headers.get('X-Cursor-Trace');
  const cursorScore = cursorData ? analyzeCursorTrajectory(cursorData) : null;

  // Weighted combination
  let newScore = state.score;
  newScore += (headerConsistency - 0.5) * 0.2;
  newScore += (timingPattern - 0.5) * 0.1;
  if (cursorScore !== null) {
    newScore += (cursorScore - 0.5) * 0.3;
  }
  newScore = Math.max(0, Math.min(1, newScore)); // clamp to [0,1]

  // Persist updated state
  state.score = newScore;
  state.signals.lastHeaders = request.headers;
  state.signals.lastRequestTime = Date.now();
  await env.KV.put(sessionId, JSON.stringify(state), { expirationTtl: 86400 });

  // Apply enforcement policy
  const policy = selectPolicy(newScore);
  return enforcePolicy(request, policy);
}

The key insight: trust scores are not computed from scratch on each request. They accumulate evidence over time.

Deployment Shape

Cloudflare runs this at the edge, not in a centralized cluster. Every edge node runs:

• Detection workers: BotBase and Precursor logic in V8 isolates.
• State store: Workers KV for session data.
• Enforcement workers: Rate limiting, challenge serving, and caching rules.

Traffic never hairpins to a central detection service. Latency stays under 10ms for trust score lookups. The trade-off is eventual consistency: a session might see slightly different scores at different edges for a few seconds.

Security Boundaries

BotBase and Precursor assume the client is adversarial. All signals are server-side or cryptographically verified:

• Cursor data: Sent over HTTPS, but not signed. An attacker can fake trajectories. Precursor treats this as one signal among many, not a sole decision factor.
• Session tokens: Signed JWTs issued by Cloudflare. Clients can’t forge session IDs to inherit another session’s trust score.
• Fingerprinting evasion: Attackers can rotate TLS fingerprints and headers. BotBase detects this as low session continuity and lowers the trust score.

The system doesn’t try to be perfect. It tries to make large-scale automation expensive. Faking a single signal is easy. Faking all signals consistently over hundreds of requests is hard.

Likely Failure Modes

1. False positives on accessibility tools: Screen readers and voice navigation generate unusual cursor patterns. Cloudflare mitigates this by not auto-blocking low Precursor scores and by allowing manual allow-listing.

2. Agent whitelisting arms race: Legitimate AI agents (search crawlers, monitoring bots) need to identify themselves. Cloudflare provides a verified bot list, but new agents must apply for inclusion. During the approval window, they might face challenges.

3. State bloat: High-traffic sites generate millions of sessions per hour. KV storage costs scale with session count. Cloudflare likely uses aggressive TTLs and sampling to limit state growth.

4. Score drift: If a session starts malicious but later becomes legitimate (shared IP, NAT gateway), the trust score might stay low. The system needs a decay function to forget old bad behavior.

Technical Verdict

Use continuous trust evaluation when:

• You operate at CDN scale and see diverse traffic patterns.
• You need to distinguish good automation (testing, monitoring, accessibility) from bad (scraping, fraud).
• You can tolerate eventual consistency in enforcement decisions.
• You have observability infrastructure to debug false positives.

Avoid it when:

• You need deterministic, instant blocking (use traditional WAF rules).
• Your traffic is low volume and you can manually review suspicious sessions.
• You can’t run stateful logic at the edge (no KV store, no Workers equivalent).
• Your threat model assumes attackers can’t sustain long sessions (in that case, snapshot detection is cheaper).

Cloudflare’s approach works because they control the edge platform and the state store. If you’re building similar logic on a third-party CDN, you’ll need to run detection in your origin and accept higher latency.

Source Links

• Cloudflare Blog: Unveiling good and bad behaviors on the Agentic Internet