It's because containers share the kernel with the host. Generally it's just not considered a security boundary. (Note that containers have come a longer way in the security side btw)
What about VMs? They offer strong isolation, as they don't share kernels, and have long been a foundational piece for multi-tenant computing. Then, why would we put an extra layer on top and rebrand it as an AI agent sandboxing solution? I'm genuinely curious what pushes everyone to build their own and launch here Is it one of those tarpit ideas: driven by own need and easy to build?
Depends. Probably not usually. I've thought about this a bunch and I think the serious "threat" here isn't the agent acting maliciously --- though agents will break out of non-hardened sandboxes! --- but rather them exposing some vulnerability that an actual human attacker exploits.
I'd also add that I just don't like the idea in principle that I should have to trust the agent not to act maliciously. If an agent can run rm -rf / in an extreme edge case, theoretically it could also execute a container escape.
Maybe vanishingly unlikely in practice, but it costs me almost nothing to use a VM just in case. It's not impossible that certain models turn out to be poorly behaved, that attackers successfully execute indirect prompt injection via malicious tutorials targeting coding agents, or that some shadowy figure runs a plausibly deniable attack against me through an LLM API.
I’ve been experimenting with this recently. Running services inside microVMs instead of plain containers makes the threat model easier to reason about, especially for multi-tenant or untrusted workloads. I’ve been trying it out on Northflank and the trade-offs become pretty obvious.
security matters if want to demarc where agents can play. running agent inside of strong VM is usually where starts container not enough for that full isolation only sees files you want it to etc