The isolation model

kixctl runs each workload as an Incus system container — or a full virtual machine where you need one — not as a container sharing the host's kernel. For your own code on your own box, a shared kernel is a reasonable trade. For code you did not write, several customers' code on one fabric, or anything that has to clear a security review, it is precisely the boundary that gets questioned. A system container is a materially stronger line than a shared-kernel container, and it is the foundation the rest of kixctl's security posture stands on.

Deployed revisions land on kixctl's own bridge and profile, internal by default. A revision is reachable through kixctl's edge, not by virtue of sitting on your LAN — so exposing an application is a deliberate act, not the default state of a freshly launched container.

The control plane cannot escalate

kixctl talks to the Incus fabric over a Unix socket or a scoped client certificate — never as the host's root user. It cannot grant itself more access to the fabric than the credential it was issued carries.

This matters because the control plane is the internet-adjacent component in any system that can launch workloads: it is the thing worth attacking. Isolation between workloads does nothing for the control plane itself. Scoping what the control plane can do — so that even a compromised one cannot widen its own reach — is a line most of the field does not draw, and here it is an invariant of how kixctl connects rather than a setting you have to trust.