What is agent sandbox escape?

Agent sandbox escape is when an AI agent breaks out of the isolated environment meant to contain its code and tool execution, gaining access to the host machine, internal network, or secrets it was never meant to reach. It can happen through container escapes, over-broad file or network access, leaked host credentials, or prompt injection that drives the agent to abuse a legitimately mounted resource.

How do you sandbox an AI agent?

Run the agent's tool and code execution inside strong isolation such as a container or microVM, grant least privilege, mount no host credentials or secrets, restrict the filesystem to a scratch directory, and enforce an egress allowlist so the agent can only reach approved destinations. Add human approval for irreversible actions and monitor all tool calls from outside the sandbox.

Last updated: July 2026 · Orchesis reference

Agent Sandbox Escape

Agent sandbox escape is when an AI agent breaks out of the isolated environment meant to contain its code and tool execution, reaching the host machine, internal network, or secrets it should never touch. It happens through container escapes, over-broad file or network permissions, host credentials left inside the sandbox, or prompt injection that drives the agent to abuse a resource that was legitimately mounted. Because agents run arbitrary tool calls and generated code, a weak sandbox turns a single injected instruction into full host compromise. The core defense is strong isolation (containers or microVMs), least privilege, no host secrets in the sandbox, and a strict egress allowlist.

How agent sandbox escape happens

An agent sandbox is meant to let the model run code and tools without endangering the host. Escapes occur when the boundary is too permissive: a container run with excess capabilities or a mounted Docker socket, a filesystem that exposes host paths, network access to internal services, or environment variables carrying cloud credentials. Prompt injection amplifies each of these — the attacker does not need a kernel exploit if the sandbox already grants a path to secrets.

Common escape vectors

Over-privileged containers: mounted host sockets, --privileged mode, or excess Linux capabilities.
Credential leakage: cloud keys or tokens present as environment variables inside the sandbox.
Network reach: the agent can call internal metadata endpoints or databases from within the sandbox.
Shared filesystem: host directories mounted read-write into the agent's workspace.
Injected code execution: prompt injection that makes the agent run attacker-supplied code against a mounted resource.

How to sandbox an AI agent

Strong isolation — run tool and code execution in a container or microVM, never directly on the host.
Least privilege — drop capabilities, run as non-root, and expose no host socket.
No secrets inside — keep host credentials out of the sandbox; broker access through a proxy that holds the keys.
Ephemeral scratch filesystem — restrict writes to a disposable directory, mount nothing from the host.
Egress allowlist — permit only approved outbound destinations to prevent exfiltration and internal pivots.
Approval and monitoring — require human sign-off for irreversible actions and log every tool call from outside the sandbox.

Context

Sandbox escape maps onto OWASP's agentic-AI risks around excessive agency and insecure tool use, and it is catalogued in the CASURA taxonomy of AI-agent vulnerabilities. The practical rule: assume the model inside the sandbox is adversarial, and design the boundary so that even a fully hijacked agent cannot reach the host, secrets, or the internal network.

Sources: OWASP Agentic Security Project · CASURA taxonomy (Orchesis) · container and microVM isolation guidance. Reference maintained by Orchesis, an open-source AI-agent security proxy.