When an AI agent runs code in a Python interpreter, Jupyter kernel, or similar environment, that environment is ideally sandboxed — isolated from the host operating system, with restricted filesystem access, no outbound network, and no ability to spawn system processes.

The sandbox is the primary technical control that prevents code execution from becoming host compromise. If it works correctly, even malicious code running inside the sandbox can't reach outside it.

Insufficient isolation: Many code interpreters used by AI agents are not true sandboxes — they're subprocess calls with limited restrictions. Python running in a subprocess on the host can still read environment variables, access mounted filesystems, and make system calls.

OS-level escape via system calls: Code that invokes os.system(), subprocess.run(), or direct syscalls can reach outside the Python runtime into the underlying OS. If the agent's container shares the host's kernel, kernel exploits can escalate further.

Container escape: Containerized sandboxes (Docker, similar) are stronger than bare process isolation but still have documented escape paths — privileged container flags, mounted Docker sockets, kernel vulnerabilities, and misconfigured volume mounts.

Dependency vulnerabilities: Libraries loaded inside the sandbox may have vulnerabilities that, when triggered by agent-generated code, escalate out of the sandbox through the library's host-level access.

Every other AG05 type operates within the agent's intended execution environment. Sandbox escape reaches the host — from which an attacker can access other containers, internal network services, cloud metadata APIs, or the hypervisor. A single sandbox escape can convert a limited code execution capability into full host compromise.