Detecting Rogue AI Agents: Cloudflare Precursor Threat Model

I spent the first week of August running an internal red team against our own public API, treating the third-party agent traffic the same way I would treat a credential-stuffing wave. The result surprised me: a substantial fraction of the third-party traffic that was clearly agent-driven — same session, same tool catalog, same model identity — was indistinguishable from human browser traffic on every server-side signal I had. Same TLS fingerprint, same JA3 hash, same request timing, same header order. The agents had been built by teams that had solved the wire-level identity problem by exactly the technique Cloudflare's bot management team described in their July post on Precursor: by routing the agent through a headful browser instance and letting the agent inherit the browser's native fingerprint. The agents were not bypassing my detection — they were not generating any signal my detection could catch. The detection was looking at the wrong layer.

This guide is the reverse-engineering I did after that experiment. It is a practitioner's walk through Cloudflare Precursor's threat model, the five client-side signal categories Precursor uses, the open-source stack to add the same signals to your own product without buying Cloudflare Bot Management, and the inverse problem — how to make your legitimate agents look less like bots when calling third-party APIs that have their own Precursor-style detection in place. The server-side detection era is ending. The client-side behavioral signal era has begun. The agent fleets I have helped instrument in 2026 have all had to face this shift. The framework below is the floor I have converged on.

Why server-side signals fail against the modern agent fleet

The natural assumption behind most anti-bot systems is that an automated client can be identified by the shape of its traffic. The assumption was correct for the first decade of the category: headless browsers sent User-Agent strings that named themselves, scripted HTTP clients sent headers in alphabetical order, request timing was either too fast or too regular, and JA3 / JA4 fingerprints betrayed the underlying TLS library. Every one of those signals is now under the agent fleet's control.

The OpenAI Operator release in January, Anthropic's Computer Use in October 2025, the Browser-Use open-source release in November, the multi-modal VLM wave in the first half of 2026 — every one of these systems ships an agent that runs against a real browser instance. The agent's traffic is the browser's traffic. The agent inherits the browser's native TLS fingerprint, the browser's header order, the browser's request timing, and (most importantly) the browser's rendering engine quirks. The signature-based detection layer that every WAF had built between 2015 and 2024 fails against this traffic by construction. The agents do not need to spoof the fingerprints — they are the fingerprints.

This is the architectural claim Cloudflare's Precursor post makes: detection has to move to the client because agents are now indistinguishable from humans on the wire. The wire is not where the signal lives anymore. The signal is in how the client behaves, not what the client sends. And the behavior is observable only at the client, because the behavior is the part the agent fleet does not yet know how to fake — at scale, in real time, against a fleet that updates its behavior faster than the detector can update its rules.

The five client-side signal categories Precursor uses

Cloudflare's Precursor post names five categories of client-side signals that, taken together, distinguish human browser behavior from automated browser behavior even when the automated browser is running a modern VLM agent against a real Chrome instance. The five categories are not a list of checks — they are a list of shapes the signal can take. Every signal inside a category is a feature the detection model can score. The categories:

Pointer dynamics. The trajectory, velocity, acceleration, and click-pressure profile of the mouse cursor as it moves between targets. Human cursor motion is non-linear: it follows a Fitts's Law ballistic arc with sub-movements at the target, with a hesitation pause before clicks, and with overshoot-and-correct on small targets. VLM-driven agent cursor motion (in the systems I have tested) is either straight-line or curved-path with no sub-movements. The shape of the trajectory is the signal, not the speed or the destination. Precursor scores the trajectory per-target, not per-session, because a single page can host many human cursors and many agent cursors simultaneously.
Scroll, attention, and focus events. The sequence of scroll bursts, the dwell time per scroll position, the focus and blur events on input fields and document iframes, and the visibility-change events when the tab moves to the background. Human scroll behavior has a characteristic burst-then-dwell-then-burst shape — the reader scrolls into a paragraph, dwells on it, scrolls a bit more, dwells again. Agent scroll behavior (in the systems I have tested) is either monotonic to the target element or jumps directly to the target. The dwell-time distribution per scroll position is the signal.
Timing distributions. The inter-event timing distribution at the sub-second resolution. Humans have a characteristic reaction-time distribution centered around 200-300ms with a long tail of longer pauses; agents either fire events too quickly (sub-50ms) or fire them with too-uniform a distribution. The metric Precursor uses is the coefficient of variation of the inter-event interval — a single number that captures how bursty the timing is. Human timing is bursty. Agent timing is metronomic.
JS execution patterns. The JavaScript call graph the page executes as the client interacts with it. A real browser executes the page's event listeners, the framework's reconciliation passes, and the third-party analytics scripts in a characteristic interleaved order. An agent-driven browser either skips the analytics scripts, executes them in a different order, or executes them in the same order but at different intervals. The signal Precursor uses is the call-graph entropy — the number of distinct code paths the browser executes per second as the user interacts with the page.
Cross-modal sensor fusion. The combination of pointer, scroll, focus, timing, and JS signals into a per-session behavioral vector that the detection model scores. No single signal is decisive — a fast human looks like an agent on pointer velocity alone, and a careful agent looks like a human on timing alone. The signal is in the joint distribution across all five categories, per session, per target. This is the part Precursor explicitly does not publish — the model is the moat.

