Every Checkpoint and KYA-OS term, disambiguated — including the names that are easy to confuse

Terms are grouped by what you're doing: naming things, reading detections, writing policy, or reasoning about identity. If two terms look interchangeable, check Commonly confused terms at the bottom — the collisions are called out explicitly.

Products & names

Term	Meaning
Checkpoint	The platform: AI-agent detection, enforcement, and identity-based governance.
AgentShield	Checkpoint's former name (legacy). Survives in the legacy `@kya-os/agentshield-` packages, some `AGENTSHIELD_` environment variable names, and a few cookie/global aliases kept for back-compat. New integrations use `@kya-os/checkpoint-*`.
KYA-OS	"Know Your Agent — Operating System." The open identity protocol (DIDs, verifiable credentials, and delegation on top of MCP) that Govern implements, plus the `@kya-os/*` npm scope.
KnowThat.ai	The company behind Checkpoint. As a URL, knowthat.ai is the public agent registry — profiles, claiming, reputation.
MCP-I	The KYA-OS protocol's former name (legacy). Survives only in published package names (`@kya-os/mcp-i`), which cannot be renamed; in prose, URLs, and UI, say KYA-OS.
Bouncer	Checkpoint's delegation, consent, and proof-verification subsystem (the Govern tier's engine; `@kya-os/bouncer-middleware` on the origin side).
Gateway (edge)	The DNS/CNAME reverse proxy that runs detection and enforcement on web traffic. See Gateway.
MCP Gateway	The org-level Govern surface (also "Agentic Hub") that authorizes agent tool-calls to MCP servers. A different system from the edge Gateway.
Beacon	The full client-side JavaScript detection SDK (`@kya-os/checkpoint-beacon`). See Beacon.
Pixel	The lightweight, no-code variant of the beacon (Google Tag Manager template). See Pixel.
Compose	The plain-language → Cedar policy authoring flow, with dry-run against real traffic. See Policies.
Cedar	The open policy language Checkpoint compiles to and enforces.
Molti	Managed deployment of governed agents. See Molti.
identiclaw	Agent identity verification for agent operators. See identiclaw Quickstart.
authorization host	The consent/delegation landing host a project serves its authorization flow from (`projects.authorization_host`). Not the edge Gateway — see the two-Gateway note below.

Detection & enforcement

Term	Meaning
detection	One classification event: who a visitor is. Carries a class, a confidence, and signal metadata. A detection alone never blocks anything.
class	The detection's category: `human`, `ai_agent` (AI assistants such as ChatGPT, Claude, Perplexity), `bot` (crawlers, scrapers, traditional automation), or `incomplete_data`.
confidence	0–100 certainty of a classification. 71+ is generally safe to enforce on; a valid cryptographic signature yields 100. A 0 means "couldn't classify," not "confidently human."
verdict	What policy decided: `ALLOW`, `BLOCK`, `REDIRECT`, `CHALLENGE`, or `INSTRUCT`. The HTTP status each produces depends on which surface enforces it — see Verdicts for the per-surface mapping.
INSTRUCT	The identity-demanding verdict: challenges the agent to return with cryptographic identity. The status it produces is not uniform — the Gateway always returns `401` (it does not negotiate for this verdict), the local-engine middlewares return `422` `application/problem+json`, .NET returns `200`, and only `withCheckpointApi` and the middlewares serve the body-readable `200` envelope to cooperative agents. See INSTRUCT by surface.
observe / enforce	The two enforcement modes, independent of policy content. Observe: evaluate everything, act on nothing, record "would have been" outcomes. Enforce: verdicts take effect.
policy	A Cedar policy: an allow-by-default baseline plus `forbid` carve-outs. The gateway enforces the last deployed version — drafts don't run. See Policies.
middleware	In-app enforcement via SDK (Next.js, Express, ASP.NET). Runs the engine in-process or calls the Checkpoint API per request. See Middleware.
signature verification	Highest-confidence detection: RFC 9421 HTTP Message Signatures (Ed25519) verified against the agent's published keys or DID document. A valid signature ⇒ verified agent.
reputation	The agent's trust score, from its public registry presence and observed behavior. Available to policies as `principal.reputation` (0.0–1.0).

Identity & governance

Term	Meaning
DID	Decentralized Identifier — a globally unique ID an agent controls, backed by a keypair the agent generated itself. Verified by proving key possession, not by presenting a secret.
did:key	A DID derived directly from the public key. Self-contained; suited to development and ephemeral agents. A new key means a new DID.
did:web	A DID anchored to a domain, resolved over HTTPS (`/.well-known/did.json`). The production choice: rotatable and organizationally owned.
DID document	What a DID resolves to: the public keys (verification methods) a verifier uses to check signatures.
delegation	The authorization grant: a verifiable credential from a user or organization to an agent, naming scopes, expiry, and constraints. Revocable at any time. See Delegations.
delegation chain	Delegations linked user → agent → sub-agent, per the KYA-OS specification: scopes can only narrow at each hop, and revoking a link invalidates everything downstream. Verification today covers a single hop; claimed parent delegations are not validated.
scope	A permission in `{resource}:{action}` form (e.g. `files:read`). Scopes match exactly — no implicit hierarchy.
proof	A short-lived signed assertion (JWS, Ed25519) an agent attaches to each request: its DID, the delegation and scope being exercised, a unique nonce, and a tight validity window. See Proofs.
verifiable credential (VC)	A W3C-standard signed claim that any party can verify independently, with no callback to the issuer.
consent	The human-approval step where a user reviews an agent's requested scopes and grants (or denies) a delegation. See Consent.
audience	The intended recipient baked into credentials and proofs. A credential issued for one server is rejected by another.
nonce	A single-use random value in each proof; verifiers cache seen nonces and reject reuse, defeating replay.

Commonly confused terms

If this section only existed to disambiguate these clusters, it would earn its place.

Two different "scores." Reputation rates the visiting agent (policy fact, 0.0–1.0). Confidence rates one detection event (0–100). They are not interchangeable.

Two different "Gateways." The edge Gateway (Enforce) proxies and protects your web traffic via DNS. The MCP Gateway (Govern) authorizes agent tool-calls to MCP servers. Different systems, one word.

Two verdict vocabularies, not one. What you author and see in the dashboard is the Cedar vocabulary — ALLOW · BLOCK · CHALLENGE · REDIRECT · INSTRUCT. What the detection engine emits internally is its Decision enum — Permit · Block · Challenge · Redirect · Instruct. Only the first word differs (ALLOW ⇄ Permit); they are the same five verdicts on two surfaces, so neither is "wrong." Stored decisions may also show the legacy lowercase wire values allow and log. See Verdicts.

Checkpoint vs. AgentShield. Same product; AgentShield is the legacy name. Say Checkpoint, install @kya-os/checkpoint-*.

MCP vs. KYA-OS. MCP is the Model Context Protocol. KYA-OS is the open identity extension on top of it — the standard Checkpoint's Govern pillar implements. It was formerly published as MCP-I, which is why package names like @kya-os/mcp-i still carry the old label.

Detect vs. observe vs. Activity. Detect is a pillar — classification, always on. Observe is an enforcement mode — evaluate policies but act on nothing. Activity is the dashboard view where live traffic and verdicts appear. Only observe/enforce is a switch you set.

Delegation vs. credential vs. proof. The delegation is the permission; the credential is the signed document embodying it; the proof is showing up with the document and your key, freshly, on each request.

Glossary

Products & names

Detection & enforcement

Identity & governance

Commonly confused terms

On this page