Glossary

Terms used in the dashboard and /validate responses. Linked pages cover anything that needs more than a paragraph.

Decisions

Allow

An allow normally lets your backend serve the original content. It can also contain validator-owned response_html, such as managed robots.txt. In that case, serve the returned body, status, and headers.

A request with no policy action continues to configured bot detection. When monitor mode applies, a would-be block returns as allow with block_reasons. A redirect remains a redirect.

Block

The validator denied the request. Serve Centinel's block page from response_html with the returned status_code, which is 403 unless a policy rule or a tenant setting changed it.

Redirect

The validator can't decide from request data alone, so it returns an interstitial challenge. Serve response_html with the returned status_code, which is 403 by default. The browser runs the challenge and the next request continues. The dashboard labels this decision Challenged.

A redirect does not always mean a challenge. If you have configured a custom block page, a real block arrives as redirect carrying that page. Read status_code rather than inferring intent from the decision string.

Monitor

A rule setting, shown in the dashboard as Detect & log only. monitor: true applies to the whole request. Terminal blocks return as allow, but challenges still return as redirect. monitor: false does not disable monitor mode. See Policy Rules.

Rate limit

A rule setting that caps requests per scope. Over-budget requests are blocked with a rate_limit_exceeded reason and a retry_after value, delivered in-band on a 200 rather than as an HTTP 429.

Visitors

Crawler (identified)

Request's User-Agent matches a known crawler signature, like Googlebot or GPTBot. Identification alone does not prove the request really came from that crawler. See the crawler object for the full schema.

Crawler (verified)

An identified crawler whose source IP falls inside the operator's published IP ranges, which Centinel ingests and refreshes. A crawler whose operator publishes no ranges can only ever be identified by name, never verified.

Crawler (allowed)

A crawler you've placed on your allowlist. It passes through without scoring. The allowlist is a built-in policy rule that runs last, so any rule you write can override it. An identified crawler that is not on your allowlist is blocked by a matching built-in rule.

Stealth crawler

A bot that tries to look like an ordinary browser. The validator catches it by collecting browser signals and spotting inconsistencies. For real browsers controlled by automation tools (Selenium, Playwright, Puppeteer), see Automated browser.

How a check works

Challenge

A short, non-interactive test that the browser runs in the background. There is no CAPTCHA and nothing for the visitor to solve. After it completes, Centinel runs the full validation pipeline. A failed or absent upload can leave the session unverified.

Interstitial

The HTML page Centinel returns for an interstitial challenge. The browser runs the challenge and reloads the same URL. A custom block page can also use decision: "redirect", so do not identify an interstitial from the decision alone. See Interstitial Challenge for the full flow.

Browser script

The optional JavaScript Centinel serves from the collector host. It gathers browser and network signals that server-side data cannot see. Detection works without it on a smaller signal set. See Scripts.

Site key

Your public key, safe to expose. It identifies your organisation in the browser script URL.

Secret key

Your server-only key, sent as x-api-key when your backend calls /validate. Anyone holding it has full tenant access.

Session

A run of requests associated with the same _centinel cookie. When Centinel sets the cookie, it assigns Max-Age=86400 (24 hours). While the server-side session and cached verdict remain available, later validations reuse that verdict. If either item is missing or expired, Centinel can evaluate and challenge the visitor again.

Fingerprint

A composite signature of how the browser behaves at the network and JavaScript level. The validator compares it against what the User-Agent claims; a real Chrome should look like Chrome from every angle.

Block-reason categories

Header anomaly

HTTP headers are missing, contradictory, or shaped like a script rather than a browser. Real browsers send a consistent set of headers; bots and minimal HTTP libraries often don't.

Fingerprint mismatch

The request doesn't match what its User-Agent claims. This covers the TLS, TCP, and HTTP/2 layers, header order and client hints, and disagreements between the page and a Web Worker. For example, a request says it's Chrome but the network signature looks like Python or Go.

Bot identity

The request's User-Agent identifies it as a known bot or scraper HTTP client (such as python-requests or curl), and is not on your allowlist. An identified crawler that isn't on your allowlist also lands here, as crawler_blocked. See Crawler (allowed). Browser-automation frameworks like Selenium or Puppeteer fall under Automated browser instead.

Automated browser

A real Chrome or Firefox driven by Selenium, Playwright, Puppeteer, or a similar tool. They run JavaScript fine, but leave traces in the browser environment that the validator picks up.

Crawler impersonator

A request claims to be a well-known crawler like Googlebot, but its IP doesn't belong to that crawler's operator. Common in scrapers trying to bypass crawler-allow rules.

Suspicious network

Traffic came from a network type associated with abuse. Common sub-types you'll see in analytics:

• VPN — commercial VPN service. Legitimate users do use VPNs, so this is a signal weighed with the others, not an automatic block.
• Datacenter (DC) — IP belongs to a cloud or hosting provider. Most consumer traffic doesn't originate from datacenters; bots often do.
• Proxy — open or commercial HTTP proxy. Frequently used to mask the origin of automated traffic.
• Tor — a Tor exit node. Anonymity network with mixed legitimate and abusive use.
• IP reputation — the address is a known anonymizer, hosting range, abuser, or is blacklisted.
• Rate limit — the request exceeded a rate-limit rule. Filed here even though it isn't a network signal.

Challenge failure

The session got an interstitial and never cleared it. Several things produce this: the challenge failed, the verification was invalid, or the visitor abandoned the page, and there are timeout and payload variants too.

One case is on your side. If your backend serves the interstitial but drops the cookies from the /validate response, the challenge cannot be won and the request fails closed with interstitial_no_session.

Unknown

A block reason Centinel hasn't grouped into a category yet. Rare. Read the raw block_reasons value to see what actually fired.

See also