Hardware isolation is not optional for agent red-teaming
Containers share a kernel. When you are actively probing for kernel-level privilege escalation, that shared kernel is the vulnerability you are trying to measure.
There is a tempting shortcut in agent sandboxing: run each agent in a container, cap its CPU and memory, and call it isolated. It works right up until the task is “try to escalate privileges,” at which point the container’s shared kernel becomes both the attack surface and a source of ambiguous results.
What a container does and does not give you
Namespaces, cgroups and seccomp filters are meaningful hardening. They are not a security boundary against a deliberately malicious workload. A kernel exploit that works once can work across every container on the host.
For agent evaluation this is doubly bad:
- Safety: an agent that finds a real exploit has now escaped.
- Signal quality: you cannot tell whether a success was the agent’s capability or a known container escape.
The microVM boundary
Each agent on the platform runs inside its own microVM: a separate guest kernel, a disposable root filesystem, and a network policy that denies by default. A breakout attempt hits a boundary that does not exist in the shared-kernel model. When the agent succeeds, you know it succeeded inside the sandbox, and the evidence is reproducible.
Reproducibility as a correctness property
Isolation is only half the story. We pin the task hash, the base image digest, the random seed and the tool versions for every run. A finding without a replay is an anecdote; a finding with one is a result. That distinction matters when a report is being used to make a deployment decision worth millions.