Comment by catlifeonmars
2 days ago
From “How it works” in the readme:
> yolobox uses container isolation (Docker or Podman) as its security boundary…
I have no issue with running agents in containers FWIW, just in framing it as a security feature.
> what vectors are you expecting the LLM to use to break out?
You can just search for “Docker CVE”.
Here is one later last year, just for an example: https://nvd.nist.gov/vuln/detail/CVE-2025-9074
Everything has CVEs, you can find CVEs in VM hypervisors if you like (the one you linked is in Docker Desktop, not Docker engine which is what this project uses).
There are valid criticisms of Docker/Podman isolation but it's not a binary "secure/not secure" thing, and honestly in this use case I don't see a major difference, apart from it being easier for a user to weaken the isolation provided by the container engine.
Docker/Podman security is essentially Linux security, it just uses namespaces+cgroups+capabilities+apparmor/SELinux+seccomp filters. There's a larger attack surface for kernel vulns when compared to VM hypervisors, but I've not heard of an LLM trying to break out by 0-day'ing the Linux kernel as yet :)
I’m not so much worried about a malicious agent, more so a confused deputy if that makes sense. The agent itself seems like a juicy RCE vector with a larger surface area than an unpatched binary. And think of all the side channels for delivering your exploits. You don’t need to bake into an executable payload, probably well crafted wording in a README.
Like you say, there’s a larger attack surface area for kernel vs hyper visor. If it’s easy to do, why wouldn’t you take advantage of the extra isolation of a VM?
It’s 2026 and microVMs are a thing. The DevX gap between VMs and containers is shrinking.