Are we defaulting to VM-level sandboxing before understanding the threat model? | Hacker News Reader

Are we defaulting to VM-level sandboxing before understanding the threat model?

3 pointssamhita-alla3 comments

Hey everyone, I'm Samhita and I work at Union.ai. We've been building infrastructure for running agents and building models, which naturally got us thinking a lot about sandboxing. One thing I've been wondering: are we overusing heavyweight sandboxing solutions?

I think some form of isolation is non-negotiable when you're running model-generated code. Things like process isolation, filesystem restrictions, network controls etc. make complete sense. What I'm less sure about is whether VM-based approaches are necessary as often as people seem to think.

In my experience using coding agents locally, basic guardrails and sensible restrictions have been enough most of the time, at least when I'm operating in a relatively controlled environment and not deliberately pushing the agent into risky situations. Of course, that's very different from a production service running arbitrary user code.

So I'm curious: - What are you using to sandbox agents today? - What threat model are you optimizing for? - Have you had incidents that convinced you VM-level isolation was necessary? - Where do you draw the line between "good enough" and "needs stronger isolation"?

Would love to hear what has worked (or not worked) for others.

This is what I've been working on the past month: a strategy for running sandboxed containers. It's not strictly for agents (I'm now using it for OpenCode). You should be thinking about supply chain attacks for all of your applications that use third-party dependencies. PyPI and NPM have had a lot of compromised packages recently. The litellm hack affected a lot of agents, and there have been some Docker escape exploits.

The threat model I'm concerned about is supply chain attacks on third-party package repositories. The primary goal is to keep the convenience of containers, but to limit the blast radius of a compromised package or application, and reduce the risk of container escape. The software stack I'm currently evaluating is:

- Kata Containers: Backend for containerd to run each container in a KVM-backed QEMU microVM (alternative to the standard runc).

- containerd: Container runtime. Docker and Podman are not compatible with Kata 3. Kata 4 is supposed to fix that.

- nerdctl: Docker-compatible front-end to containerd.

- cni-plugins: networking component for containerd. Used to isolate containers networks.

- iron-proxy: MitM, TLS-intercepting egress proxy. This restricts all outbound traffic to whitelisted domains and IPs, and supports secret injection. Squid is a more established alternative.

How is this used in practice? I have a small bash script to launch the sandboxed OpenCode container with the current folder bind-mounted. OpenCode only has file-system access to the context directory, and limited network/internet access.

Supply chain attacks are a reasonable use case. But do they require VM-level isolation?

For example, what about a sandbox that isolates arbitrary user code in its own process using kernel-level primitives like user namespaces, Landlock and seccomp? That's the same class of problem Claude Code and Codex are solving when they execute model-generated commands, and it should also limit filesystem and network access as you mentioned. It's process-level isolation rather than VM-level isolation, but it still provides meaningful containment. What do you think?

My concern is that people often default to VM-level isolation without really thinking through what it's meant to protect against and whether they actually need it. It comes with a fairly heavy infra burden and isn't necessarily the right answer for every use case.

I think process namespaces is what both Docker and Podman use along with cgroups for isolation. It should provide meaningful containment, and I was originally pursing using rootless Podman. But after hearing about the Copy Fail and recent container escape vulnerabilities, I'm concerned that is not enough. That's why I've opted for VM-level isolation, but at a more convenient level using KVM than full-fledged VMware VMs. I admit I'm not an expert in this space so maybe I'm overly cautious.

Reply on news.ycombinator.com