For a team that is building detection in-house, the categories above are the surface area to instrument. For a team that is building agents and worried about their agents looking bot-like to third-party APIs, the categories above are the surface area the agent fleet will eventually be scored against. The arms race is now at the behavioral-vector layer, not at the wire layer. The detection systems that catch the next wave of agents will not be looking at JA3 hashes — they will be looking at the curvature of the cursor trajectory.

How to add Precursor-style instrumentation without buying Cloudflare Bot Management

The open-source stack to add Precursor-style client-side behavioral instrumentation to your own web or API product is, as of August 2026, still thin. Cloudflare's Precursor is closed-source and ships only as part of Cloudflare Bot Management. The categories above are public; the model is not. The path I have used with two teams in 2026 is to build the instrumentation layer in-house against the categories, score the behavioral vector against a labeled corpus of human and agent traffic, and either run the detector yourself or hand the feature vector to a downstream model.

The instrumentation layer is straightforward. The five categories above reduce to a set of JS event listeners on the page, plus a small server-side scoring pipeline:

Pointer dynamics. Capture mousemove, mousedown, mouseup, and pointermove events on the document, with timestamps at sub-millisecond resolution. Compute per-target trajectories, per-target sub-movement counts, per-target click-pressure profiles, and per-target overshoot rates. The trajectory features are the highest-signal subset — a 12-feature vector per cursor-target pair is enough to score against a labeled corpus.
Scroll, attention, and focus. Capture scroll, focus, blur, visibilitychange, and resize events. Compute per-page scroll-burst durations, per-input focus durations, and the visibility-change histogram. The visibility-change histogram is the cheap signal — a tab that is never backgrounded has a different profile from a tab that is constantly backgrounded as the user multitasks.
Timing distributions. Already captured as the timestamps on the events above. Compute the inter-event interval distribution and the coefficient of variation per session, per target, per page. The metric is a single number per session, but the per-page breakdown is what catches the agent that alternates between fast human-like navigation and fast agent-like extraction.
JS execution patterns. Capture the call stack at each mousemove and scroll event (using PerformanceObserver with the longtask and event entry types). Compute the call-graph entropy per second as the user interacts with the page. The instrumentation is browser-native; the scoring is the part that needs a labeled corpus.
Cross-modal sensor fusion. Concatenate the per-session feature vectors across all four categories above into a single behavioral vector. Score the vector against the labeled corpus with a lightweight gradient-boosted model (the model is small enough to run on a single CPU core per session). The model is what catches the joint distribution that no single category can.

The instrumentation adds roughly 8-15 KB of compressed JS to the page payload, fires events on a 50ms debounce, and ships a feature vector to the server at session end (or in real time if the page is interactive enough to need mid-session intervention). For most pages, the overhead is under 1% of the total page weight. The hard part is not the instrumentation — it is the labeled corpus. A team that does not have a labeled corpus of human-vs-agent traffic against their own product cannot train a model that generalizes. The first 30 days of an in-house Precursor-style project is data collection, not modeling.

The inverse problem: legitimate agents looking less like bots

The arms race is bidirectional. If third-party APIs are starting to score against the behavioral categories above, the legitimate agents I have helped build in 2026 are being scored too — and a poorly-tuned agent will be flagged as a bot. The problem is worse for legitimate agents than for malicious agents, because legitimate agents have a stable identity (they sign their requests with their agent SBOM) and they have to operate within the third-party's rate limits. A flagged legitimate agent loses its identity and has to re-authenticate; a malicious agent rotates its identity and resumes.

The mitigation is twofold. First, the agent should be behaviorally honest: its cursor motion, scroll pattern, timing distribution, and JS execution should reflect what a human user would have done on the same task. A browser-driving agent that extracts a price table does not need to scroll past it — a human user would have scrolled past it. Adding a small random delay between the cursor's arrival at the target and the click is a single line of code that closes the largest behavioral gap. The agents that have shipped with this pattern in 2026 have had the lowest false-positive rate against the third-party Precursor-style detection systems I have seen.

