Core Concepts

Checkpoint is easier to use — and much more valuable — once you hold the right mental model. This page covers the concepts that everything else builds on. If you only read one docs page before deploying, make it this one.

The three pillars

Every Checkpoint feature, dashboard surface, and package belongs to one of three pillars:

Detect sees, Enforce decides, Govern trusts. The pillars compose: detection facts feed policy decisions, and policies can require the cryptographic identity that Govern manages. A team that only uses Detect gets analytics; adding Enforce turns those analytics into control; adding Govern turns blunt blocking into fine-grained authorization.

A detection is not a verdict

The two words that matter most in Checkpoint are easy to conflate:

• A detection is the engine's read of who the visitor is: a class — human, ai_agent, bot, or incomplete_data — plus a confidence score (0–100) and the signals that produced it.
• A verdict is the policy engine's decision about what to do: ALLOW, BLOCK, REDIRECT, CHALLENGE, or INSTRUCT.

Detection feeds policy evaluation; policy produces the verdict. Nothing is ever blocked by a detection alone — if a request you expected to be blocked went through, the first place to look is your policy and enforcement mode, not the detection engine.

Signals sit on a trust ladder

Detection signals are not created equal. It helps to think of them as rungs on a ladder:

The bottom rungs are claims; the top rung is proof. A valid signature verifies against the agent's published key and yields a 100-confidence, verified detection. This ladder explains why confidence scores exist, why well-behaved agents identify themselves cryptographically — and why the INSTRUCT verdict is special.

INSTRUCT: stop guessing, demand proof

Most enforcement actions respond to what detection guessed. The INSTRUCT verdict is different: it returns a WWW-Authenticate: KYA challenge — see Verdicts for the exact status code on each enforcement surface — that tells the agent to come back with verifiable cryptographic identity. The challenge is dual-audience — a plain-English message any LLM can follow, plus a machine-readable block for KYA-OS-aware agents.

Signal-based detection can be evaded by a determined agent; a signature requirement can't. A request routed through a proxy carries the proxy's identity, not the agent's, and fails the challenge. INSTRUCT moves you off the top of the trust ladder's cat-and-mouse game entirely: instead of "we think this is ChatGPT," the question becomes "prove who you are."

Every runtime verifies INSTRUCT in-process — Gateway and every middleware SDK alike — so it doesn't require the Gateway to be deployed. See KYA-OS Enforcement for the full challenge flow.

Observe first, then enforce

Enforcement mode is a separate switch from what your policy says:

• Observe — every policy is fully evaluated, every verdict is recorded ("Would have been: Block"), and every request passes through. Middleware surfaces the outcome in X-Checkpoint-Would-Have-Been headers.
• Enforce — verdicts take effect: allowed requests reach your origin, blocked ones are rejected, redirected ones are sent elsewhere, and challenged or instructed ones must satisfy a consent or identity check before proceeding. See Verdicts for the exact HTTP shape each verdict produces per enforcement surface.

The recommended rollout is always observe-first: deploy in observe mode, watch the dashboard for a week or two, review the verdicts and confidence distributions, then flip to enforce once they look right. You get full visibility with zero risk of blocking a legitimate visitor — including delegated agents acting for your own customers — before your policy is tuned.

Two ways to enforce

Checkpoint enforces through two mechanisms, and which one you use determines which features you have:

Policies are Cedar either way, so you can start on one lane and add the other later. See Package Selection for choosing an integration path.

Policies carve out from allow

Checkpoint policies use an allow-by-default, carve-out posture. The baseline permits all traffic; each rule you add is a forbid that carves out a stricter verdict for the requests it matches, and when rules overlap, the restriction wins. You never enumerate the traffic you want to let through — a policy reads as "allow everything, except…".

Rules match on facts the engine supplies: the request path, the detected agent's name and category, its reputation, whether it presented a verified delegation, and which consent scopes it holds. The canonical pattern that joins Enforce to Govern is a category-level forbid with an unless carve-out for verified delegations — unknown scrapers get blocked while authorized agents pass. See Policies for the full authoring guide.

Where identity comes in

Everything above works without agents ever proving who they are. The Govern pillar adds the last two concepts that change what Checkpoint is:

1. Identity without shared secrets — agents hold DIDs backed by keypairs they generate themselves, so verification never depends on a distributable secret.
2. Identity ≠ permission — being a recognized agent grants nothing by itself; authority comes from delegations with explicit scopes, expiry, and revocation.

Read Identity, Delegation & Proofs next for why that design was chosen, and Security Model for how it holds up against real attacks. If the surrounding product and protocol names are the confusing part, The Ecosystem maps which name means what.