How Checkpoint and KYA-OS defend against impersonation, replay, tampering, and credential theft

You don't need the cryptography to use Checkpoint — but if you're evaluating it, you need to know that each obvious attack has a specific, named countermeasure. This page maps threats to mechanisms. Everything here is defined in the KYA-OS protocol specification and implemented in the verification pipeline.

Threats and countermeasures

Threat	Countermeasure	How it works
Impersonation — "I'm ChatGPT, trust me"	Signatures, not strings	Identity claims are only treated as verified when proven by an Ed25519 signature checked against the agent's DID document or published key directory. Anything less is a low-confidence detection, never a verified identity.
Replay — capture a valid request, resend it	Nonces + freshness windows	Every proof carries a unique nonce that verifiers cache and reject on reuse, plus a tight validity window (proofs are typically valid for five minutes, and every verification path enforces its own bounded skew tolerance on `created`; see KYA-OS Enforcement for the exact tolerance per path — they differ). A captured proof dies in minutes and can never be used twice.
Tampering in transit — modify a request, or swap a response	Content binding over TLS	TLS protects the channel; on top of it, signatures cover the canonicalized content itself — proofs bind SHA-256 hashes of the exact request (and response). A modified request fails verification. Verification is fail-closed.
Credential theft — exfiltrate a delegation, use it elsewhere	Holder binding + audience	A delegation is not a bearer ticket. The caller must prove possession of the subject DID's private key on the request itself, and credentials and proofs name their intended audience — a credential issued for one server is rejected by another.
Privilege escalation — a sub-agent grants itself more than it was given	Attenuation-only chains	By design, chains are attenuation-only: a delegation's scopes must be a subset of its parent's, so authority can only narrow, and every chain terminates at an accountable root party. Verification today covers a single hop; multi-hop chains are rejected rather than walked, so do not rely on cascading revocation until chain support ships (see Delegation chains).
Provider compromise — "what if the vendor is breached?"	No key escrow, by spec	Agents generate their own keypairs; registries and verifiers only ever hold public keys. The KYA-OS specification makes holding agent private keys non-conformant. There is no central pile of agent secrets to steal.
Downgrade — simply don't send identity	Fail-closed enforcement	Routes that require identity reject unsigned or sessionless requests rather than degrading gracefully. The `INSTRUCT` verdict exists precisely so "stay anonymous" stops being an option on protected resources.

The design principle underneath

Every row above follows the same principle: verify possession, not presentation. Strings can be copied, headers can be forged, and credentials can be stolen — so nothing in the verification path trusts what a request presents. Trust attaches only to what the caller can prove it holds: a private key, exercised freshly, on this exact content, for this exact audience.

That's also why the system degrades safely. When a signature doesn't verify, a nonce repeats, a timestamp drifts, a scope doesn't match, or a delegation has been revoked, the request fails closed with a specific error rather than falling back to a weaker check. See Proofs for the verification error codes you'll encounter in practice.

Detection-layer signals (user-agent, headers, behavior) sit outside this security model — they are best-effort classification, not verification, and Checkpoint's confidence scores reflect that honestly. The cryptographic path is how a request graduates from "classified" to "verified." See the trust ladder.

Security Model

Threats and countermeasures

The design principle underneath

On this page