After Apple, Docker agrees that AI agents belong in their own machine

TL;DR — Two of the largest vendors in this space independently decided that a shared kernel is not a strong enough wall for code nobody reviewed. Both put the boundary on the developer’s machine. AppVM puts the same boundary on a server, for the workloads that are still running tomorrow.

At WWDC in June 2025, Apple open-sourced a container runtime for the Mac that gives every Linux container its own virtual machine, with its own kernel. It reached 1.0 in June this year. We wrote at the time that two teams had reached the same idea independently, and that when that happens it is usually a sign the idea is right.

Docker has now done it too. Docker Sandboxes runs each AI agent session inside its own microVM, on the native hypervisor of whichever operating system you are using. A Docker engineer put the point plainly in public: this is not containers, each session has its own kernel.

That is three teams, working separately, arriving at the same answer. The argument is no longer interesting. What is interesting is what all of them chose not to build.

Why AI agents forced the issue

Container isolation was always a judgement call about what you were running. For your own code, built from your own dependencies, sharing a kernel is a reasonable trade and the industry made it for a decade.

AI agents broke that reasoning, and they broke it quickly. An AI agent’s whole job is to carry out instructions that nobody reviewed in advance, using tools it chooses at the time. People run them unattended, and the popular flags for doing so are named things like “dangerously skip permissions” for good reason. The question stopped being whether your code might misbehave and became what happens when something you did not write decides to try.

Once that is the question, a boundary enforced by the same kernel the workload is talking to stops feeling like enough. Both Apple and Docker concluded that a machine wall, cheap enough now to use per workload, is the honest answer. So did we, and for the same reasons.

What Docker Sandboxes gives you

It is worth being accurate about a good product. Docker Sandboxes is aimed at a specific and real problem: you want to leave an AI agent running on your own machine and not think about it.

It boots a microVM per session, mounts only the project you point it at, and leaves the rest of your machine alone. It works on macOS, Windows and Linux. It adds two things that matter more than the isolation itself: an outbound firewall you configure, and credential handling where the secret stays outside the sandbox and is injected into requests on the way out, so the AI agent can use an API key without ever being able to read it. AI agents can even run their own containers inside.

If your problem is “this AI agent is about to run unattended on the laptop that has my photos on it”, that is the right tool, and AppVM is not competing for that job.

The half nobody built

Look at where all three of these run. Apple’s runtime is a Mac tool. Docker Sandboxes is a workstation tool. Both are very good at protecting the machine you are typing on.

But a lot of interesting work does not want to live on the machine you are typing on. An AI agent that runs for hours does not want to stop when you shut the lid. A workload you want to reach from your phone on the sofa cannot be a process on your desk. And once you have more than one of these, you are no longer sandboxing, you are running infrastructure, which is a different job with different tools.

That is the gap AppVM was built for. Same boundary, different home.

AppVM is the same idea, on a server

Give AppVM a container image and it boots that image as a real machine on a host you own. Its own kernel. Its own disk. Its own address on your network.

The differences from a workstation sandbox are all consequences of that one choice.

It is a service, not a session. A sandbox is disposable by design: you spin it up, the AI agent works, you throw it away. An AppVM keeps running. It has a restart policy, a health check derived from the image, and it comes back by itself after the host reboots. Nothing needs your laptop to be awake.

It has its own address. Not a forwarded port, not a tunnel out of your machine, but an address on your network like any other host. That is why you can open it from a phone, a tablet, or a spare Linux box, and why firewalling it works the way you already know. We wrote the whole path up in a walkthrough for DeepSeek Harness, which ends with opening an AI agent from a browser on a device that is not running it.

It shares a host with everything else. AppVMs run beside classic Linux virtual machines booted from standard cloud images, managed through one console and one API. The AI agent workload is not a special case living in its own tool.

The image is the deployment. You already know how to build one. Same base images, same multi-stage builds, same health check, same registries. What changes is what you get back, and we wrote down the handful of things worth knowing when the image becomes a machine’s filesystem.

Which one you actually want

These are not substitutes, and pretending otherwise would waste your time.

Reach for a workstation sandbox when the thing you are protecting is your own computer, the work is interactive, and you want it gone afterwards. That is a genuinely different need and it deserves a tool built for it.

Reach for AppVM when the workload should outlive the session: something that keeps running, that other people or other devices reach, that you want beside your other machines rather than inside a separate tool, and that you would rather administer than babysit.

Plenty of people will want both, and there is no conflict in that. One protects the machine you type on. The other runs the machines you do not.

The part that is settled

For a while, “give the workload its own machine” was a position you had to argue for. Containers were the default, the boundary was a kernel feature, and suggesting otherwise sounded like nostalgia for heavier infrastructure.

Three independent teams have now shipped the other answer, and the newest of them did it for AI agents specifically. The boundary question is closing. What is left is the question of where that boundary belongs, and for anything that has to keep running, be reachable, or sit next to the rest of your systems, the answer was never going to be a laptop.

Virtainer Free is available today on a single host. If you have a spare machine and an AI agent you would rather not run beside your own files, start there.