Adoption checklist

Question 1

What runtime does it actually start?

Not what the docs say, what the process table says. A vendor documented a hardened Sysbox default and marketed a dedicated kernel per sandbox; a June 2026 measurement found the default install path starting a plain runc container with Privileged:true hardcoded, which switches off the seccomp profile, AppArmor, and user namespaces at once.

How to check

• Start a sandbox on defaults and check what is running on the host: ps for the VMM or shim process, docker inspect for the runtime, or the orchestrator's own runner config.
• If it is open source, grep the runner for the container config it builds. Privileged, CapAdd, SecurityOpt, and the seccomp profile path are the fields that matter.
• Compare that to the tier the marketing claims. 'Dedicated kernel' means a VMM process per sandbox and a guest kernel; if you cannot find either, it is a container.

Question 2

Which build of the engine, and who bumps it?

Upstream engines patch fast, usually the day a bug is disclosed. The lag is downstream, in the products that pin those engines. Measured across five products in 2026, downstream lag ran from zero days to 471 days to opaque to never, a range wider than the gap between isolation tiers.

How to check

• Find the pinned engine version: a lockfile, a version registry, a Dockerfile, a Terraform variable, or the orchestrator default.
• Compare it against the engine's release history and its security advisories. How many releases behind is it, and does anything in that gap have a CVE?
• Then ask the question that outlives the number: what moves this pin? Dependabot, a release process, or someone remembering.

Question 3

Is there a second wall, and is it on by default?

A microVM boundary is enforced by a VMM that parses hostile guest input in userspace. If that process is compromised, whatever confines it is all that stands between the guest and your host. Default-off confinement is confinement most people do not have.

How to check

• Ask what confines the VMM process: seccomp, a jailer, Landlock, namespaces, a privilege drop, or nothing.
• Then check whether it is applied automatically or behind a flag. Cloud Hypervisor supports Landlock self-confinement, and a real deployment measured in 2026 still ran its leader thread unfiltered.
• For an embedded, in-process VMM, ask whose authority a VMM bug lands with. Linked in-process usually means the launching user's.

Question 4

What can it read about your host, and what can it reach?

The realistic failure with an agent is not a kernel escape, it is exfiltration: read the secret, post it somewhere. Egress is how anything stolen leaves, and leakage tells you how much the sandbox knows about where it is running.

How to check

• Check the egress default first. Open by default, allowlist available, and default-deny are three very different products.
• Confirm the cloud metadata endpoint 169.254.169.254 is blocked from inside the sandbox.
• Read /proc/cpuinfo, /proc/meminfo, uname -a, and the DMI tables from inside. One product in the 2026 study leaked ten host identifiers this way; two leaked nothing across 28 probes.
• Ask how secrets reach the workload. Brokered at an egress proxy beats managed injection beats plain environment variables.