What is Sandboxed Execution?
Also called Code Sandbox, Isolated Execution.
Sandboxed execution is running code or tools produced or invoked by an AI system inside a strongly isolated environment with restricted access to the filesystem, network, host resources and other tenants' data. It exists because model generated code should be treated as untrusted input, regardless of whether the model that produced it is considered reliable.
The threat is not only a malicious model. Code can be wrong in destructive ways, and an agent processing untrusted documents can be manipulated into generating code that exfiltrates data or damages state. Isolation is what turns those events into a contained failure rather than a host compromise, so the sandbox is sized to the worst plausible outcome rather than the expected one.
Isolation strengths differ. Language level restrictions and interpreter subsets are the weakest and have a long history of escapes. Containers with a restricted system call profile and no privileges are stronger. Lightweight virtual machines and user space kernels provide a further boundary, and separate ephemeral hosts are stronger still. The choice depends on how untrusted the workload is and how sensitive the surrounding environment is.
Beyond isolation, sandboxes apply resource and lifetime limits: CPU and memory caps, execution timeouts, disk quotas, process count limits, and destruction of the environment after each task so nothing persists between requests or between tenants. Network access defaults to none, with explicit allowances added for the specific destinations a task genuinely requires.
Data placement matters as much as the boundary. A sandbox that mounts production credentials, a broad cloud role or a shared filesystem has an isolation boundary in name only, since the code inside can reach whatever the environment can reach. Sandboxes are therefore provisioned with narrowly scoped, short lived credentials and only the inputs the task needs.
Key points
- Treat model generated code as untrusted input
- Isolation strength ranges from interpreter limits to separate virtual machines
- Apply CPU, memory, time and process limits, then destroy the environment
- Default to no network, allowing only required destinations
- Never mount broad credentials or shared data inside the sandbox
In practice
An analysis assistant writes Python to summarize an uploaded spreadsheet. The code runs in a short lived container with no network access, a read only mount containing only that file, a memory cap and a thirty second timeout, under an unprivileged user with a restricted system call profile. The container is destroyed after the run, so a script that attempts to read other paths or open a connection simply fails.