Coding agent sandbox Docker vs microVM vs devcontainer

The short answer: use devcontainers to standardize the agent workspace, hardened Docker for low-risk supervised work, and microVM-style isolation when agents are unattended, running arbitrary repo code, or operating in a shared fleet. The runtime label matters less than the boundary it creates: what the agent can read, write, execute, and reach.

That is the real decision behind coding agent sandbox Docker vs microVM vs devcontainer. A coding agent does not only run code. It inherits files, credentials, mounts, network access, local services, package tokens, Git identity, cloud CLIs, kubeconfigs, and sometimes a Docker socket. OpenAI's sandbox guidance frames this plainly: agent-generated code can access what its environment exposes, including files, credentials, and network. Docker's sandbox documentation makes the same point from another angle by separating microVM isolation, private Docker engines, deny-by-default egress, and host-side credential proxying.

For platform and security leaders, the useful question is not "Is Docker secure?" or "Are microVMs required?" The useful question is: what failure are you trying to contain?

Decision Frame

You are choosing between three different control planes:

The pattern is straightforward. Devcontainers solve reproducibility first. Docker containers add a meaningful layer of host hygiene when hardened. MicroVMs add a stronger trust boundary by placing the agent behind a separate kernel.

Related reading: securing coding agents in CI/CD.

Why Devcontainers Are Not Enough By Themselves

A devcontainer is a development environment specification. It can define tools, users, mounts, features, and editor behavior. That is valuable when you want every agent run to see the same compiler, package manager, browser dependencies, and test tools.

But a devcontainer is not inherently a strong sandbox. The Dev Containers specification allows settings such as privileged, capAdd, securityOpt, mounts, remoteUser, and containerUser. Those knobs are useful for development. They are also ways to blur the boundary if the agent is running untrusted code.

Trail of Bits' Claude Code devcontainer project describes its posture as containment rather than a strong security boundary. That distinction matters. If the repo is mounted read-write, if .git state is shared with the host, or if the agent can modify files that later execute outside the container, delayed impact is still possible.

Use devcontainers when your primary goal is reproducibility. Do not treat them as the full answer for malicious repositories, unattended approval modes, or agent fleets with access to valuable credentials.

Where Docker Fits

Ordinary Docker is the familiar middle tier. It can reduce host exposure compared with running an agent directly in a developer shell, especially if you drop unneeded Linux capabilities, apply seccomp and AppArmor or SELinux profiles, use user namespaces, run rootless where practical, and avoid privileged containers, as covered in Docker's Engine security and rootless mode documentation.

That makes Docker useful for supervised work where the repo is trusted, credentials are limited, network access is constrained, and the agent's changes still pass through human review. It is also a reasonable stepping stone for teams that need consistency before they can operate a microVM pool.

The dangerous pattern is treating "inside Docker" as a complete answer. The host Docker socket is the clearest example. Docker's own isolation material warns that mounting the host Docker socket gives broad control over the host Docker environment. For coding agents, that can collapse the boundary you thought you had.

The same issue appears in quieter forms:

• Writable host source mounts that let the agent alter files outside its runtime.
• Long-lived home directories that accumulate tokens, shell history, cache state, and credentials.
• Cloud CLIs, kubeconfigs, SSH keys, npm tokens, and package registry credentials available inside the container.
• Unrestricted outbound network that turns any readable secret into an exfiltration risk.
• Persistent self-hosted runners where one task can leave state for the next task.

Docker can be a sound control for low-risk work. It is a poor default for adversarial, multi-tenant, long-running, or auto-approved agent execution unless it is wrapped with stronger controls.

When MicroVMs Become The Safer Default

MicroVMs change the default trust boundary. Firecracker is designed to provide VM-style workload isolation with container-like efficiency. Kata Containers run containers or Kubernetes pods inside lightweight VMs. Docker AI Sandboxes describe dedicated microVMs with hypervisor isolation, a separate kernel per sandbox, a private Docker Engine inside the VM, proxied egress, workspace mode choices, and host-side credential proxying.

This is the right direction when the agent can run arbitrary repo code, install dependencies, execute tests from unknown projects, use sudo inside the sandbox, or operate without line-by-line human approval. It is also the safer default for shared fleets, customer-submitted code, self-hosted runners with persistence risk, and developer workstations with valuable local identity.

