Docker Sandboxes – Disposable, isolated sandboxes for AI agents

I work at Docker. Lot of valid and useful feedback here that we're looking closely at.

One correction: this isn't containers. Each session is a microVM with its own kernel on the platform's native hypervisor: Hypervisor.framework, WHP, KVM. We wrote a new VMM (not Firecracker) to make it more effective across platforms.

Explained a bit more here about the architecture and why those choices were made: https://www.docker.com/blog/why-microvms-the-architecture-be...

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.

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?

> Each agent runs inside a dedicated microVM with your dev environment

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 -- bash

How about implementing proper permissions on the tool use or if you need more flexibility a dedicated model to analyse potential impact? (Like Claude Code's Autopilot but more configurable)?

I find solutions like this to be a like trying to patch a leaking boat on a lake with duct tape. It will help, but it's not a proper solution.

Also, often the tasks you want the AI to perform are in the outside world. Like "connect to my servers, and figure out X and Y".

The proper way is permission isolation. I run a small k8 cluster in the homelab and I have 3 types of pod/agent combinations for my AI agents. Read only, one that can change my gitops but it needs to create PRs that admin approves, and admin.

Likewise with code. I have a forgejo git instance where agents have ability to create feature branches and so on, but merging is gated.

Those things require "GH enterprise features".

In fact more and more things we do at home will require "enterprise features". Why? Because a person with AI is basically a small team, but some of team members behave like Chimps on crack... So security must be top notch.

What is the main benefit over doing something like:

    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

That runs the codex OCI in a qemu microvm. From what I can see, more fine grained network and filesystem access control as well as convenience?

Wow, I hope one day Linux will be able to support the exclusive MacOs/Windows technology of Docker Sandboxes.

(it's in the doc, but kinda strange to not see some instructions on the main page, probably distro related)

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.

Apple Container is an interesting work in progress: https://github.com/apple/container

I built "Locki": something similar but open-source! A bit different approach -- single VM with Incus containers -- focusing on speed of spinning up new sandboxes and integraton with git worktrees. The core grievance that motivated me was the lack of docker/kubernetes support in existing sandboxing tools, with Locki there's no chance of footguns like "two agents rebuild :latest tag at the same time". Give it a try: https://github.com/JanPokorny/locki

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.

https://github.com/iodize6399/ai-devcontainer/tree/main/.dev...

The other day I saw this: https://nono.sh/

Haven't tested it yet, but it seems to address the same issue as Docker Sandboxes, but in a different way.

To everyone sharing their favorite container-based sandboxing solution: Docker Sandbox does not use containers for isolation. It spawns the workload in a libkrun-based micro VM, which has vastly different security properties.

I recently wrote a blog post on using Tart for Macs for something similar that docker is doing here but with better persistence and control. My take is that the Tart approach is superior to this as it gives you a full dev machine with a single command line that allows agents to access files on host, install packages, maintain the vm and do whatever they want to do without compromising the host OS.

https://www.mrafayaleem.com/blog/sandboxing-claude-cli-with-...

Neither of the recent ones was actually a container escape though. The OpenAI one in July found a misconfig in the sandbox network, and Kimi K3 last week just walked out to grab answers off GitHub during an eval.

Both went through stuff the sandbox was set up to allow.

Requires login. Garbage.

If any AI company was doing serious engineering isolated containers would have been a prerequisite to using their tools.

Reminds me of sandboxy - https://github.com/apple/containerization/tree/main/examples...

Also if your thing doesn't work with `pi` out of the box, then low effort

I started building my own isolated and security-hardened docker image for OpenCode about half a year ago. Been using it daily.

https://github.com/pkhamre/opencode-docker

Since everyone is sharing their setup, here’s my approach, just to give people an idea of how others are doing it, however impractical it might look: I run a full Linux VM (with a GUI) on my Linux host. I connect via virt-viewer to run Claude Desktop, as I’m not a fan of using the terminal for this.

The VM sits on its own libvirt network in a dedicated firewall zone, and specific directories are shared via filesystem passthrough. To keep the agent from accessing anything related to Git, the actual gitdir is stored on a separate path outside the mount point.

I review the git diff manually and commit it from the host.

Does this support Linux yet? When I previously looked it did not (the reason being that they were already using VMs on Windows/macOS but not on Linux). Every time I see an announcement I think "great, they must've added Linux now then", but the linked pages always have Windows + macOS instructions but not Linux.

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’d rather use another open source solution that doesn’t require a signup, and less likely to get rugpulled.

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 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.

Open source alternative with podman support and local telemetry collection https://github.com/VibePod/vibepod-cli

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…

Operating systems ought to be providing us the utilities we need to safely sandbox processes (agent or otherwise), but they appear to not be interested in the job

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.

I am about to cry. I have been working on a project that actually made me feel I was bringing a new approach until I found this thread with an alarming number of similar tools.. I guess many of us used the same LLMs to help us building our "unique" solutions.

My approach was to remove completely docker and start using podman as rootless daemonless alternative. It also has a good solution to user-namespace mapping when I mount my repositories inside the sandbox.

I let the ai agent make changes but then I review them and push them from my host. As an alternative, you can create a ssh key pair on the host and load it into a dedicated ssh-agent, so you expose that agent socket to the agent container.

For API Tokens and similar credentials, I solved it by putting a credential broker between the podman agent container and the LLM provider. To avoid doing any internal firewalling in the container I run a proxy as a podman container that enforces the egress policy (only https on allowed domains); so no network capabilities are required, the proxy itself handles the filtering.

Because I had the idea of using the sandboxing framework to allow specific communication inside the network (for example for pentesting), it has also (apart from the proxy mode) a "routed"-mode implemented where a podman gateway is started; this does the network filtering without holding any kernel capabilities. nftables is configured using an ephemeral container with net_admin in the same network space (one-shot network initializer).

The framework orchestrates the different required networks and Podman containers.

I haven't tried the Docker solution yet, so I'll avoid comparing them.

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.

Models start going to extreme, damaging lengths to achieve ambiguous prompts[0]. Having good sandboxes is now a must IMO.

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

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.

Does anyone have a solution for iOS development?

I was all in on sandboxes and safehouse for my agents but the moment I got into iOS development it felt like my hand was forced to just run Claude / codex / pi directly on my machine because nothing else could do the dev loop.

It’s been a painful reality for me, I’m going against core pieces of how I feel I should be interacting with agent harnesses and yet, I need to get the work done so

I don't want this that bad. I want the agent to have open access to my system because it actually does important administrative things for me. It is THAT convenient and powerful.

Here's what I want: REALTIME OBSERVABILITY/POWERPOINT.

I don't want to just see what command it ran. I need graphics... what part of the file system it is touching, what network entities it is contacting. If it's running SQL I want the parsed query handed to me in a syntax highlighted and well formatted interface. Imagine that star trek computer presenting automated infographics while someone is doing a presentation, you know what I'm talking about? It's like a automated powerpoint as the agent does it's thing.

I need to understand my agent and what it typically does so I can dangerously wield it. I treat the agent like a gun in a live shooting scenario. That's how I want to use the LLM.

Sandboxes have their purpose. Just like how shooting ranges have their purposes. But I need to fire my gun in the real world and real world is a warzone.

Here is my solution which uses the Apple Virtualization Framework

https://apps.apple.com/app/aifcc-ai-first-computer/id6782364...

als has lots of agents + and typical dev packages (node tooling, python tooling, ....) preinstalled

I'm currently facing this issue. I've resorted to implementing my own execution environment albeit limited.

It goes like this: - bash script parser + interpreter (with hooks for things like file open, execute etc.,) - wasm executor for execution. - wasm implementations of common tools like coreutils, grep, sed etc., from the uutils project. - wasm implementation of python by a VMware backed project. - entirely virtualized filesystem using Go's io/fs.FS. (tmp dirs can be implemented using any backend)

Works like a charm for the limited usecase I have. There are definitely some drawbacks with threading and especially with preopens in wasm. But a cheap sandbox for simple file explorations and minimal computations.

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)

I do not see any value proposition in this - if I need a sandbox, I make one with Dockerfile, Bubblewrap or virtualization. What I am missing? An enforced required login is a net negative value - it means rug pulls in the future.

On Linux, you can skip Docker and use bubblewrap. Some inspiration: https://blog.gpkb.org/posts/ai-agent-sandbox/

I tried it and it worked great at first but I had multiple issues with it, the disk space usage was growing significantly, I need to login multiple times for each sandbox, it's closed source and not possible to customize to my need.

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

I am not sure I understand, how is this different from a devcontainer or other similar techniques?

On another topic, can't help but notice that "leading coding agents" somehow does not include Pi.