--- title: "Docker Puts AI Coding Agents Inside Disposable Virtual Machines" description: "Docker Sandboxes runs AI coding agents in disposable microVMs so they can work unsupervised without touching the host machine. Why the design is contested." dek: "AI coding assistants now write files, install software and run commands on their own. Docker's answer is to give each one a throwaway machine of its own to wreck." published_at: "2026-08-13T17:38:58.321Z" updated_at: "2026-08-13T17:38:58.321Z" tags: - "AI" - "Security" - "Infrastructure" source_url: "https://www.docker.com/products/docker-sandboxes/" source_domain: "docker.com" canonical: "https://hex37.com/docker-puts-ai-coding-agents-inside-disposable-virtual-machines" --- An AI coding agent is a program that has been handed a goal and a keyboard. Told to fix a failing build, it decides for itself which files to open, rewrites them, installs whatever libraries it thinks the job needs, and runs commands to find out whether any of it worked. It is not drafting suggestions for a person to approve later. It is acting, in real time, on a real computer. That is where the awkward question starts. Every team now putting these tools to work has to decide how much of the machine the agent is allowed to act on — and there is no obvious place to draw the line. ## What an agent inherits when you launch it Software that runs on your computer runs with your permissions. An agent started from a developer's laptop can, in principle, do anything that developer could do: rewrite configuration files far outside the project it was asked about, delete directories, pull packages off the internet, reach whatever internal services the laptop can reach. None of this requires the agent to be malicious or compromised. A single confidently wrong command is enough, and agents produce commands at a rate no one is reading line by line. The industry's first answer was the permission prompt. Before anything consequential, the agent stops and asks. It is a reasonable safeguard and it works, in the sense that a human being is now in the loop for every risky step. What it costs is the thing that made agents interesting in the first place. Their strongest results come from being left alone to grind through a long task — running a test suite, watching it fail, adjusting, running it again — and every approval gate turns that unattended run back into a person watching a terminal. So the choice appears to be a straight trade. Lock the agent down and accept that it will be slow and needy. Or turn the guardrails off, let it move, and accept that you have given an unsupervised program the run of a working machine. Both options charge you something real, which is why the question of whether teams can deploy agents at all keeps coming back to whether it can be done safely rather than whether it would be useful. ## Containing the damage instead of vetting each step [Docker Sandboxes](https://www.docker.com/products/docker-sandboxes/), released as a command-line tool for macOS, Windows and Linux, takes the question apart from a different end. Rather than deciding which of the agent's actions are acceptable, it changes what the agent's actions can reach. Each agent session is given its own small [virtual machine](https://en.wikipedia.org/wiki/Virtual_machine) — a simulated computer running on top of the real one, with its own operating system kernel and a hard boundary between the two. Inside it sits a working development environment, and the only piece of the host filesystem mounted into it is the project folder the agent was asked to work on. Everything the agent does — installing packages, editing configuration, starting services, even launching its own containers — happens inside that boundary. The host is not touched. When the work is finished, the whole environment is thrown away in a single command. This is why the tool ships with permissive mode switched on by default. Coding assistants generally have a flag that disables their approval prompts entirely, named in a way that makes the risk plain — Claude Code calls it `--dangerously-skip-permissions`, and developers call using it YOLO mode. The flag is dangerous because of what a mistake could touch. Take away everything it could touch and the same flag becomes ordinary. There is no manual review, no prompt, no one supervising, because the consequences of a bad decision are confined to a machine that exists only for this task. That is the move worth noticing. The safety is not coming from correctly predicting which commands are fine. It is coming from the geometry of where the agent is allowed to stand. Once the boundary is drawn in infrastructure rather than in policy, speed and safety stop competing, because you are no longer buying one with the other. ## Why it is not a container Docker's name is attached to [containers](https://en.wikipedia.org/wiki/Containerization) — lightweight packages that bundle an application with its dependencies — and much of the initial reaction assumed this was more of the same. Engineers working on the product were quick to correct that. Containers share the host's operating system kernel, which means the wall between a container and the machine underneath it is thinner than most people assume. Each sandbox session here is a microVM: a stripped-down virtual machine with its own kernel, running on the hypervisor already built into the platform — Apple's on macOS, Microsoft's on Windows, the Linux kernel's own on Linux. The team wrote a new component to manage those machines rather than adopt an existing one, specifically so the behaviour would be consistent across all three. The practical consequence is that the security properties are those of virtualisation, not of process isolation, and that an agent inside a sandbox can run containers of its own without the nesting becoming a problem. Developers who have adopted it report that the appeal is largely that it works without configuration. At least one has made it a daily driver despite finding the required sign-in irritating, on the grounds that nothing open-source currently matches it out of the box. ## The argument for leashes rather than walls The design has informed critics, and their objection is not that the isolation fails. It is that isolation is the wrong layer to solve the problem at. Their preferred approach is to control what the agent is permitted to do — fine-grained permissions on each tool it can call, or a separate model that assesses the likely impact of an action before it runs. Containment, on this view, is duct tape on a leaking boat: it helps, and it is not a fix. The sharper end of that argument is about usefulness. Many of the jobs people actually want agents for point outward — connect to these servers, query that system, find out why the deployment is failing. An agent sealed into a box with a copy of one folder cannot do those things, and the safety guarantee holds partly because of what has been taken away. Whether infrastructure-level isolation genuinely covers the work organisations want done, or whether it covers only the subset that happens to fit inside a disposable machine, is the question the next year of using these tools will answer.