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

You don't need the cryptography to use Vouched KYA, 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	The KYA-OS specification requires agents to generate their own keypairs. Registries and verifiers only ever receive public keys: an implementation that generates or holds an agent's private key on its behalf is non-conformant, so a conformant deployment has no central store of agent secrets to steal. Keys Vouched KYA holds for you are the exception; see below the table.
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.

Agents that Vouched KYA deploys and hosts for you do not meet the key requirement in the provider-compromise row today. Vouched KYA creates the agent's private key on its own servers (it generates the key, or receives it from KnowThat.ai registration), stores it encrypted, and passes it to the agent's runtime, so Vouched KYA holds that key as well as the agent. Vouched KYA also holds your organization's registry signing key: it generates the key, keeps it encrypted in its custody, and signs on your organization's behalf. The registry receives only the public key.

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 Vouched KYA'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