THE SHORT VERSION

Start with Minimize Friction, scope stricter verification to the few browser paths that need it, and review the privacy and API consequences before enabling it broadly.

Update — August 12, 2026: Cloudflare now documents two operating modes, path-level Precursor Rules, API caveats, and its interaction with the cf_clearance cookie. This is a deployment decision, not simply a new bot-score input.

Cloudflare Precursor is a client-side, session-based verification system. Instead of judging one request or one challenge, it continuously evaluates behavior as a visitor moves through an application. The intent is to find automation that can look plausible in an isolated browser request but becomes less convincing over a complete journey.

That can strengthen bot defenses, but the control sits in the browser and changes the session state that other parts of an application may rely on. Treat it as a security-and-product change with an explicit rollout owner.

What changes in a visitor session

Precursor injects a client-side script, collects signals repeatedly, evaluates them, and updates session state in the cf_clearance cookie. Cloudflare’s launch material describes signals such as pointer movement, keyboard activity, focus, and page visibility; it says keyboard content is not collected. The system is therefore about interaction patterns, not a one-time proof that a browser exists.

The important operational implication is that a clearance established earlier in the visit may be reduced, invalidated, or followed by another challenge. A successful page load does not guarantee that the rest of the session will remain untouched.

Choose the enforcement boundary deliberately

Minimize Friction, the default mode, attempts to establish session state without an interstitial challenge. Maximize Security can show a lightweight challenge to establish a valid session before a visitor proceeds. Cloudflare also allows rules that select the mode by request, so a site can keep low-friction coverage broadly and require stronger verification only on an account, payment, or other sensitive path.

Do not use that flexibility as a reason to enable strict verification everywhere. Identify the browser journeys where abuse causes material harm, name the excluded paths, and decide which team can change the rule during an incident. A broad rule is easy to activate and much harder to diagnose when it affects conversion or support volume.

Separate browser traffic from machine traffic

When Maximize Security is in effect, requests need a valid cf_clearance cookie. That can break command-line clients, mobile backends, server-to-server jobs, and browser requests that omit cookies. Cloudflare’s documented patterns are to begin with Minimize Friction and make only sensitive paths strict, or to exempt API paths and hostnames with a rule.

Inventory those callers before rollout. For browser fetch or XHR that must reach a protected endpoint, verify that credentials are intentionally included. For non-browser integrations, prefer a scoped exception over silently discovering the dependency from production failures.

A pilot that produces a decision

Run the initial cohort on a bounded high-abuse flow and compare it with a baseline: confirmed abuse, challenges issued and solved, false-positive appeals, completion rate, client-side errors, page performance, and support contacts. Review the results by device, geography, accessibility path, and login state; an aggregate improvement can conceal a costly failure for one audience.

At the same time, have privacy and legal owners evaluate the added behavioral measurement against the site notice, consent model, retention expectations, and Cloudflare agreement. The question is not whether fraud prevention matters. It is whether this specific continuous collection and enforcement path is proportionate, disclosed, and reversible.

Sources and reporting notes

This article explains the practical implications of the primary material below. PatchMemo does not publish vendor copy as editorial coverage and does not accept payment for positive coverage.

Editorial independence

PatchMemo independently selects and evaluates the topics it covers. Analysis and recommendations are ours; sources are linked so readers can check the underlying claims. We clearly label sponsorships and affiliate relationships, and neither determines coverage or conclusions.