Hacker News Reader

Comment by debarshri | Hacker News Reader

Can someone elaborate with whats wrong with having containers for sandbox?

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)

So it's a mostly security thing.

But in the context of agents. Does it matter?

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.

This is a genuine concern. But this sounds a bit independent of the execution environment. It could either be containers or VMs.

On a local machine, yeah, I think it's pretty situational. VMs are safer, but in risk management terms the win is sometimes not that significant.

In a multitenant cloud environment, of course, totally different story.

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

Imo it's even more important in context of agents, if these agents are as good as it's going to get with as much access as we let them.

One could theoretically use a prompt injection attack to exploit a privilege escalation vulnerability on the kernel.

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?

From what I read others say at some point on HN:

- resources

- security

- setup speed?

I suppose a lot depends on how and in what environment you're dealing with agents.

Resources might be an issue on Mac if you have bunch of agents running different things, trying to execute code in different containers. But that's the issue of Mac and the way containers are running in a VM there.

Security-wise there were concerns with prompt injection telling agent to execute certain steps to escape from container. Possible, but I'm not aware if there were actually cases of that.

Luis wrote an excellent blog about it btw: https://www.luiscardoso.dev/blog/sandboxes-for-ai

Reply on news.ycombinator.com