Security Model
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; gateway signatures allow ±30 seconds of clock skew). 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 | Chain validation rejects any delegation whose scopes aren't a subset of its parent's — authority can only narrow. Every chain terminates at an accountable root party, and revoking any link cascades to everything below it. |
| 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.