Here is a fair question for your platform team. If an AI coding agent with a shell, your source tree and a token decides to run something it should not, what stops it? If the answer is that it runs in a container, you are trusting a shared kernel to hold back a process that writes and executes its own code all day.
Vendors have reached the same conclusion. In October, Chainguard launched Workspaces and Checks in beta to run coding agents and their CI steps in hardened microVMs, and the Harbor eval framework added Docker Sandboxes so each agent eval runs in its own microVM. For teams letting agents run code, microVM isolation for AI coding agents, with short-lived credentials and default-deny networking, is becoming the baseline.
Why are containers not enough for agents?
Containers were built to package and ship software you wrote and reviewed. Namespaces and cgroups keep workloads tidy, but every container on a host shares one kernel. One kernel bug or one careless mount is all it takes.
That trade-off was fine when the code inside was yours. An agent is different. It writes code, installs packages, runs tests, reads the errors and tries again, thousands of times. Sooner or later something it pulls in will be hostile. When Docker launched Cloud Sandboxes on 24 September, its president Mark Cavage said containers were not designed for the level of isolation agents need, according to Forkast. When the company that made containers popular says that, it is worth listening.
What did Chainguard launch?
Chainguard announced both products at its Assemble London event, InfoQ reported on 16 October. Workspaces gives each developer or agent a dedicated remote microVM. A chainctl develop command syncs your local working tree, including uncommitted changes, into it. Sessions are snapshotted when you detach and resume with files, processes and shell state intact.
The security details are the interesting part. A host-side proxy adds short-lived credentials to approved outbound requests, so long-lived secrets never sit inside the guest. Optional egress rules block and log connections to endpoints you have not approved. Commands, code changes and network calls go into what Chainguard calls a tamper-proof log. Agent support starts with Claude, with others planned.
Checks runs CI steps in separate warm microVMs built from Chainguard packages, with dependencies prepared from the lockfile. A passing run produces a signed attestation tied to the environment, the result and the commit, so a merge gate can verify the evidence instead of running the tests again. Both products are offered as 30-day beta trials, and Workspaces is priced on compute used.
InfoQ noted that Chainguard has published no performance comparison with established CI services and has not explained how customers can verify the log's tamper resistance. Both are fair questions to raise in any trial.
Why does isolation matter for evals too?
Agent evaluation is a quieter version of the same problem. An eval runs agent-written code over and over, and agents are known to game their scores, for example by editing the tests or overwriting the file that records the result.
On 14 October Docker announced that Harbor, an open-source eval framework, can now run every task in Docker Sandboxes, either locally or in Docker's cloud. Each task gets a microVM instead of a shared container. Network policy can allow downloads during setup and then cut internet access while the agent works, so every agent is tested under the same conditions. Docker said it tested 64 concurrent tasks in the cloud.
What do Docker Sandboxes actually isolate?
According to Docker's security documentation, each sandbox is a microVM with its own kernel and its own Docker Engine, with no path to the host daemon. The agent gets sudo inside the VM and nothing outside it except what you share. Outbound TCP goes through a host proxy with a deny-by-default policy, UDP and ICMP are blocked, and sandboxes cannot talk to each other. The proxy injects credentials into requests, so raw secrets do not enter the VM. Forkast reported that Docker built its own virtual machine monitor rather than using Firecracker.
Two caveats from the same docs. The default allowlist includes broad wildcards such as *.googleapis.com, so review it with sbx policy ls. And in direct mode your workspace is mounted read-write, which means Git hooks and package.json scripts the agent edits will run on your machine later.
What should you do now?
Notice the pattern across all three. A VM boundary per agent session, credentials injected at the edge and never stored inside, outbound traffic denied unless allowed, and a record of what happened. InfoQ's own guidance says much the same, and services such as E2B and Vercel's Hive already run agent work in Firecracker microVMs.
If your agents run today in a shared CI runner, or in a container on a developer laptop with a long-lived token mounted, that is the first thing to fix. Buy it or build it, but stop calling a container a sandbox.
Quick answers
Why not run AI coding agents in containers?
Containers share the host kernel and were built for code you trust. Agents write and run untrusted code all day, so a microVM with its own kernel gives a much stronger boundary.
What is Chainguard Workspaces?
A beta service announced in October 2026 that gives each developer or AI agent a dedicated remote microVM, with short-lived credentials added by a host proxy, optional egress rules and a recorded activity log.
What changed for Harbor agent evals?
Since 14 October, the open-source Harbor framework can run each eval task in a Docker Sandboxes microVM, locally or in Docker's cloud, with network policy controlling access during the run.
