Sandboxes Explained: What Each Type Actually Isolates

Sandboxing is necessitated by the reality that code being run often does not fully trust its execution environment, whether due to hostility, accumulating dependencies, or the need for consistent behavior. The motivations for sandboxing fall into three categories: Security (limiting hostile code access), Blast radius (limiting buggy code impact), and Reproducibility (ensuring consistent behavior). Different sandbox implementations prioritize these goals, leading to trade-offs. Virtual machines offer the strongest boundary but incur high cost, while containers rely on a shared kernel and configuration for isolation, which is inherently less secure due to shared failure modes. Language runtimes provide fast isolation but inherit large attack surfaces. Agent sandboxing shifts the focus from physical containment to defining allowed actions, focusing on controls like filesystem scoping, egress allowlists, action classification, and scoped credentials. This shift acknowledges that an agent introduces a policy problem—a confused deputy—rather than just a process containment problem.

The core tension in modern isolation lies between physical reality (VMs), architectural convenience (Containers), runtime speed (Language Runtimes), and operational complexity (Agent Sandboxes). The piece reveals that a sandbox is not a fixed object but an artifact of the threat model applied. Physical boundaries like VMs offer the strongest defense against resourceful attackers, reflecting hardware-enforced separation, yet they are operationally burdensome. Conversely, the rise of agent sandboxing suggests that for complex workflows involving human intent and multi-step reasoning, the focus must shift from isolating a process to governing accumulated authority. The shift from containment ("what can it touch?") to policy ("what can it do?") is crucial because the latter accommodates the semantic complexity introduced by LLM interactions, where instructions are indistinguishable from legitimate context. This implies that security success is less about perfect isolation primitives and more about designing feedback loops—like logging accumulated actions—that capture the history of delegated authority before a failure occurs. The lesson is that in systems where intelligence delegates actions, the greatest risk lies not in escaping the perimeter, but in the accumulation of unlogged, implicitly granted permissions over time.