What is Detect?

Checkpoint Detect provides passive AI agent detection for your web applications. Unlike Enforce, Detect methods identify and classify traffic without blocking or redirecting visitors. Use Detect to build analytics, understand your traffic composition, and gather intelligence before deciding on an enforcement strategy.

Every detection returns:

A classification of the visitor: human, ai_agent, bot, or incomplete_data
A confidence score from 0 to 100
Metadata: for agent/bot traffic, the detected agent's name (detectedAgent.name), plus verificationMethod and riskLevel (human results carry no detectedAgent)

Marketing Pixel

Lightweight, no-code AI agent detection for analytics and marketing teams.

Beacon

Full-featured client-side signal collection, with optional Web Worker offloading.

Detection Methods

Checkpoint offers four detection methods. This table covers only what each method detects and how; to decide which integration fits your stack, see Choose Your Integration.

Method	Where It Runs	What It Sees	Latency
Pixel	Browser (script tag)	JS-executing browsers, page-load signals	Async, non-blocking
Beacon	Browser (npm SDK)	JS-executing browsers, richer browser/performance signals	Async, non-blocking
Middleware	Your server (Node.js, .NET, JVM)	Every request reaching your server	Inline, before your handler
Gateway	Cloudflare edge (DNS)	Every request to your domain	Inline, before your origin

Middleware and Gateway detect and enforce, using the same policy engine, so they're documented once (under Enforce) instead of being split across two sections. Running either detection-only is simply a matter of leaving it in observe mode; see Enforce vs. observe.

What Each Method Can See

Each method's visibility into a request is fixed by where it runs: that's the detection-relevant difference. (For which method fits your stack, see Choose Your Integration.)

Pixel and Beacon: client-side signals only

Both run in the browser and only see what a JS-executing client can observe: page-load timing and browser/performance signals (Beacon also lets you send custom events). Neither has access to raw HTTP headers or TLS-layer data on its own, and both are invisible to traffic that never executes JavaScript. If your CDN proxies their requests, it can add the visitor's TLS fingerprint: see Forward edge evidence.

Pixel guide → · Beacon guide →

Middleware: server-side headers, no TLS fingerprint

Middleware runs in your server process (Node.js, .NET, or the JVM), after TLS termination. It sees every header on every request that reaches your server (User-Agent, Accept, Language, cookies) plus request-pattern signals, but not the TLS fingerprint: that's captured only at the edge, before the request reaches server-side code. See Detection Signals.

See Middleware setup.

Gateway: headers plus a TLS fingerprint

The Gateway runs at Cloudflare's edge, ahead of your origin. Alongside the same header and request-pattern analysis available to Middleware, it's the only method that captures the client's TLS fingerprint: see Edge Detection. A browser User-Agent sent from a TLS stack that only non-browser software uses is classified as automation and flagged ua-tls-mismatch.

See Gateway setup.

Detection Classes

Every detection is assigned one of four classes:

Class	Value	Description
Human	`human`	Regular browser traffic from a human visitor
AI Agent	`ai_agent`	AI assistants like ChatGPT, Claude, Perplexity, Gemini
Bot	`bot`	Web crawlers, scrapers, and automated tools (Googlebot, Bingbot)
Incomplete Data	`incomplete_data`	Insufficient signals to make a confident determination

This page is the canonical reference for what these classes mean and how confidence is scored. For how the engine produces them (signals, scoring internals, edge vs. server mechanics), see Detection in Enforce Mode.

Confidence Scores

Confidence scores range from 0 to 100, in four levels:

Range	Level	Meaning
91–100	Very high	Strong signals.
71–90	High	Solid evidence.
31–70	Medium	Moderate evidence; some indicators present but not conclusive.
0–30	Low	Weak or no signals.

Confidence measures how strongly the evidence indicates automation, not how certain Checkpoint is of the assigned class (see Reading the object). A human verdict from the Gateway, SDK middleware or the API therefore carries a low score: little evidence of automation, which is not proof of a person. The Pixel and Beacon score a human verdict from the in-browser evidence they collect, so compare scores within one surface (see Detection Semantics).

Combining Detection Methods

You can use multiple detection methods simultaneously. For example:

Pixel on your marketing site for traffic analytics
Beacon in your authenticated application for detailed event tracking
Middleware on your API routes for server-side detection with enforcement

Each method sends data to the same Checkpoint project, giving you a unified view in the dashboard.

Next Steps

Marketing Pixel: lightweight, no-code detection
Beacon: full-featured client-side SDK
How Checkpoint verifies agents: the evidence behind each verdict, and what each kind can prove
Set up browser posture: let your server verify a signed token for a browser session
Enforce: add blocking, redirects, and policies to your detection

Detect

Marketing Pixel

Beacon

On this page