I have a solution based on Nix that can be used to generate reproducible container images: https://github.com/nothingnesses/agent-images . It lets you customise which agents, harnesses, or any other packages you want included in the VM and it uses `agent-box` for sandboxing.
It's a batteries included alternative to firecracker with a couple of new ideas tossed into the mix i.e. portable like a container (bake into a single file and rehydrate the vm anywhere), dynamic resource allocation, etc.
Ah let's see, do they still want you to LOGIN, in order to use a local dev tool? Yes, yes they do. No thanks Docker. You can keep your buzzword reasoning as to why this is needed.
The one thing I wonder about is how you enforce the usage of Docker Sandboxes vs running the agent on the host directly, apart from scanning machines for binaries
Do the agents come preinstalled in the images? Or do they somehow use whatever I’ve installed locally? The former makes sense to me but then I’m wondering whether the sandbox images stay up to date with new releases of each image.
Like many people, I suspect, I used Claude to write my own agent sandbox that suits my needs very well. Investing my time in a propietary product has become a hard sell.
You want to prevent the agent/others from reaching your home directory and other things. As long as you don't mount/sync directories/files from/to the container, so no mounting like "-v $(pwd):/app", but instead copy in, then when done, copy out.
And of course, instead of doing the "copy in > copy out" process manually, get your local agent to write a bash script that does that for you, given what directory you're in, and you're basically G2G.
Sure, but all projects are version controlled? You only mount the project dir so you can only loose your current changes - which is the same if you copy...
> Were you following any patterns/standards/advice on what you needed to protect against?
Just the general knowledge that sharing a kernel with untrusted software is too dangerous, that hardware virtualization is an infinitely smaller attack surface and that the entire industry will be in deep shit if people or AI breaks hypervisors.
Initial threat model was supply chain attacks but eventually grew to include AI harnesses as well. Not very worried about them hacking me, more about accident prevention.
So that means each VM must be running a completely independent kernel that's fully isolated from the host's file system. They must also have fail closed network filtering built in.
In summary, it's a QEMU VM orchestrator with a base OS image and project specific delta images. VM lifecycle is managed by systemd. System level isolation is already pretty good and it already solves the "AI wiped out my $HOME" problem. I'm currently working on a custom network stack to replace the nftables based firewall.
I did the same thing. It was my first "vibecoded" project. I've been using it every day and it's great. I'm writing a custom Rust network stack for it right now. Gonna replace the current nftables firewall with it.
As for Docker Sandboxes, I'll just ask Sol literally right now to see what it does better than my virtdev, and then I'll improve virtdev instead of using Docker.
TO me, that's the important distinction: sandboxing limits what the agent can do but it doesn't necessarily enforce that the agent must run inside the sandbox. You need a separate control layer to enforce that boundary.
You design the sandbox so the agent starts in that layer. The next thing you can do is to limit the network access, this is what I'm working on right now.
392 comments
Also if your thing doesn't work with `pi` out of the box, then low effort
{ "allowedHosts": [ ".anthropic.com", ".claude.com", ".pi.dev", "npm.org", ".npmjs.org", ".github.com", ".githubusercontent.com", ".pypi.org", ".pythonhosted.org" ], "baseImage": "docker.io\/library\/node:22", "displayName": "Pi", "environmentVariables": [ "IS_SANDBOX=1" ], "installCommands": [ "npm install -g --ignore-scripts @earendil-works/pi-coding-agent", "npm install -g global-agent" ], "launchCommand": [ "pi" ], "mounts": [ { "containerPath": "\/root\/.pi", "hostPath": "~\/.pi", "readOnly": false } ] }⏎
(I am testing this now as a backend for my pet project which currently supports firecracker and gvisor. No network.)
Other than the login problem, it’s a decent option.
And of course, instead of doing the "copy in > copy out" process manually, get your local agent to write a bash script that does that for you, given what directory you're in, and you're basically G2G.
Start by mounting just your repo and passing in the keys for the agent. Take it from there, it's like software engineering, you iterate.
When you run into issues you expand the tools in the container available to it.
Just the general knowledge that sharing a kernel with untrusted software is too dangerous, that hardware virtualization is an infinitely smaller attack surface and that the entire industry will be in deep shit if people or AI breaks hypervisors.
Initial threat model was supply chain attacks but eventually grew to include AI harnesses as well. Not very worried about them hacking me, more about accident prevention.
So that means each VM must be running a completely independent kernel that's fully isolated from the host's file system. They must also have fail closed network filtering built in.
> Anything you can point the rest of us to?
I have published my virtdev's design document.
https://github.com/matheusmoreira/virtdev/blob/master/DESIGN...
Yes, it is AI generated.
In summary, it's a QEMU VM orchestrator with a base OS image and project specific delta images. VM lifecycle is managed by systemd. System level isolation is already pretty good and it already solves the "AI wiped out my $HOME" problem. I'm currently working on a custom network stack to replace the nftables based firewall.
As for Docker Sandboxes, I'll just ask Sol literally right now to see what it does better than my virtdev, and then I'll improve virtdev instead of using Docker.
Or do you mean something else?