MicroVMs do not remove the need for good policy. They reduce host blast radius. They do not fix overbroad GitHub tokens, package publish credentials, writeable host mounts, allowed exfiltration destinations, or an approval policy that lets the agent make destructive changes without review.

The trade-off is operational. You now own image lifecycle, VM startup behavior, nested virtualization constraints, network policy, storage mapping, logs, snapshots, cleanup, and debugging paths. That cost is justified when the work is high-risk enough that shared-kernel isolation is not the boundary you want to bet on.

Do Not Ignore gVisor

gVisor sits between ordinary containers and full VM isolation. It intercepts syscalls and implements much of the kernel interface in userspace, reducing direct exposure to the host kernel while keeping a container-like operating model.

For coding agents, this can be attractive where microVM operations are too heavy but plain Docker feels too thin. The caveat is practical testing. Package installs, browser tests, Docker Compose workflows, monorepos, language toolchains, and tests that expect privileged kernel features can expose compatibility or I/O performance problems. Treat gVisor as a candidate runtime, not a checkbox.

The Real Perimeter Is Often Credentials

Practitioner discussions keep returning to the same point: development machines are dense with real work identity. SSH keys, repo credentials, npm tokens, browser sessions, cloud credentials, and internal network reachability are often more valuable than the source files themselves.

That is why credential injection deserves the same attention as kernel isolation. Passing secrets as environment variables or files gives the agent direct access. A stronger pattern is a broker or proxy that keeps secrets outside the executor and attaches them only to approved outbound requests. Docker's sandbox model points in this direction with host-side credential proxying.

Network policy has the same shape. Disabling network access is safest, but most real coding tasks need package registries, Git hosting, documentation, test services, issue trackers, and sometimes preview environments. Default-deny egress, domain allowlists, registry mirrors, DNS controls, and proxy logs become part of the sandbox. Without them, isolation only limits local damage. It does not stop data from leaving.

Threat Model Matrix

Workspace Mode Matters

One subtle but important choice is how the agent sees source code. Docker's sandbox documentation distinguishes direct mode, where the host working tree is mounted read-write, from clone mode, where the repo is mounted read-only and the agent works in a private clone.

For agent workloads, clone-style workflows are safer. They make it easier to inspect a diff, discard state, and avoid silent mutation of host files. Direct mounts are convenient, but convenience is exactly where sandbox boundaries tend to erode.

The same rule applies to local stdio MCP servers and other host-side tools. Docker notes that local stdio MCP servers can run outside the sandbox VM with host permissions. If the agent can invoke a host-permissioned helper, that helper becomes part of the trust boundary.

Related reading: MCP tool allowlists and drift detection.

Build Or Buy Checklist

Before standardizing on a runtime, evaluate the full execution envelope:

• Isolation: Is the boundary shared-kernel, syscall-intercepted, or guest-kernel based?
• Workspace: Does the agent mutate the host working tree directly, or work in a disposable clone?
• Docker access: Is the host Docker socket mounted? If yes, assume the host boundary is weak.
• Secrets: Are credentials exposed as files and environment variables, or brokered outside the executor?
• Network: Is egress default-deny with explicit destinations, registry mirrors, DNS controls, and logging?
• State: Is the runtime destroyed after each task, or can caches and home directories persist?
• Observability: Can you inspect file changes, commands, network requests, approval events, and cleanup results?
• Human review: Which actions require approval because they cross a boundary, publish code, rotate credentials, or change infrastructure?

Bottom Line

If your agents are supervised, working in trusted repos, and operating with limited credentials, a devcontainer or hardened Docker setup can be a practical baseline. If your agents are unattended, touching arbitrary code, running in persistent infrastructure, or serving multiple tenants, start from microVM-style isolation and work backward only where the risk is clearly lower.

The runtime is only one layer. The effective sandbox is the combination of kernel boundary, mounts, secrets, egress, state lifetime, tool permissions, and approval policy. Get those wrong, and a microVM can still leak through allowed channels. Get them right, and the coding agent becomes far easier to trust in production engineering workflows.