--- title: "KYE Protocol™ — Risk & mitigation | Threat model · failure modes · operational guarantees" description: "The KYE Protocol™ threat model: signing-key compromise, registry availability, false-positive denials, time-skew, replay, supply-chain risk…" url: https://kyeprotocol.com/risk/ lang: en source: "KYE Protocol" --- > The KYE Protocol™ threat model: signing-key compromise, registry availability, false-positive denials, time-skew, replay, supply-chain risk… Risk & mitigation # What can go wrong. What KYE™ does about it. Every risk and security team asks the same question before adopting a new contract layer: _what’s the threat model, and where does the protocol fail?_ KYE Protocol™ answers in the open. Below is the published threat model, the failure modes, and the protocol-level mitigations the spec ships. Threat model ## 10 threats. 10 mitigations. Spec-level, not operator-best-effort. ### Signing-key compromise — agent or trust-domain root High R-01 **Threat:** an agent’s Ed25519 key, or a trust-domain root key, is exfiltrated. Forged authority + audit entries become possible. **Mitigation:** mandatory key-rotation profile (`kye-rotation-1.0`) with overlapping validity windows; signal-bus `quarantine` + cascade revoke in < 1 second; transparency-log receipt makes any forged audit entry detectable on next replay; recovery-profile time-boxed re-keying; HSM · KMS · cloud-KMS-backed keys at L3 conformance. ### Registry / Gateway outage High R-02 **Threat:** the KYE™ Gateway, signal bus, or registry is unavailable. Decisions stall — or worse, fail-open. **Mitigation:** embedded PDP library runs in-process with cached policy bundles; configurable fail-closed default; multi-region active-active deployment topology in the runbook; Gateway is stateless, registry is the only state plane; DORA-grade chaos-testing fixtures ship with the conformance pack. ### False-positive deny — over-restrictive policy Medium R-03 **Threat:** agents are denied legitimate actions because policy is too tight; business velocity drops; users circumvent the protocol. **Mitigation:** shadow-mode + canary policies (every PDP request can be evaluated against multiple policy versions); `allow_with_constraints` as default disposition (vs binary deny); per-tenant policy review surfaced in the audit chain; explainability via Decision Map™ on every deny. ### Time-skew · expired credentials honoured Medium R-04 **Threat:** clocks drift; expired delegations or stale grants are honoured; revocation propagation is delayed. **Mitigation:** NTP / chrony required + drift telemetry in the signal bus; every authority token carries time-bound issuance fields plus an ordering field that lets the runtime detect and reject out-of-order updates. The specific ordering-field construction and the conflict-resolution rule are proprietary and are not disclosed in this repository. Conformance fixture covers ±60s skew tolerance. ### Replay attack on signed payloads High R-05 **Threat:** a previously-signed payload (e.g. a payment intent) is replayed by an attacker; same signature, same authority — new effect. **Mitigation:** KYE™ Payload Trust Profile™ 13-state lifecycle; `payload_id` uniqueness enforced at `/v1/payloads/verify`; replayed-state transition emits a `replay` signal; bound\_to\_decision pinning makes a payload single-use. ### Supply-chain risk · SDK / dependency compromise Medium R-06 **Threat:** a compromised SDK or transitive dependency injects a backdoor into authorize calls; trust is undermined silently. **Mitigation:** SBOM (CycloneDX) per release; reproducible builds for the reference implementations; signed releases (Sigstore-compatible); npm audit · pip-audit · govulncheck wired into CI; conformance fixture suite re-run by the consumer (not just the publisher) at adoption. ### Recovery-channel abuse · break-glass exploit High R-07 **Threat:** the recovery / break-glass profile becomes the path of least resistance; insiders abuse it; auditors lose visibility. **Mitigation:** recovery is a contract, not a black box (`evidence-replay`). Every break-glass grant is a signed request + decision + proof artefact, auto-expires, and requires dual-control at L4 KYE™ Certified™. Bus emits `break_glass_issued` / `break_glass_used` / `break_glass_expired`. ### PII · sensitive-data leakage in audit chain Medium R-08 **Threat:** the audit chain itself becomes a sensitive-data store; GDPR / HIPAA / 42 CFR Part 2 violations follow. **Mitigation:** audit chain references entities by URN, never embeds payload bytes; redaction profile binds to capability before bytes leave the data boundary; lifecycle `tombstoned` state for right-to-erasure; trust-domain federation keeps EU records EU and non-EU records non-EU. ### Operator misconfiguration · loose scope Low R-09 **Threat:** an operator grants overly-broad scope (the “star permission” problem); blast radius on compromise is excessive. **Mitigation:** attenuation is a protocol invariant (parent ⊇ child enforced); Blast Radius Map™ surfaces over-broad grants pre-deployment; conformance fixture rejects wildcards in payment / healthcare / federation profiles; scope-tightening recommendation engine in the recovery console. ### Cryptographic agility · algorithm sunset Low R-10 **Threat:** Ed25519 / SHA-256 are eventually superseded; signed evidence packs need to remain verifiable for 7+ years (regulatory retention). **Mitigation:** algorithm choice is a profile parameter, not hard-coded; v2.0 RFC adds the post-quantum cryptography overlay (algorithm choice deferred); legacy verifier remains permanently shipped so historical evidence stays replayable. **Reporting a finding:** see [SECURITY.md](https://github.com/KYE-Protocol/.github/blob/main/SECURITY.md) for the coordinated-disclosure policy. We’ll publish updates to this threat model on the [changelog](https://kyeprotocol.com/changelog/); new risks accepted via Discussions. Blast Radius Map™ · for CISOs & risk operators ## See what breaks before it breaks. Pick a compromised credential, agent, capability, delegation, or principal. The Blast Radius Map™ shows the downstream agents, payment authorities, capabilities, sessions, and webhooks that fan out — plus the required revocations a runbook should execute. The visualisation is rule-based for clarity; the production runtime mechanism is proprietary and is not modelled here. What KYE™ does not claim ## Honest non-goals. - **Not a model-safety layer.** KYE™ governs _what an agent is allowed to do_; it does not stop a model from producing unsafe output. Pair it with a content-safety layer. - **Not a replacement for legal counsel.** KYE™ produces evidence; certifications, legal filings, and regulator interpretations remain the customer’s. - **Not a certification body.** KYE™ Conformant™ / KYE™ Certified™ are conformance badges issued through the registry; framework certifications (SOC 2, ISO 27001:2022, FedRAMP) come from accredited auditors. - **Not a single-vendor product.** The protocol is Apache 2.0 + open contract. Multiple conformant implementations are expected; the conformance pack is the test of fidelity, not vendor identity. - **Not a silver bullet for adversarial inputs.** Decision Map™ explainability + cascade revocation reduce blast radius when adversarial inputs slip past the model; they don’t prevent the inputs. Where to go next ## Adjacent reading. [Readiness self-test →](https://kyeprotocol.com/readiness/) [Protocol overview](https://kyeprotocol.com/protocol/) [For auditors](https://kyeprotocol.com/auditors/) [SECURITY.md](https://github.com/KYE-Protocol/.github/blob/main/SECURITY.md) Talk to us ## Ready to see your AI agents flagged? Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks. [Apply for pilot →](https://kyeprotocol.com/pilot-apply/) [Try the sandbox →](https://kyeprotocol.com/sandbox/demos/) Canonical KYE™ surfaces referenced on this page: [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) · [KYE™ Conformance Pack™](https://kyeprotocol.com/compliance/) · [KYE Protocol™](https://kyeprotocol.com/).