The Sandboxing Manifesto
A sandbox is a falsifiable claim. "Sandbox" has been diluted until it guarantees nothing.
“Sandbox” has been diluted until it guarantees nothing. It gets stamped on Docker containers with seccomp profiles, on browser tabs, on YAML policy files running beside the agent they claim to contain. Meanwhile the workload inside changed. An AI agent installs packages, calls APIs, and touches production, and its behavior is a function of whatever text it read five seconds ago. An agent is untrusted code. Where it runs is a security decision, and the industry answers it with a word that means nothing.
We hold ourselves to a definition sharp enough to be proven wrong:
A sandbox collapses the trust problem from “do I trust this agent?” to “do I trust this specification?” It makes the execution environment a verifiable function of an auditable spec, enforced by hardware-level microVM isolation that no configuration can weaken.
Seven properties follow. Each can be checked. Each eliminates something.
1. The boundary is hardware. Isolation is enforced by hardware virtualization, not by the host kernel. If the host kernel is in the trust path, it is not a sandbox. This eliminates shared-kernel “sandboxes”: containers, seccomp, namespaces, user-space kernels. In Edera’s red-team benchmark, LLM agents broke into Docker in roughly half of 18 escape scenarios; hypervisor-isolated zones blocked all but one, and that one fell to a misconfiguration, not a kernel exploit. A vendor-run number, but it points the same way the CVE record does.
2. Zero ambient authority. The workload starts with nothing. No filesystem, no network, no host services. Every capability is explicitly granted, narrowly scoped, revocable. The container model makes security the art of subtracting from ambient authority, and subtraction always misses something. Addition cannot.
3. The trusted computing base is small enough to audit. A microVM monitor is tens of thousands of lines. A shared kernel is tens of millions. A single-application kernel guest is one process: no shell, no package manager, no services the task didn’t ask for. Smaller surface, stronger claim.
4. The image is the specification. Built reproducibly from a declarative spec, hash-verifiable by anyone who rebuilds it. No gap between what was reviewed and what runs. Agents cannot be audited. Specifications can.
5. Resource limits hold under attack. CPU, memory, and I/O are enforced by the hypervisor, not negotiated with the guest. An agent that cannot escape can still try to starve its neighbors, and “usually fair” is not a security property.
6. Nothing survives that wasn’t declared. Fresh state at start, no residue at teardown, persistence only when explicitly scoped. One task, one microVM, one credential. A compromise ends where the task ends.
7. Configuration cannot weaken isolation. Most container escapes are not kernel exploits; they are one YAML line that was always there. We don’t try to prevent bad configuration. We remove configuration from the security boundary.
When a vendor says “sandbox,” ask one question: where does enforcement execute? If the guardrail runs in the same kernel as the agent it polices, it is a suggestion the agent can eventually disable, deceive, or race. Guardrails belong on the boundary, never inside it.
The old objection was cost. VMs were too slow for per-task isolation. That argument is dead: microVMs cold-start in milliseconds and pack a million to a server. A shared kernel is no longer a pragmatic compromise. It is just a weaker boundary.
Our position: isolate first, recover utility through explicit grants. The two strategies fail differently. Relaxing the boundary fails silently; each exception is individually reasonable and the sum is a sieve. Granting capabilities fails loudly; an agent missing a grant stops and asks, and the grant is a logged, reviewable event. We choose the failure mode that leaves evidence.
Where we stand. NOFire agents investigate production incidents holding credentials to customer infrastructure, so this definition is the standard our own execution layer is held to. Shipped today: one microVM per task via urunc, no in-guest agent, no guest-to-host control channel, scoped short-lived identity, egress allowlisting, hash-verified images, per-step checkpoint and rollback. Building: runtime policy bands, TEE-backed attestation. Open for everyone, including us: side channels under extreme threat models, and a malicious host.
A sandbox is not a product feature. It is a set of falsifiable claims about an execution environment. Ours are above. Check them.
The white paper behind this manifesto has the threat model, the isolation comparisons, and the evidence for each claim. Get the white paper, or book a demo and check the claims against your own stack.
Follow me on
Contact me!
If you want to start adopting a culture of reliability and AI, feel free to Contact me.
The reframe from do I trust this agent to do I trust this specification is the right move. Trusting the agent's judgment doesn't scale, but auditing a spec once and then enforcing it at the hardware boundary does, since the check only has to happen a single time instead of on every run.