Compliance posture

kixctl is not certified against any compliance framework, and this page does not claim it is. What it describes is narrower and more durable: the security properties a compliance program requires are, in kixctl, consequences of how the system is built rather than features added for a checklist. That is what makes the story credible rather than aspirational.

• Immutable units with per-revision identity, legible from the fabric itself, give a real, reconstructable change history — what ran, when, and from which commit — with no separate audit log to trust.
• Secrets encrypted at rest under a sops-guarded key, delivered as root-only credentials, are never baked into an image and are logged by key name only.
• A control plane that cannot escalate its own access means a bounded, auditable blast radius if the web tier is ever compromised.
• A build pipeline that never runs as root and can execute only one validated program forecloses the shell-injection class of bug entirely.
• Layered authorization enforces access per verb, with an optional enterprise path that moves enforcement into the hypervisor itself.

These are the properties a HIPAA or SOC 2 program is built on. A hypervisor with no deployment model, no immutability, and no secret architecture has none of them to point at. The certifications themselves are organizational work a deploying operator undertakes; kixctl's contribution is to make that work rest on architecture rather than hope.