They are effective at fostering a false sense of security though.
They are effective at fostering a false sense of security though.
The threat with AI agents exists at a fairly high level of abstraction, and developing with them assumes a baseline level of good intentions. You're protecting against mistakes, confusion, and prompt injection. For that, your threat mitigation strategy should be focused on high-level containment.
I've been working on something in a similar vein to yolobox, but the isolation goal has more to do with secret exfiltration and blast radius. I'd love some feedback if you have a chance!
Assuming a standard Docker/Podman container with just the project directory mounted inside it, what vectors are you expecting the LLM to use to break out?
> 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
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 :)
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.