A Sandbox Isn't a VM or Docker — It's a Security Boundary, and AI Agents Are Making It Urgent Again
When an AI agent can autonomously read files, execute shell commands, and modify code, the security question shifts from "did the human approve this action?" to "what is the agent even capable of touching?" Sandboxing draws that hard boundary, and agent frameworks are now building it in by default.
The core idea of a sandbox is restricting a program's blast radius, not where it runs. It can be implemented with containers, VMs, seccomp, or OS permissions, but the defining question is always: what is this code allowed to do? A sandboxed process may see a tailored filesystem, a truncated process list, or no network at all — sometimes it doesn't even know the restricted resources exist.
AI coding agents are forcing sandboxing back into the spotlight. When an agent moves from suggesting commands to executing shell, reading files, and modifying code autonomously, the permission model flips from "does the human approve?" to "what is the agent even allowed to touch?" Tools like OpenClaw now route agent execution into Docker-based sandboxes with read-only filesystems, no outbound networking, and stripped Linux capabilities by default.
Browsers have run on this principle for years: JavaScript can manipulate the DOM and make fetch calls, but it cannot read your SSH keys or kill other processes. That same boundary — "your world ends here" — is what sandboxing brings to agentic code execution.
Sandboxing is often misunderstood as a product category when it is actually a design goal; conflating it with Docker or VMs leads to over-trusting a technology rather than verifying the boundary it enforces.
The shift from AI-as-advisor to AI-as-actor changes the security model from a human-in-the-loop approval gate to a pre-declared capability boundary — a fundamentally different threat model.
Filesystem isolation can be stronger than permission denial: a sandboxed process that cannot even see a directory is safer than one that merely lacks read access, because it eliminates information leaks about what exists.
Security in sandboxing is layered — file restrictions, process isolation, network blocks, and syscall filtering each act as independent gates, so a breach at one layer does not automatically compromise the whole system.