The Sandboxing Manifesto | NOFire

Try now

Blog/Engineering<br>Engineering21 Jul 20265 min read<br>The Sandboxing Manifesto<br>A sandbox is a falsifiable claim. "Sandbox" has been diluted until it guarantees nothing. Ours is a definition sharp enough to be proven wrong: seven checkable properties, enforced by hardware-level microVM isolation, not by configuration.

Panagiotis MoustafellosCo-founder & CTO

Anastassios NanosCo-founder & Chief Scientist

Charalampos MainasMember of Technical Staff

Kostis PapazafeiropoulosMember of Technical Staff

Key takeaways<br>A sandbox collapses the trust problem from "do I trust this agent?" to "do I trust this specification?" The environment becomes a verifiable function of an auditable spec, enforced by hardware-level microVM isolation no configuration can weaken.<br>When a vendor says "sandbox," ask one question: where does enforcement execute? A guardrail running in the same kernel as the agent it polices is a suggestion, not a boundary.<br>The cost excuse is dead. MicroVMs cold-start in milliseconds and pack a million to a server. A shared kernel is not a pragmatic compromise anymore, just a weaker boundary.<br>Distilled from our white paper "Sandboxing for Agentic Execution". Companion reading: Design for Breach.

"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...