open-standards/sandbox/spec/tiers.md

The isolation ladder (S0–S7)

Normative companion to SPEC.md §2.2. RFC 2119 keywords apply.

A host runs a unit at exactly one tier. The tiers form a total order; each tier's guarantees strictly contain the tier below. The guarantees are normative; the reference mechanisms are illustrative. A host MAY satisfy a tier by any means that delivers its guarantees, and MUST NOT claim a tier whose guarantees it does not deliver.

The guarantee at each rung

S0 — Bare

No added boundary beyond an OS process. The unit shares the host's authority. Guarantee: none beyond process separation. Permitted only for trusted code or local development. Accelerators reachable only if a compute grant names them, but no confinement is asserted.

S1 — Capability

The unit holds unforgeable capability tokens and has no ambient authority: it can name only resources it was handed. Guarantee: no resource is reachable without a capability for it; possession is the whole of authority. Reference: an seL4-class capability system or an equivalent object-capability runtime.

S2 — Sandbox

The unit runs inside a managed runtime with instruction/fuel metering and memory caps, mediated host calls, and no raw syscall surface. Guarantee: S1, plus bounded CPU work (fuel) and bounded memory, plus a host-call boundary every capability crosses. Reference: a WASM engine (Wasmtime-class) with fuel metering and StoreLimits. Default tier for untrusted single-tenant agent tools. An accelerator class granted here is reached through a brokered device interface the host mediates (e.g. a virtual GPU-compute device), never raw.

S3 — Partition

Multiple units share a host kernel under temporal and spatial partitioning: dedicated time slices and memory regions, with cross-partition interference bounded. Guarantee: S2, plus multi-tenant isolation on one kernel. Accelerator time is partitioned across tenants.

S4 — Unikernel

The unit runs as a single-address-space unikernel guest under a VMM — a minimal kernel+app image with no general-purpose OS surface. Guarantee: S3, plus a hypervisor boundary and a minimized attack surface. Accelerators reached via a paravirtual device.

S5 — MicroVM

The unit runs in a full guest kernel inside a microVM with dedicated vCPU and memory. Guarantee: S4, plus a complete kernel/userspace boundary at hardware-virtualization strength. Reference: Firecracker, Cloud Hypervisor, crosvm. An accelerator granted here MAY be directly assigned (PCI passthrough / SR-IOV); direct assignment requires S5 (SPEC §5.1).

S6 — Confidential

S5, plus hardware memory encryption and remote attestation (a TEE): the host operator cannot read the unit's memory, and a verifier can establish the boundary cryptographically. Guarantee: S5, plus confidentiality against the host. Reference: AMD SEV-SNP, Intel TDX, Arm CCA; confidential-compute accelerators (e.g. GPU CC modes) for accelerator grants. The host obtains a TEE report bound to the run, verifies it (signature + measurement/TCB/debug/report-data against policy), and seals the summary into the attestation (SPEC §7.6). Report verification is implemented and vectored; generation requires the platform's security processor (SPEC §9).

S7 — Sovereign

S6, plus geographic pinning and an immutable audit trail: the run is bound to a { region, jurisdiction } locality, and each run is folded into a hash-chained, tamper-evident audit log so the sequence of sovereign runs is itself attestable (SPEC §7.7). Guarantee: S6, plus locational and audit provenance.

Tier minimization (REQUIRED)

The unit's required tier is the lowest tier whose guarantees satisfy every grant it holds. SPEC §5 fixes per-capability minimums:

Grant condition	Minimum tier
Cpu / Simd compute only, no network, no storage write	S0 (if trusted) / S1
any untrusted code	S2
accelerator class via brokered interface	S2
multi-tenant on shared kernel	S3
contention-sensitive colocation without an I/O ceiling	S3
accelerator via direct device assignment (passthrough/SR-IOV)	S5
confidential compute (TEE)	S6
jurisdiction-bound + audited	S7

The host computes the required tier as the maximum of the per-grant minimums, runs there, and records it in the attestation. A host MUST NOT run above the required tier (energy waste) nor below it (under-isolation). Escalation to a higher tier than required is the escape hatch, not the default.

Minimization is side-channel-aware

The tiers above S2 exist because logical isolation does not partition shared physical resources — and a shared resource is a channel. S0–S2 share the host's kernel and device I/O paths, so co-tenants can observe one another through contention (SECURITY.md gives storage I/O as the worked example). The required-tier computation therefore accounts not only for what a unit's grants name but for what they expose: a workload that is sensitive to — or, as an untrusted neighbor, capable of — cross-tenant leakage through a shared resource has its floor raised. The capability lever (an I/O ceiling, SPEC §5.2) can hold such a workload at S2; absent it, the floor is S3 (partitioned I/O) and the channel is closed structurally, not merely throttled. Dedicated device assignment (S5) removes the shared device entirely.

Overhead is reported, not hidden

Each tier costs latency, energy, and memory to establish. A host SHOULD report per-tier establishment overhead so the cost of isolation is visible and the minimization rule is auditable. Establishment energy is part of the run's receipt (SPEC §6) and attributed to the Cpu class unless a more specific interface is available.