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.
incus launch images:ubuntu/26.04 my-ubuntu-vm --vm
incus exec my-ubuntu-vm -- bashFirecracker is designed to start a VM in under 125ms and 5MB. Netbsd advertises that you can direct-boot a MICROVM kernel configuration in under 10ms.
There is a need for a Docker desktop like GUI for this market.
The world didn't fit around me, so I made "me" fit around "the world". I bet those stubborn dinosaurs can learn a new trick or two also, if management lets them do it during working ours...
Also, WSL (Windows Subsystem for Linux) has been baked into Windows for a long time and makes it very easy to play with Linux, as does using the Hyper-V VM system. Any developer unfamiliar with Linux because they use Windows, has little excuse.
I use something in between - a single Ubuntu VM, into which I spawn multiple Incus LXC containers for the agents. The containers only use 50 MB or so per instance (separate systemd, ...). This way I pay the VM RAM tax only once, and the agents are still contained inside the VM if they manage to escape the LXC containers.
docker run --runtime krun --rm -it -v $(pwd):/workspace/$(basename $(pwd)) -w /workspace/$(basename $(pwd)) --network restricted-net ghcr.io/openai/codex-universal:latest sh
(it's in the doc, but kinda strange to not see some instructions on the main page, probably distro related)
The option left is to use SSH to sign commits which is a no-go for a different reason.
https://github.com/iodize6399/ai-devcontainer/tree/main/.dev...
I quite like the 'features' layer system, adding extra tools to container in a declarative plugin-like way
Being able to 'safely' run with skip permissions has been a gamechanger
I especially like the firewall it has.
One other thing, I want to be able to handle multiple repos in the same sandbox and have a standard workflow around worktrees (one worktree per repo, all the worktree mounted in the VM).
These were some of the reasons that led me to build: Clawk - https://github.com/clawkwork/clawk
All the open GH issues about supporting Linux that I subscribed to have gone unresponded to.
OpenShell looks like a good alternative, but it still has "Do not use in production" plastered all over the website, which doesn't fill me with confidence yet
I wrote a tool to use `bubblewrap` to containerize any agent (at least all the agents I've used a couple of times), and bind mount the system stuff read-only, so the agent has your "usual" environment, but they can only see the project. Their history persists (either through a bind mount or a "shadow" copy of the history that only the wrapped agent sees), the agent can still create and manage containers of its own using podman's rootless mode, etc. It's nearly instant to start because it's just a namespace (plus a few copied files for the container support and session history); no container needs to be built/fetched/updated/whatever. bubblewrap is extremely well-tested as it is used by flatpak and several other large projects, so I trust it quite a bit (more than I trust Docker).
Regardless, I'm hoping something that isn't behind a login screen is going to win out.
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".
Exactly. It's not as though it's difficult. It never occurred to me to not do this from day one, and it astonishes me that anyone runs this stuff bare metal. Since then, I've brought several other people on board, and that's all they've ever seen: I don't think they'd know how to run outside a sandbox, and that's just fine.
Haven't tested it yet, but it seems to address the same issue as Docker Sandboxes, but in a different way.
But it’s not as well sandboxed for sure.
Eg, if used with Colima in macOS, it means I can run a devcontainer in an isolated VM and Nono inside the devcontainer can restrict a lot what can and cannot be done.
You get credentials proxying and network outbound limits.
How is Docker Sandbox better sandboxed?
Also if your thing doesn't work with `pi` out of the box, then low effort
But sbx is a bit annoying to use with OpenCode for instance (which has zero sandboxing by default, unlike codex CLI or Claude Code). You cannot easily change ~/.config/opencode/opencode.jsonc AFAIK.
[0]: Black Hat OpenAI-Hugging Face incident: https://www.youtube.com/watch?v=87DyyMV0kCY&t=1021s
Ideally, they should run in _different_ sandboxes.
The environment might corrode the harness (e.g. rogue npm/pip packet would manipulate agent harness config).
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.
This is not my main point though. Both are based on cgroups and cgroups are the wrong tool for the job.
The same is not applicable for any kind of sandboxing for two reasons:
1. The boundary is in the kernal’s own code, enforced by the thing you are trying to be protected from. -> Use a VM
2. The kernal is a gigantic attack surface -> Use gVisor
[1] https://docs.cloud.google.com/kubernetes-engine/docs/resourc...
Say I want to use pi inside a container. If I wrap pi within a bubblewrap or within nono, how is that less secure than using a vm?
Also, I think most people run containers inside VMs anyway and not directly on their hosts (on Mac and windows you have to use a vm anyway).
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.
Unless we're talking 0-day/CVE, running an unprivileged container is as trustable as a VM. The only difference is how strictly you want to hold the memory/CPU bar. Infact on linux, containers are more lightweight than VMs.
So yeah, not "vulnerable".
On Linux, you can run docker directly on the host, but you can also very easily setup a vm with incus and run docker from there.
docker run --runtime krun hello-world
Though, they need to remove the login requirement.
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.
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)
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.
I use it regularly to run Claude/Codex with permission checks disabled.
Maybe we should just ssh into separate development machines to ensure real and verifiable sandboxing? (as was totally standard before Docker became a thing)
Better sandboxing for AI agents is exactly the main reason for containers improvements on macOS and Windows, with a few talks at WWDC, and BUILD.
Not sure how much they would get from Linux users then.
On another topic, can't help but notice that "leading coding agents" somehow does not include Pi.
To work around that limitation I came up with this https://github.com/shaftoe/sbx-template-pi
So essentially you can get latest Pi/Node pulling from that image:
`sbx run -t ghcr.io/shaftoe/sbx-template-pi:latest shell`
Like others here I'm also saddened by the login requirement but at the moment this is the best UX I could find for running sandboxed agents, the "kit/mixin" concepts are neat and I make use of them too: https://github.com/shaftoe/sbx-template-pi#stacking-the-extr...
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.
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.
https://engine.build/lab/agent-sandboxes
The open source section specifically.
For those who do not trust
docker run --rm -it -v "$(pwd)":/work -w /work myaiimage /bin/bash
container run --rm -it -v "$(pwd)":/work -w /work myaiimage /bin/bash
Don't give it shell access, just predefined tools.
The other url is their marketing page.
Yes, Linux is supported.
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?
I'm using it as my main driver since months.
Support for running agent harnesses in unprivileged podman containers is on my feature list. :-)
I have a dedicated container for that. It can run its own Docker daemon and other system services if needed.
Apart from the Claude login token, it has no SSH keys or other credentials. I push everything I need to it from the local machine. And I pull the Claude generated outputs from it.
Of course, this kind of setup requires a stack which can run or at least be tested without any credentials.
What I don‘t have compared to sbx is an outbound firewall, but my VM does not have any personal/interesting data, only a vanilla Fedora installation and the project dir with open source code, so I do not care much about exfiltration.
Has egress and ingress filtering, egress can be bound to host/internet/subnet or even better to internal apps (which are each separate netns) meaning you can do your own firewall/vpn/whatever per sandbox. Plus you control what other components in the sandbox env the app can communicate with.
Really not built for day-to-day dev work though, more like automating your company/life / getting rid of SaaS (e.g. for technical Founders / Sales etc, not exactly useful for dev work)
It has network filtering + placeholders for secrets.
OSS, no logins needed
Documention at this moment in an early stage.
Overall, its a great project but for me was simpler just use Virtual Machine Manager (libvirt GUI).
I wish all luck to the maintainers, but probably DX-wise I will prefer to have more granular or predictable controls (eg micro cloud from Canonical).
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/
Their example implementation with pi uses a pi extension so that pi runs on the host but the read/write/bash/etc tools run in the guest. Doesn’t have to be that way though.
https://github.com/pjlsergeant/byre -- slightly different security model, but lazer-focused on developer experience; my daily driver and I love it not just because I wrote it. The TUI is great for configuring and setting up instant boxes just how you want
https://pleasedonotescape.com/ -- a list of every other agent jail I could find, filterable by open-source and whatever else you want
Basically, it's a plain QEMU/KVM VM on a stock Debian cloud image: device model stripped down to a virtio disk, a virtio NIC and a serial console, nested virt off, no passwordless sudo in the guest. It also ships a containment check that scans outward from inside the guest, so the network boundary is something you can verify.
Wrapping the whole environment rather than a single agent session puts supply chain attacks inside the boundary too. A poisoned npm or PyPI package, or a compromised editor extension, lands in the VM instead of on the host. That was the original reason I set this up; agents just made it more urgent.
There's no per-domain egress allowlist; the policy is "internet yes, private addresses no". Secret injection isn't built in either, though Infisical's agent-vault on the host as an egress proxy covers that part.
Wrote the whole setup up here, in case it's useful:
https://karamatli.com/posts/network-isolated-kvm-sandbox-ai-...