What it is
Sandbox escape via code execution is an attempt to move from an agent’s intended, isolated interpreter into capabilities belonging to the host, neighboring workloads, or a protected network. A code interpreter can be valuable for calculations, transformations, and tests. The risk appears when the model can run arbitrary code, import dangerous modules, access host files or sockets, or reach a container runtime with more privilege than the task requires.
This page addresses the security boundary, not a particular exploit. A model-generated script can be unsafe because of a prompt injection, a malicious file, a dependency, or a programming mistake. “Sandbox” is also not a guarantee: isolation strength depends on the runtime, kernel, network, credentials, filesystem, and lifecycle. Do not test an escape against a real host without written authorization and a dedicated lab.
How it works
The attacker supplies code or content that causes the interpreter to inspect environment details, load an unexpected library, open a network connection, or invoke a host-facing interface. A tool may expose a shell, package installer, file mount, notebook kernel, or language runtime. If isolation is incomplete, the code can read beyond the work directory, contact private services, or influence another process.
An LLM can be the delivery mechanism: it may follow an instruction in a document and generate a script, or it may be asked to “debug” a harmless example until the code gains broader access. The backend must assume code and model output are untrusted. Blocking a few words in the prompt does not replace a hardened execution boundary.
Why it works
Convenient sandboxes often share a kernel, mount directories, credentials, DNS, or sockets with the host. Language-level restrictions can be bypassed when native extensions, subprocesses, reflection, or package installation are available. A model may also misunderstand the difference between a path inside the workspace and a host path.
The execution service is a powerful deputy. Once it accepts a script, the operating system—not the model’s refusal behavior—determines what happens. Network egress and broad file mounts turn a code bug into a data-flow problem; ambient credentials turn it into an identity problem. This is why model alignment can reduce risky requests but cannot certify isolation.
A safe, fictional example
The fictional Pebble Notebook runs Python-like snippets in a disposable container with a single synthetic file, /work/example.csv. A security test asks the notebook to list files only under /work and to calculate a count. A second test requests access to a protected fixture path, but the harness intercepts it and returns a canned denial. The container has no network, credentials, package installation, or host mounts.
The reviewer checks the process user, filesystem view, resource limits, network namespace, and cleanup after termination. A safe report describes which boundary held without including an escape script. The goal is to validate isolation assumptions, not to discover a path out of a live service.
Analyst to Notebook assistant: "Count the rows in example.csv"
Notebook assistant to Container: run snippet in /work
Container to Notebook assistant: count: 42
Notebook assistant to Container: read a protected path
Container to Host system: Blockedescape?
no network, no credentials, no host mounts
How to spot it
Watch for generated code that accesses paths outside the task workspace, imports process or networking modules, invokes shells, installs packages, inspects environment variables, or opens device and runtime sockets. These are review signals, not proof of an escape; legitimate tasks may need a carefully scoped subset.
Trace system calls, file accesses, network attempts, child processes, resource usage, and container identity. Alert when a task requests capabilities unrelated to its purpose or when an interpreter persists after the response. Redact file contents and credentials from logs. Test boundary probes in a disposable lab and compare behavior across runtime updates.
Defensive controls
Use strong OS- and network-level isolation, non-root identities, read-only minimal images, ephemeral workspaces, seccomp or equivalent syscall restrictions, resource quotas, and default-deny egress. Do not mount host sockets or sensitive directories. Remove credentials, package managers, and unnecessary interpreters. Separate code execution from the application’s control plane and destroy the environment after each run.
Treat generated code as untrusted. Parse and constrain tool arguments, require approval for elevated capabilities, and validate outputs before they reach other systems. Keep secrets out of the sandbox, monitor runtime behavior, patch the base image, and test escapes with synthetic fixtures and a dedicated security team. A model refusal is not a sandbox control.
Limits and nearby techniques
SSRF via an LLM agent targets network reach through a fetch tool; a sandbox escape targets the execution boundary, though the two can combine. Exploiting agent tool chains describes composing permissions. Covert channel data theft describes how data may leave after access is gained. Improper output handling can make generated code executable without a classic escape. Keep the threat model explicit: a sandbox may contain a model mistake but must not be trusted to authorize host access.