Security

The isolation guarantees rest on a small number of design decisions. They are worth understanding before you rely on them, because each one shapes what the boundary does and does not protect against.

Deny-all by default

The zero-value profile is the most restrictive thing a tier can express: no network, no mounts, no devices, capabilities dropped. Confinement is what you get by omission; permission is what you have to ask for.

That is the opposite of the usual container default, and it matters. A profile assembled from partial input does not silently inherit host access — an unset field means denied, not inherited.

Network is the clearest case. NetworkPolicy defaults to off:

Mode	Meaning
`off`	No network at all — the default
`loopback`	Loopback only
`egress`	Outbound only
`host`	Host networking — escape hatch, must be opted into

Escape hatches are explicit and named

Two things can weaken the boundary to nothing, and both require deliberate opt-in:

--allow-process-tier — the process tier applies no isolation. It exists for local development.
--allow-net-host — host networking, which removes network confinement.

Ask for the unconfined tier without the hatch and it refuses:

kis sandbox run --tier process -- echo nope

escape_hatch_forbidden: the process tier runs unconfined and requires escape_hatch.allow_process_tier

The value here is not that it is impossible — it is that it is impossible by accident. The error names the exact flag, so an unconfined run always appears in a command line or a config file where a reviewer can see it.

Declared-but-unusable fails loud

If a backend cannot enforce the isolation you asked for, it refuses — ErrProfileUnsatisfiable or ErrTierUnavailable — rather than running with weaker confinement.

This is the property that makes the tier model trustworthy. The dangerous failure mode for any sandbox is silent degradation: you ask for a microVM, the host cannot provide one, and your code runs in a namespace while you believe otherwise. That cannot happen here.

The corollary is operational: a deployment that suddenly cannot run its workloads may be telling you an isolation mechanism disappeared, not that the sandbox is broken. Check kis sandbox backends against the tier you requested before assuming a bug.

Absent is different from unusable. A backend that is not present on the platform is normal and selection routes around it; a backend that is present but cannot satisfy the profile is an error.

The engine decides nothing

The engine is stateless and takes resolved input: no registry lookup, no policy decision, no secret fetch happens inside it. Policy — which tier, which base, whose credentials, what to audit — is decided by the caller and handed in.

Two consequences worth naming:

The auditable surface is small. The part that enforces isolation does not also parse config, resolve identity or talk to a registry, so reviewing it is tractable.

Policy is your responsibility. The engine will faithfully enforce a weak profile. It is not a policy engine and will not object that what you asked for is unwise — only that it cannot be delivered.

Identifiers are engine-set

Sandbox ids, mount sources and stream ids are assigned by the engine; only value payloads are caller-controlled. A caller cannot name its own mount source or collide with another sandbox’s id, which closes a class of confused-deputy and path-traversal problems at the type level rather than by validation.

Isolation is not the only boundary

Sandbox confines a process. It does not confine meaning:

Tenant data isolation is enforced by the data layer, not here. A sandboxed process with a valid credential reads exactly what that credential permits.
What a script may call is Script’s namespace binding, a different and complementary mechanism.
Secrets come from Vault and are injected by the caller. The engine fetches nothing.

A common mistake is treating the sandbox as a substitute for authorisation. It is not: it limits what a process can reach, not what it is entitled to.

Choosing a tier

Running	Tier
Your own code, locally, iterating	`process` with the escape hatch
Untrusted or generated code	`container` or `microvm`
Something needing a real kernel boundary	`microvm`
A compiled artifact with no syscall needs	`wasm`
Trusted code needing filesystem limits	`host`

The honest default for anything you did not write is microvm. Kernel-sharing tiers — host and container — are defence in depth against a compromised process, not against a kernel exploit.