Glossary
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 repository name and legacy @kya-os/agentshield-* packages. 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 in package names (@kya-os/mcp-i) and doc paths; in prose, 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. |
| CheckPulse | Governance-posture scoring in the dashboard: rates your organization's agent-governance maturity across six primitives (identity, credentials, delegation, consent, authorization, audit). |
| 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. Scopes can only narrow at each hop, and revoking a link invalidates everything downstream. |
| 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.
Three different "scores." Reputation rates the visiting agent (policy fact, 0.0–1.0). CheckPulse rates your organization's governance maturity. Confidence rates one detection event (0–100). None of them are 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.