The evidence Checkpoint checks, hardest to forge first, what each kind can and cannot prove, and how it becomes a class, a confidence, and a risk score

Every surface, from the DNS gateway to the SDKs and the Pixel, Beacon, and API routes, runs the same detection engine. It looks for proof first, falls back to heuristics, and records which kind of evidence it used, so you can tell an agent that proved its identity from one that only claims a name.

The evidence, hardest to forge first

Evidence	What the engine checks	What it proves	What it cannot prove
Vendor signature	RFC 9421 signature and `Signature-Agent` against the vendor's key	The vendor's key signed this request	Who it acts for, or that you allow it
KYA-OS identity	A signature by its DID's key, then any delegation	The agent holds its DID's key, and who granted it what	That your policy allows what was granted
Vendor network	Client IP in published ranges, plus the matching user agent	The request came from that operator's addresses	What the request is for
TLS fingerprint (JA4)	The TLS handshake against known non-browser stacks	A browser user agent came from a non-browser client	Who the client is
User agent and headers	Agent, crawler, and tool tables, and browser headers	Only what the client claims	Who sent the request
Behavior	Automation flags, interaction, and request rate	Disclosed automation, or bot-like volume	That a quiet client is human

Cryptographic proof

Vendor signatures. Some agents sign each request with HTTP Message Signatures and name themselves in the Signature-Agent header from the Web Bot Auth draft. The engine needs Signature, Signature-Input, and Signature-Agent together and checks them against a reviewed copy of the vendor's published key compiled into it, so the engine fetches nothing; the DNS gateway also checks a daily-refreshed copy of the vendor's key directory. The only vendor today is OpenAI, for its ChatGPT agent. A signature fails when Signature-Agent names a different vendor than the key, when it has expired, or when its created time is more than five minutes off the engine's clock. A verified request is classified ai_agent.

A failed signature earns no trust and blocks nothing by itself: the request falls through to the checks below, and the result records why.

KYA-OS identity. A KYA-OS agent signs with the key its DID names (did:key or did:web), in a signature that is valid for at most 300 seconds and, when the request has a body, covers it. It can also present a delegation credential, a signed grant from a user or organization; the engine checks the issuer's signature on it, that it names this agent and this site, its expiry, its scopes, and whether it was revoked. KYA-OS requests over MCP connections (MCP-I) get the same DID, signature, revocation, expiry, and scope checks. See KYA-OS Enforcement and Delegations.

The assurance field records the strongest identity proof: key-bound for a KYA-OS DID signature, delegated when a delegation verifies on top of it, and anonymous for a vendor signature, which proves the vendor but binds no user.

Network evidence

Vendor IP ranges. The engine compiles in 17 vendor IP feeds from eight operators: OpenAI, Anthropic, Perplexity, Google, Microsoft Bing, Apple, Common Crawl, and DuckDuckGo. A match needs both the client IP inside a feed's ranges and a user agent published with that feed. It is only as good as the client IP your integration resolves: behind a load balancer, set a trust profile.

An address in a /8 block that AWS, Google Cloud, or Azure holds is weak evidence only: a coarse match, not a published range, so it never names an agent.

The engine makes no network calls, so reverse DNS plays no part in the verdict. Checkpoint uses it only to confirm Googlebot and Bingbot before reporting a visit to the KnowThat.ai registry as network-verified.

TLS fingerprint. A client whose user agent claims a browser but whose JA4 fingerprint matches a known non-browser stack (Go, Python, Node.js, Java, curl, or OpenSSL) is classified bot. A JA4 alone decides nothing: it only contradicts a user agent, and an HTTP/2 fingerprint matching no known browser strengthens that. JA4 reaches the engine from the DNS gateway, or from your own edge with Forward edge evidence.

User agent and headers

The engine matches User-Agent against tables of AI agents, AI crawlers, search engines, automation tools, and developer tools, and flags requests missing several headers every browser sends. A user agent names an agent but proves nothing: anyone can send ChatGPT-User. By default, a user-agent match never blocks on its own; your policy decides.

Behavior

The Pixel and Beacon report what the browser shows: automation flags such as navigator.webdriver, headless tells, interaction (mouse, clicks, scrolling), and the viewport. A browser that discloses automation through navigator.webdriver is classified bot. These reports come from the client, so they can only raise suspicion: a missing tell never makes a request look more human.

On the server, a client that sends at least 150 requests at 120 or more a minute is reclassified as bot, unless it matched a vendor. Only the DNS gateway, the Pixel and /detect routes, and the .NET and Java SDKs measure this rate.

How the evidence becomes a verdict

Class is one of human, ai_agent, bot, or incomplete_data (see Detection Classes). A named crawler such as GPTBot is bot, even when its IP is in OpenAI's published ranges. No agent evidence yields human or incomplete_data at low confidence, which means nothing matched, not that a person did.
Confidence (0 to 100): a verified signature sets it to 99 or 100. Otherwise the engine combines every signal with a Noisy-OR formula, so weak signals add up instead of the strongest one winning, then maps the result through a curve that ships with the engine. It is a score, not a measured probability; Confidence Scores has the bands.
riskScore (0 to 1) is the combiner's raw output before that curve, reported with riskScoreSource: "uncalibrated".

Your policy then decides what happens: verification identifies the caller but never authorizes it, so a verified signature still goes through your policy. The Response Object documents every field.

How Checkpoint verifies agents