6 ms·

> I stress about my agent sandboxes all the time Same here, so I ended up moving the whole dev environment (editors, agents, containers) inside a hardened QEMU

> I stress about my agent sandboxes all the time Same here, so I ended up moving the whole dev environment (editors, agents, containers) inside a hardened QEMU/KVM VM that reaches the internet but has no route to the host, the LAN, or any other private address. I wrote a script to create such VMs and also verify network containment by scanning outward from inside the guest. Even then, I still don't feel great when running agents unattended. Write-up in case anyone's curious: https://karamatli.com/posts/network-isolated-kvm-sandbox-ai-agents/ https://karamatli.com/posts/network-isolated-kvm-sandbox-ai-...

sexylinux 1mo ago
Thank you very much for this helpful post!
- sparsesignal 1mo ago
  Thanks, glad it was useful
TacticalCoder 1mo ago
I do something similar and I've also got a nice script to provision my VMs. > So rather than pick one, this post advocates layering both, in the spirit of defense in depth: a sandbox VM wraps your containers along with the whole toolchain, and that sandbox reaches the internet but has no route to anything private. It's the first thing the biggest devops guru I know advised me to do. He told me to always ever ever run my containers inside VMs. I religiously followed his advice ever since and I couldn't be happier: I was already doing it before the AI days, to run "normal" containers. Now with these insane agents trying to break out, I'm happy that it's second nature to me. It's funny that, just like you, I'm using IPv4-only too for those VMs. I tried GPU-passthrough as a proof-of-concept (worked fine) but I've got no use for it yet. FWIW all my VMs are running on a 10 years old Xeon / 14 cores / 28 threads / ECC RAM. That's where the agents live. Thanks for the link to your write-up, very interesting to read from like-minded people and see what's similar and what's different in their solutions.
- embedding-shape 1mo ago
  > Now with these insane agents trying to break out, I'm happy that it's second nature to me. FWIW, the cases of these agents "breaking containment" is not someone asking "Create space invaders in HTML, CSS and JS" and the agent breaking out of containers and VMs to destroy the user's computer. They're effectively asking the agents "Answer question X, find the answer in any way you deem possible and applicable" during evaluations and letting them run for days, hoping the agents come up with their own strategies, which sometimes results in "cheating" like getting internet access to query public datasets, and similar stuff. And in this case, getting access to production databases to look up answers :) As long as your filesystem is disconnected from the container you run (so no synced/mounted volumes, instead copy stuff in, copy stuff out), you're safe just running agents in the container without full VM isolation.
- sparsesignal 1mo ago
  Thanks. Like you, I'd been running containers inside VMs for a while before the agents. Turns out it's right for them too. Making it IPv4-only simplified the firewall rules and network containment check, and made the boundary easier to reason about.

sexylinux 1mo ago

Thank you very much for this helpful post!

sparsesignal 1mo ago
Thanks, glad it was useful

TacticalCoder 1mo ago

I do something similar and I've also got a nice script to provision my VMs. > So rather than pick one, this post advocates layering both, in the spirit of defense in depth: a sandbox VM wraps your containers along with the whole toolchain, and that sandbox reaches the internet but has no route to anything private. It's the first thing the biggest devops guru I know advised me to do. He told me to always ever ever run my containers inside VMs. I religiously followed his advice ever since and I couldn't be happier: I was already doing it before the AI days, to run "normal" containers. Now with these insane agents trying to break out, I'm happy that it's second nature to me. It's funny that, just like you, I'm using IPv4-only too for those VMs. I tried GPU-passthrough as a proof-of-concept (worked fine) but I've got no use for it yet. FWIW all my VMs are running on a 10 years old Xeon / 14 cores / 28 threads / ECC RAM. That's where the agents live. Thanks for the link to your write-up, very interesting to read from like-minded people and see what's similar and what's different in their solutions.

embedding-shape 1mo ago
> Now with these insane agents trying to break out, I'm happy that it's second nature to me. FWIW, the cases of these agents "breaking containment" is not someone asking "Create space invaders in HTML, CSS and JS" and the agent breaking out of containers and VMs to destroy the user's computer. They're effectively asking the agents "Answer question X, find the answer in any way you deem possible and applicable" during evaluations and letting them run for days, hoping the agents come up with their own strategies, which sometimes results in "cheating" like getting internet access to query public datasets, and similar stuff. And in this case, getting access to production databases to look up answers :) As long as your filesystem is disconnected from the container you run (so no synced/mounted volumes, instead copy stuff in, copy stuff out), you're safe just running agents in the container without full VM isolation.
sparsesignal 1mo ago
Thanks. Like you, I'd been running containers inside VMs for a while before the agents. Turns out it's right for them too. Making it IPv4-only simplified the firewall rules and network containment check, and made the boundary easier to reason about.