A sandbox is a restricted execution environment: programs running within it can only access explicitly permitted resources, making it difficult for errors or malicious exploitation to affect the host system and other programs. The premise of a sandbox is handling "untrusted code," meaning programs from third parties, user inputs, or model generations cannot be assumed secure by default.

The conceptual origin of sandboxes lies in process isolation in operating systems. In 1979, Version 7 Unix introduced the chroot system call (later added to BSD by Bill Joy in 1982), which locked a process's root directory to a specific subtree, making the rest of the file system "invisible" to it. In 1993, Wahbe et al. proposed Software Fault Isolation (SFI) in the paper Efficient Software-Based Fault Isolation, using instruction rewriting to restrict memory access of untrusted modules to their own address segments, achieving fault isolation without launching virtual machines. In the mid-1990s, Java applets turned "sandbox" into a common term: code in browsers was by default limited to specific actions, requiring explicit authorization for elevated privileges. Dean et al. systematically analyzed this model in the paper Java Security: From HotJava to Netscape and Beyond.

Modern sandbox implementations are built on three stacked layers: kernel primitives, virtualization, and language runtimes. The kernel layer uses seccomp to filter system calls and namespaces and cgroups to isolate views and resources, allowing containers to be isolated from each other on the same kernel. The virtualization layer uses lightweight micro-VMs to achieve stronger boundaries; Firecracker reduces boot time and memory overhead to the millisecond level with a streamlined device model (Firecracker: Lightweight Virtualization for Serverless Applications, NSDI 2020). The language layer integrates sandboxes into runtimes, where WebAssembly's linear memory and import mechanism allow modules to only access explicitly passed objects. In recent years, as AI agents began executing model-generated code, sandboxes have shifted from "security mechanisms" to "default infrastructure."

The value of sandboxes lies in limiting the impact of faults and attacks within boundaries, allowing untrusted code to be run safely, repeatedly evaluated, and rolled back at any time. However, they are not absolutely secure: kernel vulnerabilities, side channels from shared caches, and configuration oversights can compromise isolation, making "escape" a constant focus of offense and defense. On the other hand, there is a cost: the stronger the isolation, the fewer system capabilities are available, requiring file, network, and GPU access to be granted item by item. The engineering challenge of sandboxes is precisely to draw an appropriate boundary between "containment" and "usability" for each task.

[JIALIU_0]