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.