Five tiers, five different promises

The tempting diagram is a staircase: worktree at the bottom, VM at the top, and one word—“security”—rising with every step. That diagram is easy to sell and bad at helping anyone choose.

Imagine two runs. The first builds ordinary code from your own repository but must start in a fraction of a second. The second opens a stranger's pull request containing native build scripts. The third must reproduce exactly in CI. The fourth is allowed to contact one package registry and absolutely nothing else. Those tasks want different properties. Giving all four the same “strongest” tier either wastes time or quietly misses the control that mattered.

Why “stronger” is not one dimension

Sandbox comparisons often collapse everything into a ladder. That hides the decision you actually have to make. Filesystem reach, network enforcement, kernel sharing, portability, startup time, and observability move independently.

A rootless container has a clean image and dropped capabilities, but an HTTP proxy cannot bind a program that ignores proxy variables. A supervised host process shares the kernel, but nftables in a private network namespace can stop that same program at the packet layer. Neither sentence fits a single score.

What each tier changes

The everyday default

The process tier is aimed at the common failure: an agent or dependency script reads or writes somewhere it should not, spawns too much work, or calls a dangerous syscall. On Linux, Landlock and seccomp do most of the work. The important property is inheritance: the policy follows the process tree.

This is not a claim against a targeted kernel exploit. The kernel enforcing the rule is the same kernel the confined process attacks.

When network destination matters

Use supervised isolation when “only these destinations” must describe packets, not cooperative application behavior. The box receives a private network namespace. DNS answers are pinned. nftables admits resolved addresses from the policy. A seccomp notification gate controls socket creation.

That design closes the obvious proxy escape: clear HTTPS_PROXY, open a raw socket, and dial the address directly. At supervised, the packet still meets the boundary.

What a container is actually for

The container tier is for repeatable images and filesystem portability. That is valuable. It is simply a different value from stronger egress.

Because its allowlist is an HTTP/HTTPS proxy, a compliant package manager is constrained and a program that bypasses the proxy is not. Call this L7 scoping. Do not describe it as general network isolation.

When the kernel must move inside

A microVM changes the deepest assumption. The untrusted process attacks a guest kernel; the hypervisor remains between it and the host kernel. Choose it for hostile code or environments where shared-kernel containment is outside the risk budget.

The trade is visible. Booting a kernel costs more. Hardware virtualization must exist. And an in-guest packet filter may drop denied traffic without producing the request-by-request summary a proxy can record. Stronger enforcement can mean thinner evidence.

Why capability checks must execute

A binary, kernel feature, or device node can exist while policy still prevents it from working. A useful probe runs a minimal confined action and reports whether the claim is satisfiable. Then an explicit request must fail closed. Silently replacing microvm with process would keep the command running by changing the security claim underneath it.

The honest interface is boring: probe, choose, create, inspect the resolved policy.

Workspace is useful precisely because it makes no security claim

The workspace tier gives the agent a separate Git worktree, branch, index, and pinned base. That prevents ordinary checkout collisions and makes comparison clean. It is excellent hygiene for a trusted tool and the wrong answer for untrusted code.

Calling it a sandbox would make every later decision worse. The process still runs as you. It sees the host filesystem, environment, sockets, network, and kernel. h5i keeps the rung because checkout isolation is sometimes the only requested property, and labels it as unconstrained because names should not smuggle guarantees.

Process confinement is the fast, inherited boundary

At process, the session receives filesystem allowlists, syscall restrictions, namespaces, and resource controls where the host can enforce them. On Linux, Landlock makes the allowed filesystem tree explicit and seccomp removes dangerous syscall families. The important part is not any one primitive. It is that the restrictions inherit across the session's descendants.

This tier works well for the daily loop: edit, compile, test, repeat. It does not provide an L3/L4 destination allowlist. Network policy here is coarse—deny it or let it use the host network—and the host kernel remains shared.

Container is a reproducibility choice with a security boundary attached

Rootless Podman lets the repository name an OCI image. h5i runs it with all capabilities dropped, no-new-privileges, a read-only root filesystem, private IPC, a bounded tmpfs, and only the intended mounts. Runs never pull: --pull=never makes the environment depend on the image you prepared, not on what a registry served at session start.

That makes the container tier compelling when “same toolchain everywhere” is the requirement. It also gives real memory and process ceilings on platforms where the host kernel tiers cannot. But its egress allowlist is a CONNECT proxy. Most package managers and HTTP clients respect it. A program opening its own raw socket does not. Portability is the primary reason to choose this rung.

MicroVM moves the shared-kernel line

The microVM adapter boots a guest from the same class of OCI image, through microsandbox. The agent's process, filesystem view, and network stack sit behind a guest kernel. A kernel exploit inside the workload therefore meets the hypervisor rather than continuing directly in the host kernel it attacked.

That property has three concrete prerequisites: a compatible msb binary, usable hardware virtualization, and a pre-pulled image. If any is absent, an explicit microvm request refuses. The command does not “helpfully” fall back to a shared-kernel tier.

The cost is not only startup. Host-loopback credential grants do not currently cross into the guest, so profiles declaring them are refused. The guest network stack enforces destination rules but does not yet return a per-request deny tally, so the boundary can be stronger while the report is less detailed.

What a trustworthy probe has to prove

Feature detection is full of false positives. A kernel can expose Landlock while a policy prevents the final exec. A /dev/kvm node can exist but be unreadable. Podman can be installed and configured rootful when the tier requires rootless operation.

h5i box probe separates facts from claims. It identifies mechanisms, checks prerequisites, and runs a minimal confined action for the lightweight tier. Then box status answers a different question: what did this particular box actually receive? Finally, box doctor asks whether the stored box can still keep that claim on this host today.

$ h5i box probe
# What can this host enforce?
$ h5i box status review-1234
# What policy was resolved for this box?
$ h5i box doctor review-1234
# Can that box still uphold the stored claim?

Choose by the first unacceptable failure

• If host checkout collisions are the only concern, use workspace.
• If a runaway agent or dependency must not roam the filesystem, start at process.
• If off-list raw network traffic must fail, use supervised.
• If a pinned image and portable toolchain matter most, use container and accept its L7 egress scope.
• If the workload must not share the host kernel, use microvm and accept the heavier prerequisites.

This is not a score. It is a threat model stated as an operational choice.

Four runs, four defensible choices

A fifth case—reproducing a precise Linux toolchain across laptops and CI—may choose container even though supervised has stronger network enforcement. The image is the requirement. This is exactly why a single strength score obscures more than it reveals.

The same tier name can have platform-specific limits

Linux supplies Landlock, seccomp, namespaces, nftables, and cgroups. macOS uses Seatbelt for filesystem and process policy and does not have a per-box equivalent to every cgroup control. Pretending the rows are identical would turn portability into fiction.

h5i reports unenforced memory and process values at the macOS kernel tiers instead of listing them as active. The image tiers can supply runtime-level ceilings there. The right workflow is to inspect status on the machine that ran the box, not infer enforcement from the profile alone.

Sources and further reading

• The manual's isolation-tier reference, including platform-specific limits.
• The box lifecycle, including probe, capabilities, status, and doctor.
• Write a box policy, for turning the choice into a checked-in profile.
• The h5i-sandbox source, where the tier adapters and enforcement mechanisms live.

Questions that come up