Second, the agent should carry an attestable identity that the third-party can verify out-of-band. Cloudflare's Verified Bots program is the existing reference; agents that are on the program are scored against a different (more permissive) behavioral baseline than agents that are not. The analog for the open web is the robots.txt + agent SBOM attestation pattern that the agent security posture guide walks through: the agent ships a signed SBOM, the third-party API verifies the SBOM, and the behavioral detector applies a different scoring threshold to attested agents. The pattern is the same OAuth 2.0 token-exchange layer that the MCP enterprise authorization guide covers, applied to the agent as the subject.

For teams building agents that need to call a wide range of third-party APIs without being flagged, the practical path is: (a) ship the agent through a headful browser instance with a real cursor, (b) add behavioral honesty to the agent's interaction layer, (c) ship a signed SBOM with the agent, and (d) maintain a per-third-party behavioral profile that the agent's interaction layer adapts to. The pattern is not standardized in 2026 — every team I have helped is building it themselves — but the floor is converging across the category. The Cloudflare Workers mcp-server-proxy template is the closest existing reference for the proxy layer that carries the SBOM + the behavioral profile to the third-party API.

What the framework does not solve

Two things the framework deliberately does not solve. The first is the adversarial agent problem: a malicious agent operator can take a recorded human session and play it back as a behavioral trace, with the cursor motion, scroll pattern, and timing distribution replayed from the recording. Precursor-style detection can catch this (the JS execution pattern is hard to fake from a recording) but the threshold is not zero — there is a residual false-negative rate. The framework assumes the detection is probabilistic, not deterministic. The mitigation is the layered defense: behavioral scoring plus SBOM attestation plus rate limits plus audit logging. None of the four layers is decisive on its own; the four together are decisive enough to make the attack uneconomic.

The second is the privacy problem. Client-side behavioral instrumentation is, by definition, observing the user's cursor and scroll behavior. The instrumentation has to be designed for the user's consent: opt-in, minimal data, no cross-site correlation, no third-party sharing. The instrumentation the framework above describes is the floor for the signal — the ceiling is a privacy-preserving variant that runs the scoring entirely in the browser and ships only the verdict to the server. The privacy-preserving variant is technically feasible in 2026 (the model is small enough to run in a Web Worker) but it is not yet the default in the open-source tooling. For a team that is rolling the framework out today, the privacy review is the part that takes the longest to land, not the instrumentation.

For the broader category posture — the cross-team, cross-vendor, cross-cloud view — the framework is the floor. The ceiling is Agent Trust & Verification as a product category, which is the vendor space that has emerged in the second half of 2026 and which sits adjacent to the agent security posture discipline. The floor is the five signal categories plus the SBOM attestation plus the privacy-preserving instrumentation. The ceiling is the product category that aggregates the five into a trust score.

Open questions I am still tracking

Three open questions that will shape the next 12 months of Precursor-style detection. I do not have answers for them yet — these are the questions I am probing with the teams I help, and I will write the answer when the evidence is in.

What is the right retention window for the behavioral feature vectors? A session's behavioral vector is sensitive — it is a fingerprint of how the user moves their cursor and scrolls. The vector should be retained only as long as the detection needs it, but the operational answer depends on how the downstream model uses the vector. For real-time scoring, retention is zero (the vector is consumed at session end and discarded). For batch re-training, retention is 30 days. For forensic investigation, retention is 6 months. The framework above does not converge on a default.
How do I reconcile Precursor-style detection with EU AI Act risk classification? The EU AI Act treats an agent that scrapes a website at scale as a high-risk system if the scraping is "systematic" — and the behavioral instrumentation above is exactly what would prove the scraping was systematic. The framework above makes the agent more detectable; the same instrumentation makes the operator more accountable. The reconciliation is not yet in the regulation, but it is the obvious next front.
What is the right posture for agents that need to look like humans for a legitimate reason? An agent that calls an accessibility API to navigate a website for a user with motor impairments is, by definition, generating cursor and scroll behavior that is not the user's. Precursor-style detection would flag the agent as bot-like. The mitigation is the same SBOM attestation layer, but the policy floor for accessibility-driven agents is different from the floor for autonomous-checkout agents. The framework above carries the field but does not yet specify the policy differentiation.

Cloudflare Precursor establishes that agent detection is now a Cloudflare-scale problem with Cloudflare-grade R&D behind it. The shift from wire-level signals to client-side behavioral signals is the same shape of shift as the move from TLS fingerprinting to JA4 — it is a one-way move to a higher-fidelity layer. The teams I have helped in 2026 that have shipped agent fleets are the ones that have understood the shift early. The teams that have not are the ones that are going to be surprised in the next 90 days. The five signal categories above are the floor. The agent SBOM attestation is the next floor up. The privacy-preserving variant is the ceiling. The work is to ship the floor first.