Your AI Sandbox Is NOT a REAL Sandbox

Putting an AI agent in a container does not make it sandboxed. A standard container shares the host kernel, and an agent running attacker-influenced code is the case where that gap gets used.
This talk traces attacks from the first prompt to root on the host.
It begins in the agent: an MCP server whose tool description carries hidden instructions, and a GitHub issue that gets an over-permissioned agent to read a private repo and post its contents to a public pull request.
None of these steps exploits a vulnerability, the tools just do what they were built to do. It then moves to the runtime, where the code the agent was running, uses a known container escape to reach the host.
The two layers fail differently. Agent-layer defenses are not absolute, a well crafted prompt can past through them. No prompt gets past the kernel: gVisor and Kata reject the syscall on principle, not on wording. The session is packed with couple of demos and ends by running the same escape under runc and gVisor and on docker sbx toolkit,

key takeaways:

• If a workload runs untrusted code, learn how to give it a real sandbox environment: gVisor or Kata, user namespaces, capabilities dropped, seccomp on, admission control that rejects the dangerous pods, with egress denied by default.
• Plan as if the agent can be compromised. Put a boundary underneath that doesn't depend on the model behaving, and keep the prompt-level defenses where they belong, on top, as real mitigation, not as the thing you actually bet on.