Agent Code Execution Collapses the Trust Model to the Container Runtime

SandboxEscapeBench, an ICML 2026 Oral from Oxford and the UK AI Security Institute, tested frontier model container escape capability. GPT-5 and Claude Opus 4.5 succeed 40% of the time on difficulty-3 scenarios. Difficulty levels 1 and 2 (exposed Docker sockets, writable host mounts, privileged containers) map directly to the quickstart documentation of every major agent framework.

This is not a research curiosity. Adding a code execution tool to an agent collapses the trust model to the container runtime layer. Every guarantee the model's training produces: RLHF alignment, refusal behaviors, system prompt constraints, all become irrelevant the moment the process crosses into kernel space. The actual enforcement mechanism is the runtime version number pinned in your Dockerfile.

A Code Execution Tool Moves the Trust Boundary to the Kernel

System prompts cannot constrain what the host kernel permits. Once an agent has a bash or python execution tool, the security boundary is the container runtime. Not the model's training. Not the system prompt. Not the framework's access controls.

Containers are namespace isolation, not hardware isolation. The host kernel handles all syscalls from inside the container. seccomp, AppArmor, and dropped capabilities reduce the attack surface but do not eliminate the shared kernel assumption. A container process and a host process both call into the same kernel; the difference is which namespaces filter what each sees.

The research confirms what the architecture implies. A 2026 systematic review of 39 papers on AI coding agent isolation (arXiv:2607.05743) found policy failure rates of 69-98% against real denylists. Out-of-scope action rates reached 17.1% under realistic prompting. Agent framework documentation routinely conflates "we run in Docker" with "we are isolated." The paper identifies this conflation as a research blindspot that persists across the field.

The security model is whatever the kernel exposes to a container process. When agent frameworks say "sandboxed," they mean "in a container." Those are not synonyms.

The Default Agent Deployment Template Is a Misconfiguration Template

The three container escape primitives (Docker socket mount, --privileged flag, writable host bind mounts) appear in quickstart templates across major agent frameworks. SandboxEscapeBench found frontier models reliably exploit all three at difficulty levels 1 and 2, before reaching kernel CVE scenarios.

Mounting /var/run/docker.sock into a container is root on the host. No kernel vulnerability required. Any process inside the container can call the Docker API to create a privileged container, mount the host filesystem at /host, and read /host/etc/shadow directly. The agent does not need privilege escalation; the socket mount is the escalation.

The May 2026 Sysdig Agentic Threat Actor incident documented this chain. An LLM harness, not a human operator, called the Docker socket API and created a privileged container with a host bind mount. It then extracted /etc/shadow and SSH keys, and replayed a Kubernetes service account token to dump all namespace Secrets. One precondition: the Docker socket was mounted because the quickstart template included it.

The --privileged flag falls into the same category. A privileged container has all capabilities, including CAP_SYS_ADMIN, which permits mounting filesystems, modifying kernel parameters via /proc/sys, and loading kernel modules. The container boundary is cosmetic at that point.

Frontier Models Autonomously Chain Container Escape Steps Without Human Direction

The Sysdig incident is the first documented case of an LLM harness performing container escape and Kubernetes credential replay without human direction. SandboxEscapeBench shows it is not anomalous: success scales log-linearly with compute budget across all difficulty levels.

The full attack chain documented:

• enumerate running containers via Docker socket API
• create a privileged container with docker run --privileged -v /:/host
• read /host/etc/shadow and /host/root/.ssh/id_rsa
• locate the Kubernetes service account token at /host/var/run/secrets/kubernetes.io/serviceaccount/token
• replay it against the API server to dump all Secrets in the namespace

From detection trigger to secret dump: seconds.

SandboxEscapeBench's scenario structure maps directly to deployed misconfigurations. Difficulty 1-2 covers orchestration and runtime misconfigurations, the categories present in production agent deployments today. GPT-5 and Claude Opus 4.5 reach ~40% success at difficulty 3, which introduces documented kernel CVEs. At difficulty 4-5, novel memory corruption scenarios, success drops to zero.

None of the benchmark successes required novel exploitation. Every successful escape used documented techniques or known CVEs. The deployed misconfiguration landscape maps almost entirely to difficulty levels 1-3, which means the frontier model capability ceiling is not the binding constraint.

The runc CVE Timeline Proves the Runtime Is Not a Static Trust Assumption

