Introduction
Lately everyone in the AI agent scene is spinning up Docker Sandbox on a Mac mini for an isolated environment. I get the appeal. But the cheapest Mac mini config is ¥94,800 (~$630). And with memory prices through the roof, buying or building any new PC hurts right now. So I built one from spare parts. A B360M motherboard and an RTX 3060 Ti that had been collecting dust in my closet.
Now here's the thing. Did you know the Docker docs say this?
"MicroVM-based sandboxes require macOS or Windows (experimental). Linux users can use legacy container-based sandboxes with Docker Desktop 4.57."
In other words, microVM sandboxes aren't available on Linux. What you're left with is the legacy approach — namespaces and cgroups sharing the host kernel. One kernel vulnerability and you're all the way through to the host.
And here's another thing: what happens when that isolated environment breaks? You've been hand-crafting Docker images, placing secret keys with shell scripts, and calling it done because it works… but can you reproduce it? When a host OS update breaks everything, are you confident you can rebuild the same environment from scratch?
There's only one point I want to make in this article. Isolation isn't just about "locking things in." Don't you want to be able to rebuild the same cage, anytime, as many times as you need? Declaratively defined isolation, reproduced with a single command. That's what I did with NixOS and microvm.nix, and that's what this article is about.
Why Kernel Isolation + Declarative Reproducibility
Simon Willison has a concept he calls the "lethal trifecta": access to private data, processing untrusted content, and the ability to communicate externally. When all three come together, a system becomes fatally dangerous. AI agents structurally satisfy all three conditions. Doesn't that bother you?
So you think containers will keep things contained? Think again. runc CVE-2024-21626, CVSS 8.6 — a vulnerability combining process.cwd handling and file descriptor leaks that lets you escape the container. And in November 2025, three runc CVEs dropped simultaneously: CVE-2025-31133, CVE-2025-52565, CVE-2025-52881. The CNCF blog has a technical breakdown, and every one of them is a container breakout class issue. Containers share the host kernel by design, so a single kernel boundary vulnerability collapses the entire "containment." That's how it works.
Here's the funny part: Docker knows this. The fact that Docker Sandbox adopted microVMs for macOS and Windows is practically an admission that container isolation isn't enough. Yet Linux is left behind with legacy containers. Ironic, isn't it?
But kernel isolation alone doesn't make you safe. Isolation should be designed assuming it will be breached. The real question is how fast you can recover when it's compromised.
Michael Stapelberg, known as the creator of the i3 window manager, wrote about a microVM setup for AI agents in his February 2026 blog post. His philosophy is clear: VMs are disposable. If compromised, throw them away and rebuild. Make clean-state reconstruction the operational baseline.
But this doesn't work if reconstruction is manual. Break it, throw it away, grow the same thing back in 30 seconds. To do that, the entire environment — OS configuration, service definitions, secret placement — must be declaratively defined. Recovery by reading a runbook and typing commands can't be "disposable." That's why declarative reproducibility matters.
Locking It Down with microvm.nix + Nix
I'm not denying that Docker Sandbox is a valid option. It's perfectly practical on macOS. But if you want the same or better on Linux, microvm.nix offers four distinct advantages.
Kernel isolation. What Docker Sandbox does with microVMs on macOS — isolation via independent kernels — microvm.nix brings to Linux. Cloud Hypervisor spins up lightweight VMs on KVM, each running its own kernel separate from the host. Inter-VM communication is controlled by nftables: only SSH from the OpenClaw VM to the gogcli VM is permitted; everything else, including the reverse direction, is dropped. Lateral movement is structurally eliminated.
An observable cage. Locking things in isn't enough if you can't see what's happening inside. This setup captures audit logs at three layers. The nftables egress chain logs every outbound VM connection to syslog with a microvm-egress: prefix. Unbound logs every DNS query. auditd monitors reads, writes, and attribute changes to secrets files. Docker Sandbox only provides domain-level logs via its HTTP/HTTPS proxy, blocking all other protocols outright. With microvm.nix, you get L3/L4 conntrack logs across all protocols. You see not just what was blocked, but what was attempted.
Declarative reproducibility. This is the most important part. flake.nix contains everything: VM definitions, networking, secret injection, plugins, ML servers. flake.lock records cryptographic hashes of all inputs, so the same lockfile guarantees the same output. A single nixos-rebuild switch reconstructs the host, VMs, networking, and firewall rules all at once. git clone onto another machine, run the same command, and an identical isolation environment comes up. This is fundamentally different from Docker's ubuntu:latest changing contents day to day. Nix doesn't give you "we think it's reproducible" — it guarantees reproduction via cryptographic hashes. …Though it's not perfect. Some packages depend on upstream binaries, which falls outside Nix's guarantees. This has been discussed on NixOS Discourse, but I should be honest about it. Even so, incident response is just systemctl stop → nixos-rebuild switch. Since there's no mutable state, you never have to wonder "is this actually clean?"
Disposability. This only works because of declarative reproducibility. An environment you can't declaratively rebuild is an environment you can't throw away. The prerequisite for disposable VMs is being able to grow the same thing back anytime. I get it — it's hard to destroy an environment you've carefully nurtured. I can't even keep houseplants alive, though.
One last thing. I'm also running prompt injection defense. nyosegawa's openclaw-defender provides three-layer defense, and I just packaged it for NixOS. See nyosegawa's writeup for details.
Closing Thoughts
Docker Sandbox on a Mac — that's a reasonable choice. The microVM-based sandbox works properly on macOS, and for most people that's plenty. I'm not telling anyone to go install NixOS.
But if you're running AI agents on Linux with full permissions inside kernel-sharing containers… that's a little scary, isn't it?
If you want kernel isolation, microvm.nix isn't the only answer. Firecracker or QEMU will separate kernels just fine. But when combined with Nix's declarative model, "break it, throw it away, instantly regrow it" becomes an operational reality. There's a meaningful difference between a VM you recover by following a runbook and one you reconstruct with nixos-rebuild switch.
The configuration is on GitHub — feel free to use it as reference.
This is far from perfect, so if you have suggestions for improvement, reach out to me at @ryooo8244311427.
…Well, for a box built from spare parts, I'd say it turned out to be a reasonably decent cage.
References
- buduroiu — OpenClaw microVM — Security patterns for running OpenClaw in microvm.nix isolation
- nyosegawa — openclaw-defender — Three-layer prompt injection defense explained
- Original article (Japanese) — この記事の日本語原典
Top comments (0)