Abstract
“Run it in a sandbox” is the reflexive answer to agent execution risk. It is a good answer, but it is often stated with more confidence than the evidence supports. This publication does two things: it separates the two very different things people call a sandbox, and it draws a careful line between what the research actually demonstrates about agent escape capability and what remains speculative.
The honest position in September 2026: agents are demonstrably capable of exploitingknown vulnerabilities when given information [2], which means a container with a known-vulnerable configuration is at risk; but there is little public evidence of agents autonomously discovering and chaining novel escapes against a hardened boundary. We design for the capable case regardless, because the cost of being wrong is host compromise.
01What “sandbox” means here
A sandbox is only a security boundary if it was built as one. Most agent “sandboxes” are convenience containers that were never threat-modeled against a motivated occupant.
The word carries wildly different guarantees depending on the mechanism. A shared-kernel container isolates namespaces and cgroups but shares the host kernel — a large attack surface. A microVM or full VM gives each workload its own kernel behind a hardware boundary — a much smaller surface. Treating these as interchangeable is the root of most misplaced confidence.
02Two things called a sandbox
Agent deployments contain two nested containment problems, and conflating them causes design errors:
- The code-execution sandbox — where code the agent writes and runs executes (the interpreter, the test runner, the shell). This is the classic sandbox-escape surface.
- The agent process itself — the orchestration loop, its credentials, its tool connections. Even with a perfect code sandbox, the agent process can misuse its legitimate tools (the injection story) without escaping anything.
This distinction matters because many teams harden the code-execution sandbox and consider themselves done, while the agent process retains broad tool authority and network access. The most damaging incidents in this series (GTG-1002, EchoLeak/CamoLeak) required no sandbox escape at all — the agent abused authority it was granted. Sandbox escape is a real but secondary boundary; do not let it distract from the primary one.
03Classic escape classes an agent inherits
When an agent can run arbitrary code, it inherits the entire, well-documented catalogue of container-escape techniques. None of these are novel to AI; what is new is a tireless occupant that can enumerate and attempt them at speed:
| Class | Root cause | Mitigation |
|---|---|---|
| Misconfiguration | Privileged flag, mounted Docker socket, host mounts | Rootless, no host mounts, no socket exposure |
| Excess capabilities | Default or added Linux capabilities (e.g. CAP_SYS_ADMIN) | Drop all caps; add back the minimum; seccomp |
| Kernel vulnerability | Shared host kernel with an exploitable flaw | Patch; user namespaces; microVM to shrink shared surface |
| Shared resources | Shared network, IPC, or filesystem with host/peers | Network isolation; read-only rootfs; per-workload FS |
| Supply chain | Malicious dependency runs inside the sandbox | Pin/verify; deny egress; treat sandbox contents as hostile |
04What the evidence actually supports
The peer-reviewed work does not (yet) measure “can an agent escape a hardened sandbox.” It measures adjacent capabilities that bound the risk. Read precisely:
LLM Agents can Autonomously Exploit One-day Vulnerabilities
R. Fang, R. Bindu, A. Gupta, D. Kang — submitted 2024-04-11 · revised 2024-04-17
- Question
- Can an agent exploit a real vulnerability once it knows what the vulnerability is?
- Method
- A single agent with tools attempts real one-day vulnerabilities; measured with and without the CVE description.
- Key finding
- 87% success when handed the description; ~7% without it.
- Reported metric
- 87% → 7% (with vs. without description)
- Limitations
- Exploitation, not escape; success is contingent on being told the weakness.
- Why it matters
- Implication for sandboxing: a sandbox with a known, unpatched weakness is squarely within demonstrated agent capability. Patch discipline is a first-class agent-security control.
CVE-Bench: A Benchmark for AI Agents' Ability to Exploit Real-World Web Application Vulnerabilities
Y. Zhu, A. Kellermann, D. Bowman, P. Li, A. Gupta, et al. — submitted 2025-03-21 · revised 2025-06-24
- Question
- How reliably can agents exploit real-world vulnerabilities end to end under realistic conditions?
- Method
- Sandboxed benchmark of critical-severity real-world web CVEs with reliable success criteria.
- Key finding
- State-of-the-art frameworks resolved up to 13% — capability is real but far from saturated.
- Reported metric
- ≤13% resolved
- Limitations
- Web-app CVEs, not kernel/container escapes; benchmarks trail frontier models.
- Why it matters
- Tempers the fear: autonomous, reliable end-to-end exploitation of arbitrary hardened targets is not today’s reality — but the trend line is upward, so design for headroom.
05What remains speculative
We could not identify strong public evidence that an autonomous agent has, unaided, discovered and chained a novel escape against a properly hardened microVM boundary. Claims in this space frequently blur three different things: (a) an agent exploiting a knownmisconfiguration, (b) an agent using a supplied exploit, and (c) an agent discovering a novel escape. Only (a) and (b) are well-evidenced [1][2].
This is an open question, not a reassurance. Capability is rising and multi-agent coordination amplifies it [3]. The engineering response to an open question about a catastrophic outcome is to build for the pessimistic case — hence the defense below — while refusing to overstate the current evidence.
06Defense-in-depth isolation
- Prefer a microVM/VM boundary for untrusted code; shared-kernel containers alone are a weak boundary against a capable occupant.
- Run rootless, drop all Linux capabilities, apply a restrictive seccomp profile, mount the root filesystem read-only.
- Never mount the container runtime socket or host paths into the sandbox.
- Give the sandbox no ambient credentials and no host network; pair with deny-by-default egress (see egress control).
- Make sandboxes ephemeral — destroy and recreate per task so persistence cannot accrue.
- Patch aggressively: the 87% number means a known-vulnerable sandbox is exploitable [2].
07Production failure modes
A convenience container is mistaken for a security boundary
Mechanism
Agent-run code executes in a shared-kernel container started for developer convenience — sometimes privileged, with host mounts or the runtime socket exposed. The agent (or code it runs) reaches the host.
Why the existing control failed
The container was never threat-modeled as adversarial containment; it isolated for tidiness, not for security, and retained escape-enabling configuration.
Signals to monitor
- Attempts to access /var/run/docker.sock or host mounts
- Capability-probing syscalls; seccomp violations
- Processes enumerating the kernel version / known CVEs
- Unexpected outbound connections from the sandbox
Controls
- microVM boundary for untrusted execution
- Rootless, drop caps, seccomp, read-only rootfs
- No runtime socket, no host mounts, no host network
- Ephemeral sandboxes + aggressive patching
08Container, microVM, or remote execution service?
| Option | Boundary strength | Cost / latency | Where it fits |
|---|---|---|---|
| Shared-kernel container | Weak vs capable occupant | Low | Trusted code only; not untrusted agent execution |
| Hardened container (rootless+seccomp+userns) | Moderate | Low–medium | Lower-risk agent tasks with egress deny |
| microVM / VM per task | Strong (own kernel) | Medium | Untrusted code execution — the default for real isolation |
| Managed remote execution service | Strong + off your infra | Medium–high | When you want the boundary outside your network entirely |
For any agent that executes code it or an attacker may influence, make the default a microVM boundary per task, ephemeral, with no ambient credentials and deny-by-default egress. Reserve bare hardened containers for lower-risk, trusted-input work. The extra milliseconds of microVM startup are cheap next to host compromise — and they buy a boundary that does not depend on the shared-kernel attack surface.
09Limitations
- We deliberately do not cite unverified claims of autonomous sandbox escape; direct evidence for novel-escape discovery by unaided agents is, to our review, weak — treat this as an open question, not a settled one.
- Exploitation benchmarks [1][2] measure web-app and one-day exploitation, not container/kernel escape; we extrapolate capability direction, not a specific escape rate.
- microVM boundaries are strong but not infinite; hardware and hypervisor vulnerabilities exist, and misconfiguration can undermine any boundary.
- The "primary boundary is authority, not escape" argument holds for today’s incidents but does not license neglecting execution isolation as capability rises [4].
10Where this leads
Isolation is one wall; the fuller architecture — mediating every boundary and bounding blast radius by construction — is the subject of containment architecture. The network wall that holds even after an escape is egress control, and the capability trend that makes all of this urgent is read carefully in exploitation benchmarks.
—References
- Y. Zhu, A. Kellermann, D. Bowman, P. Li, A. Gupta, et al.. CVE-Bench: A Benchmark for AI Agents' Ability to Exploit Real-World Web Application Vulnerabilities. arXiv:2503.17332 [cs.CR], 2025. https://arxiv.org/abs/2503.17332
- R. Fang, R. Bindu, A. Gupta, D. Kang. LLM Agents can Autonomously Exploit One-day Vulnerabilities. arXiv:2404.08144 [cs.CR], 2024. https://arxiv.org/abs/2404.08144
- Y. Zhu, A. Kellermann, A. Gupta, P. Li, R. Fang, R. Bindu, D. Kang. Teams of LLM Agents can Exploit Zero-Day Vulnerabilities. arXiv:2406.01637 [cs.MA], 2024. https://arxiv.org/abs/2406.01637
- OWASP. OWASP Top 10 for LLM Applications & Agentic AI Threats and Mitigations. OWASP GenAI Security Project, 2025. https://genai.owasp.org/
Engineering assistance
ProxyTech works with engineers and teams building production AI, cloud, security, data and distributed systems. If this analysis maps to a system you are designing or operating, we provide hands-on support and interview preparation for these domains.