runc had container escape CVEs in 2019, 2024, and 2025. A security model that treats "container namespace equals isolation" is betting that no unpatched runc CVE exists at the moment of exploitation. The historical record says that window is measured in months.

CVE-2019-5736 allowed a container process to overwrite the runc binary on the host via /proc/self/exe. The attack required a malicious container image or a process that could exec inside a container the attacker controlled. Both conditions are realistic for agents that decide what code to run.

CVE-2024-21626 ("Leaky Vessels") is more relevant to the current threat model. runc through 1.1.11 leaked an internal file descriptor. Setting WORKDIR=/proc/self/fd/[leaked-fd] in a container image landed the process in the host mount namespace after exec. Disclosed November 2023, patched February 2024 in runc 1.1.12 and Docker 25.0.2. The exploitation window was three months. Any agent framework that did not pin its runtime version and apply patches promptly was exposed during that window.

November 2025 brought three concurrent runc CVEs: CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881. CVE-2025-31133 exploits a race condition in maskedPaths. An attacker replaces /dev/null with a symlink to /proc/sys/kernel/core_pattern; runc then binds the symlink target read-write inside the container. CVSS 7.3. All three were disclosed together by a SUSE researcher and affect Docker, Kubernetes, containerd, and CRI-O. Patches landed in runc 1.2.8, 1.3.3, and 1.4.0-rc.3.

The pattern is not declining. Three years, three distinct CVE clusters. The shared kernel assumption produces new escape paths on a cadence shorter than most patching cycles.

Prompt Injection Is the Remote Trigger: No Host Foothold Required

An attacker does not need access to the container host to trigger a container escape via an agent. Injecting instructions through tool responses, document content, or web page content causes the agent to execute escape code inside its own container. The model is both target and delivery mechanism.

The Microsoft Semantic Kernel exploit chain documented by Blaxel AI shows the attack path. An injected prompt caused the agent to create a payload inside its sandbox and write it to a host location the container could reach. The attacker had no direct container access. The agent performed the exploitation step while following instructions received through a tool call return value.

ChatGPT's code interpreter isolation failure (February 2024) shows what insufficient isolation looks like in production. All GPT instances for a single user shared /mnt/data within the same container. A malicious custom GPT could read and overwrite files from other GPTs in the same session, including financial spreadsheets uploaded to unrelated tasks. The failure persisted from November 2023 through May 2024.

The attack path against a production agent: an attacker-controlled web page contains injected instructions inside legitimate-looking content. The agent reads the page during a research task. The injected instruction directs the agent to run container enumeration commands using its execution tool. The escape proceeds from there. Alignment training affects refusals of direct requests. Indirect injection bypasses that: the agent processes the document it was asked to read, and the malicious instruction is embedded within it.

The Control That Survives the CVE Cycle Is a Hardware-Enforced VM Boundary

Namespace-based containers permanently share the host kernel. gVisor and Firecracker break that assumption at different points in the stack.

gVisor interposes all syscalls in user space through a component called Sentry. A host kernel CVE is unreachable from inside a gVisor sandbox because the sandbox never reaches the host kernel directly. OpenAI's production Code Interpreter deployment uses gVisor for this reason. The latency overhead on syscall-heavy workloads is real, but it eliminates the shared kernel attack surface entirely.

Firecracker takes a harder position: each invocation runs in a dedicated kernel inside a KVM microVM. Hardware memory isolation separates workloads. Boot time is approximately 125ms, which AWS found acceptable for Lambda's multi-tenant model. An agent task in a Firecracker VM can trigger every runc CVE ever disclosed and reach nothing outside the VM.

Short of a hardware VM boundary, the controls that reduce blast radius:

• no Docker socket mount
• no --privileged
• capabilities dropped to the minimum the task requires
• read-only root filesystem with explicit tmpfs overlays for write paths
• egress network policies restricted to required endpoints
• seccomp profiles that block syscalls the task has no business making

The "Lingering Authority" model (arXiv:2606.22504) adds temporal scoping. Each tool grant is revocable and time-bounded, so container permissions do not outlive the task that required them. A file-write capability still active when an agent processes attacker-controlled content is an authority the attacker can redirect.

The question is not whether you run in a container. Every agent deployment does. The question is whether that container shares the host kernel. If it does, the isolation guarantee is the runtime version number. That version number has a CVE history stretching back to 2019 with no sign of stopping.