Edera Publishes Manifesto on Hardware-Level Sandboxing for AI Agents
Key Takeaways
- ▸Current industry 'sandboxes' (Docker, containers, namespaces) fail to reliably contain AI agents; Edera's benchmark demonstrated ~50% escape rate for LLM agents in Docker
- ▸A true sandbox must use hardware-level microVM isolation enforced by hypervisors, not kernel-level controls that agents can exploit, disable, or race
- ▸Seven measurable properties define effective sandboxing: hardware boundary, zero ambient authority, small auditable trusted computing base, reproducible specifications, hypervisor-enforced limits, stateless design, and immutable isolation
Summary
Edera has published 'The Sandboxing Manifesto for Agentic Execution,' a technical position paper arguing that current sandboxing approaches are fundamentally inadequate for safely containing AI agents. The manifesto challenges the industry's diluted use of the term 'sandbox,' pointing out that Docker containers, seccomp profiles, and kernel-level namespaces fail to provide genuine isolation for untrusted AI agents that can install packages, call APIs, and touch production systems.
The paper defines a proper sandbox through seven specific, verifiable properties: hardware-level isolation via microVMs rather than shared kernels; zero ambient authority (workloads start with no filesystem, network, or host services); small auditable trusted computing bases; reproducible, hash-verifiable specifications; hypervisor-enforced resource limits; fresh state at startup with automatic cleanup; and immutable isolation boundaries that configuration cannot weaken. The key insight is that security boundaries must be enforced outside the kernel (on the hypervisor), never inside it.
Edera's red-team benchmark supports the urgency: LLM agents successfully escaped Docker containers in approximately 50% of 18 tested scenarios, while hypervisor-isolated zones blocked all escape attempts (except one that fell to misconfiguration rather than kernel exploit). The manifesto argues that microVM performance has eliminated the pragmatic case for shared-kernel isolation—microVMs now cold-start in milliseconds and can scale to millions per server—making hardware-level sandboxing both necessary and feasible.
- Modern microVM performance makes per-task hardware isolation both practical and cost-effective; shared-kernel approaches are no longer a necessary compromise
- Sandboxing is fundamentally a security boundary problem, not a configuration problem—isolation must execute on the hypervisor boundary, and configuration cannot weaken it
Editorial Opinion
Edera's manifesto exposes a critical gap in AI infrastructure thinking: the false comfort of 'sandbox' labels applied to solutions that don't actually isolate untrusted code. With AI agents gaining capabilities to write code, call APIs, and modify systems in real-time, the difference between a Docker container and true hardware isolation is no longer academic—it's a security prerequisite. The seven-property framework is refreshingly testable, and the 50% Docker escape rate should disabuse anyone of faith in current practices. This work should force a reckoning: organizations deploying production agents should demand hardware isolation, not accept whatever 'sandboxing' vendor marketing claims.
