The login is annoying but, lacking an open source alternative, this has been my daily driver for a while now because it works great out of the box with two key features: outbound firewall and secret injection with placeholders.
I run it with superset and then each git worktree is mounted in a sandbox that is configured for each repo i work in.
I havent used nor gondolin neither docker's solution, but curious to know what gondolin is missing (evaluating both for my personal use)? is it only the DX or something else, if DX, can you what exactly is missing?
Eclipse Enclave does exactly that: There is an outbound firewall and secret injections, so that the agent never sees a real key. And it's fully open source: https://github.com/eclipse-enclave/enclave
Does secret injection really prevent that the agent send my GitHub key somewhere? If it has access to it via env var, can it not just paste it somewhere?
I just made my own devcontainer that I copy on any project and load whatever harness I want in that repo. Harnesss' config and auth are simply mounted from the host, so no setup required at all.
Before you use no sandbox at all use this or one the many similar projects but it's alway worth remembering that Docker is not a security boundary. It never has been meant to be and never will
become one.
cgroups are a mechanism designed for hierarchical organization and resource distribution. Against a malicious and capable actor, and that is how we have to treat AI agents, cgroups will not withstand.
Also, the kernal is an interface too big for what an AI agent needs and is therefore offering a gigantic attack surface completely unnecessarily.
I got excited for this not because this didn't exist before, but because Docker putting their weight on this would imply a broader adoption and better integration in the industry. I am sad that they are asking for a login here though, which doesn't make any sense to me.
I did try to use those for some stuff:
* Login requirement is something else
* It's closed source last I checked
* Pretty slow/unstable
There are many better namespace/container based options, VMs may be moderately more secure but when you more or less trust your agent and code you can do with lesser containment. And with the recent CVEs in kvm honestly there isn't a huge deal of difference vs namespaces.
(I'm building https://xbin.dev/ for some time now for managing my personal code/apps, a project which started specifically after Docker Sandboxes broke on me some time ago)
Can someone more versed in Docker explain to me how this is different than building my own docker container from a Dockerfile for using Pi agent harness? That's what I do currently. I use Docker Desktop in windows as the backend for that.
Docker containers use Linux kernel features to create an isolated environment, running on the same machine as docker is.
This creates a virtual machine, with its own kernel, and runs the container in there.
This gives stronger isolation and security guarantees.
I have the same question as GP. Your answer helps a little but not really. I might be naive, but I was under the impression that malicious code escaping a docker image and running amok on my host system was not something I should be too worried about. Especially if I run docker in rootless mode. Is that wrong?
For clarity I’m actually using podman, not Docker.
Oh no, you should definitely be worried about that. Podman might make it harder to escalate to host root, or manipulate other containers, but it is still vulnerable.
Now I'm curious to know how hardened the Docket Sandbox orchestration interface is. I guess we can assume they have run Mythos against it for a few weeks maybe? It's unclear.
Unsettling. I mean, is there any reasonable way to develop software in 2026? I've already sworn off ever installing npm directly on my host. Containerizing everything is laborious enough, but running a separate VM for everything?
Anyone serious about security will want to bring their own sandbox anyway, not trust these, often proprietary, agents. I've never run an agent outside a sandbox. My first bubblewrap script for `claude` is now over a year old. The tools are available and if you learn to use them you can run any program in a sandbox.
But, in any case, why put in effort doing something people don't expect or ask for? We can assume everyone running agents is either a) using their own sandbox, or b) doesn't care. I think we can guess which category most people fall into. You could maybe argue about responsibility, but I don't think you can argue about "serious engineering".
The sandboxing problem is perhaps the greatest justification for doing agent integration via existing human interfaces rather than low level shell access. Granting access to shell is a super obvious path (it's easy) so I can understand us wanting to fight for it. But we should consider the other paths as well before we make our final stand.
Automating browsers with LLM agents properly requires a lot more work than Process.Start into powershell, but the advantages can be immense once you have achieved integration this way. Incrementally maintaining this integration is generally easy because human users cannot tolerate rapid changes either.
It's a hell of a lot easier to convince management to adopt a robot that looks and acts like a human employee than one that looks like a combine harvester. The combine is far more efficient, but it is also totally indiscriminate. Nothing constrains its appetite except for the invisible fence imposed by GPS. The amount of infrastructure required to keep farm equipment from running astray is incredible. In the context of agriculture, the added complexity is definitely worth it. We don't want to have to recreate the same thing with our technology if it can be avoided. Sandboxes and security isolation boundaries are not things to aspire to. These are costs to be paid for admission to something more valuable.
I wish they solved the issue happening for years on MacOS where Docker keeps up eating all available free space and ends up requiring restart of the whole machine, instead of Gordon and other useless shit.
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.
I know some people want to run their agents when their computer is off, but I imagine a solution like this will be much more common than paying for a remote sandbox (i.e on fly.io or exe.dev), especially because it'll be free.
Though, they need to remove the login requirement.
I tried Docker Sandboxes but last time I checked you could not configure custom volume mounts, making more complex setups impossible. For work I need two directories for context for the agent to have access to…
I used this for a while then decided to build my own suites that pack individual harness and respective host state (config, plugins, skills, etc.) into an image. Works better and much flexible in my opinion.
Doesn't everyone do this now? It's hardly a new idea. Yet every time someone proposes the idea, people fawn over it and proclaim it the best thing ever.
Yes, you can inject tokens via a proxy. What else is new?
Who is doing it as first class feature with at least adequate UX?
I have skimmed alternatives offered in comments to this post (vibepod-cli, code-on-incus, opencode-docker, sandboxy, smolvm, amazing-sandbox) and none of them seem to do credentials injection at the proxy level.
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.
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.
> 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.
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.
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.
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.
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.
Not sure what you mean by "just". Containerisation is generally understood to mean something like what Docker does, which includes sandboxing but a whole lot more on top, like image management etc. Bubblewrap is just sandboxing without the rest of containerisation.
Customize the exact environment of your container from the ground up (harnesses, tools, base image, packages, mounts, etc) and enter with a single command.
What's a "microVM" and what's the security model here compared to using real virtual machines with actual constraints on breakouts?
Is it marketing fluff?
Incus/LXD has had VM's for a long time now.
I run it with superset and then each git worktree is mounted in a sandbox that is configured for each repo i work in.
Closest open source I have seen is https://earendil-works.github.io/gondolin but the DX is not as polished. https://exe.dev/ would be perfect but it does not come with outbound firewall.
Does anyone have a better alternative?
It has network filtering + placeholders for secrets.
OSS, no logins needed
thanks
It seems with gondoling i need to explain the agent to run commands in the sandbox, but then where does the agent run itself?
[0]: https://earendil-works.github.io/gondolin/workloads/
(it's in the doc, but kinda strange to not see some instructions on the main page, probably distro related)
Haven't tested it yet, but it seems to address the same issue as Docker Sandboxes, but in a different way.
https://github.com/iodize6399/ai-devcontainer/tree/main/.dev...
cgroups are a mechanism designed for hierarchical organization and resource distribution. Against a malicious and capable actor, and that is how we have to treat AI agents, cgroups will not withstand.
Also, the kernal is an interface too big for what an AI agent needs and is therefore offering a gigantic attack surface completely unnecessarily.
https://github.com/pkhamre/opencode-docker
There are many better namespace/container based options, VMs may be moderately more secure but when you more or less trust your agent and code you can do with lesser containment. And with the recent CVEs in kvm honestly there isn't a huge deal of difference vs namespaces.
(I'm building https://xbin.dev/ for some time now for managing my personal code/apps, a project which started specifically after Docker Sandboxes broke on me some time ago)
For clarity I’m actually using podman, not Docker.
Now I'm curious to know how hardened the Docket Sandbox orchestration interface is. I guess we can assume they have run Mythos against it for a few weeks maybe? It's unclear.
But, in any case, why put in effort doing something people don't expect or ask for? We can assume everyone running agents is either a) using their own sandbox, or b) doesn't care. I think we can guess which category most people fall into. You could maybe argue about responsibility, but I don't think you can argue about "serious engineering".
Automating browsers with LLM agents properly requires a lot more work than Process.Start into powershell, but the advantages can be immense once you have achieved integration this way. Incrementally maintaining this integration is generally easy because human users cannot tolerate rapid changes either.
It's a hell of a lot easier to convince management to adopt a robot that looks and acts like a human employee than one that looks like a combine harvester. The combine is far more efficient, but it is also totally indiscriminate. Nothing constrains its appetite except for the invisible fence imposed by GPS. The amount of infrastructure required to keep farm equipment from running astray is incredible. In the context of agriculture, the added complexity is definitely worth it. We don't want to have to recreate the same thing with our technology if it can be avoided. Sandboxes and security isolation boundaries are not things to aspire to. These are costs to be paid for admission to something more valuable.
Also if your thing doesn't work with `pi` out of the box, then low effort
(I am testing this now as a backend for my pet project which currently supports firecracker and gvisor. No network.)
Though, they need to remove the login requirement.
Yes, you can inject tokens via a proxy. What else is new?
I have skimmed alternatives offered in comments to this post (vibepod-cli, code-on-incus, opencode-docker, sandboxy, smolvm, amazing-sandbox) and none of them seem to do credentials injection at the proxy level.
There is no reason to require a login for creating local mini sandboxes.
If you’re on Apple, native solutions like “container-machine init” come built in and are pretty good, if you’ll only be on Apple hardware.
Don't give it shell access, just predefined tools.
For those who do not trust
AND do not want to use some other, free VM for some reason?container run --rm -it -v "$(pwd)":/work -w /work myaiimage /bin/bash
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.
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.
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.
On another topic, can't help but notice that "leading coding agents" somehow does not include Pi.
Or do you mean something else?
The other url is their marketing page.
Yes, Linux is supported.
[1] https://github.com/apple/container