Isolation runtimes

Four boundaries carry the whole platform. Each is chosen for a specific threat model and a specific start-latency budget, and those two constraints are in direct tension — stronger boundaries start slower.

Tier 0 — the handler contract

There is no sandbox at tier 0 because there is no untrusted code. The agent chooses a tool and supplies arguments; the code that runs was written and reviewed by the organization or the platform.

What actually constrains tier 0:

• Schema validation on arguments and results. A handler never sees a value it did not declare.
• The tool allowlist, evaluated per invocation against the session's policy.
• Per-tool timeouts, concurrency ceilings and circuit breakers, so one bad remote MCP server cannot degrade the tier.
• Resource ceilings on in-process handlers: wall time, memory, outbound connection count.

Tier 1 — gVisor

What it is

gVisor runs a user-space kernel — the sentry — that implements the Linux syscall ABI in Go. Guest processes issue syscalls to the sentry, not to the host. The sentry satisfies most of them itself and only reaches the host for a small, filtered set.

Why it fits tier 1

The threat is model-authored code — attacker-influenced by construction. A plain container's boundary is the full Linux syscall surface, which is hundreds of calls, decades of accumulated behaviour, and a steady supply of local privilege escalation bugs. gVisor cuts that to roughly sixty heavily filtered calls, at a cost of tens of milliseconds and some syscall-heavy performance.

A microVM would be stronger, but tier 1's value proposition is sub-second starts at high density. gVisor gets within 2–3× of container start time where a microVM is 3–5×.

Known limits

• Not a hypervisor. A sentry bug combined with a seccomp bypass reaches the host kernel. Rare, but the boundary is software, not hardware.
• Syscall-heavy workloads pay. Tight read/write loops and process creation are measurably slower. Compute-bound code is near native.
• Incomplete ABI coverage. Some syscalls and /proc entries are unimplemented. Templates are validated against the sentry's coverage before publication.

Hardening on top

Read-only rootfs with per-session overlay · all capabilities dropped · no CAP_NET_RAW · user-space netstack, no host socket access · cgroup v2 CPU and memory limits with OOM surfaced as a run failure · only /dev/null, /dev/zero, /dev/urandom · no host filesystem passthrough.

Tiers 2 and 3 — microVM

What it is

A Firecracker-class VMM: hardware virtualisation through KVM, with a device model cut down to virtio-blk, virtio-net, virtio-vsock and a serial console. No BIOS, no PCI enumeration, no USB, no graphics. The VMM binary is a few megabytes and the attack surface is a fraction of a general hypervisor's.

Why it fits tiers 2 and 3

Tier 2 hands the agent a shell and root inside the guest. Nothing short of hardware virtualisation is a defensible boundary for that. The guest kernel is the guest's problem; a guest kernel exploit gets root in a VM that already had root.

Tier 3 uses the same boundary for a different reason: a browser is a large, complex, remotely attacked program. A compromised renderer should land in a VM, not in a shared sentry.

Defence in depth around the VMM

The jailer assumes the VMM itself will eventually be compromised:

Snapshot resume

The reason microVM tiers hit sub-second starts. A pool VM is booted to a ready wbagent, then paused and snapshotted — memory image plus device state. A claim restores that image, swaps in the session's scratch block device, joins the egress namespace and unpauses.

Two consequences worth designing around:

• Entropy must be reseeded. Every resumed VM starts from identical memory, so the guest would otherwise share random state with every other resume. wbagent reseeds the guest CSPRNG from a host-provided seed before any workload starts.
• Clocks must be corrected. A resumed guest believes it is still at snapshot time. The agent forces a clock sync at resume, before any TLS handshake.

Tier 4 — full VM

What it is

QEMU with KVM and a complete device model: virtual framebuffer, input devices, sound, optional mediated vGPU. Everything a desktop needs and a microVM deliberately omits.

Why the device model has to be full

A desktop needs a display, input and sometimes GPU acceleration. Those devices are exactly what makes the boundary larger — more emulated hardware is more code reachable from inside the guest. Tier 4 therefore compensates with placement rather than with a smaller surface:

• No co-tenancy on the physical core. 1:1 vCPU-to-core, desktop-class hosts only. A cross-VM side channel has no co-tenant to attack.
• Instances are destroyed, never reused. The pool slot is refilled from a clean snapshot.
• Per-session disk encryption, with the key held by the control plane and destroyed at teardown.
• Device minimisation within the constraint: no USB passthrough, no host filesystem sharing, clipboard and file transfer mediated through the API rather than a transparent channel.

Cross-cutting controls

These apply at every tier above 0.

Choosing a boundary for a new tier

If a sixth tier is ever added, the questions in order:

1. Does it execute code the model wrote? No means tier 0's contract may be enough.
2. Does it need a shell, arbitrary binaries or a real kernel? Yes means hardware virtualisation.
3. What is the start-latency budget? Under 100 ms rules out VMs entirely.
4. Does it need devices beyond virtio? Yes means a full VM and the placement compensations that come with it.
5. What does a full compromise reach? If the answer includes another tenant, the design is wrong.