| 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. |
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.