Policies and the kill switch
Everything Kavros enforces traces back to a signed policy. This page covers the lifecycle — propose, approve, sign, enforce — and the kill switch that quarantines a workload instantly.
Two-person approval by default
A policy change starts as a proposal (org admin or automation), and only takes effect after approval and signing by a super admin. The approver sees a diff against the current policy. Every proposal, approval, signer, and timestamp is recorded in the policy event timeline.
Signed, then enforced
- Approved policies are Ed25519-signed by the control plane's key; the enclave verifies the signature before enforcing a runtime policy — an unsigned or wrongly-signed policy is never enforced.
- The policy signing key's fingerprint is visible in the dashboard and in
kavros doctor, so you can verify what is enforcing your requests. - Dry-run simulation shows what a proposed policy would have blocked or allowed against recent traffic, before you approve it.
- Version history keeps every revision with diff and rollback.
Tamper resistance
The baked policy is measured into the enclave's PCR0: tampering changes the measurement and the platform refuses to attest it. Runtime policies only flow to the enclave over a signed fetch — a rogue insider cannot add an allowlist entry by editing a file.
The kill switch
Halting a workload sets it to QUARANTINED. The data plane blocks egress immediately — the agent receives a plain-language block with the real reason — and a critical incident appears in the Task Inbox with the halt reason and actor. Resuming returns the workload to ACTIVE and resolves the incident. Both actions are hash-chained in the audit log.
Revocation
Revoking a workload identity retires its key: the agent cannot authenticate at all. Halt is the reversible operational switch; revocation is the permanent one.