Risk & mitigation · published threat model

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.

High R-01

Signing-key compromise — agent or trust-domain root

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.

High R-02

Registry / Gateway outage

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.

Medium R-03

False-positive deny — over-restrictive policy

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.

Medium R-04

Time-skew · expired credentials honoured

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 issued_at + not_after + cascade_seq; cascade-seq monotonicity check rejects out-of-order updates; conformance fixture covers ±60s skew tolerance.

High R-05

Replay attack on signed payloads

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.

Medium R-06

Supply-chain risk · SDK / dependency compromise

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.

High R-07

Recovery-channel abuse · break-glass exploit

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 (kye-recovery-1.0): every break-glass grant is a signed request + decision + proof artefact; auto-expiry; mandatory dual-control at L4 KYE Certified™; emits break_glass_issued + break_glass_used + break_glass_expired on the bus.

Medium R-08

PII · sensitive-data leakage in audit chain

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.

Low R-09

Operator misconfiguration · loose scope

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.

Low R-10

Cryptographic agility · algorithm sunset

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 for the coordinated-disclosure policy. We’ll publish updates to this threat model on the changelog; new risks accepted via Discussions.

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. KYE Cloud™ is one (commercial) implementation; multiple conformant implementations are expected.
  • 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.

checklist Readiness self-test → architecture Protocol overview verified_user For auditors security SECURITY.md forum Talk to us