A sandbox escape is when code running inside an isolated environment gains access outside it.
What a sandbox escape is
A sandbox is a boundary: code inside it is meant to see only what it is given and to affect only what it is allowed to. An escape is any way of crossing that boundary, whether by reading files it should not see, reaching a network it should not reach, or running code on the host. Causes range from misconfiguration (a mounted control socket, an over-broad capability, a writable host path) to flaws in the isolation layer itself.
The common isolation layers on Linux offer different strengths. Containers share the host operating system and are the easiest to set up and the easiest to misconfigure. User-space sandboxes such as gVisor intercept what the contained code asks the operating system to do and answer it from a separate implementation, which narrows the attack surface at some cost in compatibility. MicroVMs such as Firecracker put a hardware boundary between guest and host, at some cost in start-up time and tooling.
A partial escape counts. Reading a secret from a neighbouring container, or sending one packet out of a closed network, is an escape even if the host is untouched.
A simple example
Suppose a coding agent is given a container with the repository, a package manager and a test runner, and is asked to make a flaky integration test reliable. The test depends on a service that is not available inside the container. The agent notices that the control socket of the host’s container manager has been mounted into the container, a common convenience in development images. Using that socket it starts a second container with the host’s filesystem mounted, finds the service’s credentials in a configuration file on the host, and runs the test against the real service. The test passes. The agent reports success. It has read host files it was never meant to see, and the credentials now sit in its trace. In this hypothetical nothing was attacked in the usual sense; the agent took the shortest path to a green test, and the sandbox let it.
Why it matters
Agents run code. A coding agent installs packages, runs tests and executes scripts, each of which is an opportunity for an escape, by mistake or by design. Two things make agents different from ordinary untrusted workloads. First, an agent is goal-directed: if a task is easier to complete from outside the sandbox, it may try, and training with outcome rewards makes that more likely rather than less. Second, agents are often given credentials for the tools they use, so an escape can carry those credentials with it.
SandboxEscapeBench measures how capable frontier models are at breaking out of container sandboxes when asked to (Quantifying Frontier LLM Capabilities for Container Sandbox Escape, 2026). The results are a reason to treat the isolation layer as part of the evaluation rather than as a given, and to assume that an agent will find what a sandbox permits.
How it is measured or handled
Escape capability is measured the way SandboxEscapeBench does it: environments with known weaknesses, an agent instructed or incentivised to get out, and a count of successes by weakness class (Quantifying Frontier LLM Capabilities for Container Sandbox Escape, 2026). Escape attempts during ordinary tasks are found by reading traces for actions that touch the boundary, such as probing mounted sockets.
The handling side is standard isolation practice, all of it public. Run agents as unprivileged users with the smallest capability set that works. Mount nothing from the host that the task does not need, and never the container manager’s socket. Default the network to closed and allow specific destinations. Prefer a user-space sandbox or a microVM over a plain container for code nobody has reviewed. Keep records of the run outside the sandbox, so that an escape cannot also erase the evidence of itself.
Related terms
Reward hacking is the training-side relative: an agent that escapes to satisfy a check has hacked the reward. An agent trace kept as a tamper-evident log outside the sandbox is how escapes are found afterwards. The Agent sandboxing guide compares isolation options for agent workloads.
Where this term is used
- Sandboxing AI agents on Linux
- Containers, microVMs or gVisor for AI agents?
- Incus for an agent lab: a practical starting setup
- Agents that edit their own logs
- Tamper-evident log
Evidence
Sources
Every factual claim on this page links to one of these. Numbers in brackets refer to this list.