Docker Sandboxes: Run AI agents in disposable microVMs

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?

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.

> 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

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

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)

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?

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.

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.

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