Docker Sandboxes isolate the host, not every consequence

The microVM is the beginning of the security design

Docker Sandboxes answers a question that ordinary development containers never had to answer: how do you give an autonomous coding agent root access, package installation, a shell, and Docker without giving it the developer's machine? Docker's answer is a dedicated microVM with its own kernel and Docker daemon, plus host-side brokers for files, network traffic, credentials, and MCP tools.

The answer drew unusual developer attention on August 10. The Docker product page reached 629 points and 350 comments on Hacker News. That discussion mixed enthusiasm about mainstream agent isolation with objections about login requirements, proprietary dependence, missing enforcement, and confusion over how a microVM differs from a dev container. Those objections are useful because they identify where “sandbox” can become a label instead of a threat model.

Docker's current product page says each agent receives a dedicated microVM and can install packages, edit configuration, and run containers while the host remains protected. The security documentation is more precise. The microVM is the primary trust boundary, but selected host resources cross it. In direct mode the project workspace is mounted read-write. Credentials are injected by a host proxy. Network requests pass through a host policy layer. Shared skills can be mounted read-write across sandboxes. MCP servers run outside the VM and expose methods through a gateway.

Those are not hidden defects; they are the integration points that make the sandbox useful. They are also where a team must decide which data, tools, and consequences belong inside the same trust zone. The practical thesis is simple: use the microVM to remove ambient host authority, then treat every brokered channel as a separate capability with its own policy and evidence.

How Docker Sandboxes divides the machine

The separate kernel matters because an ordinary container shares the host kernel. More importantly for coding agents, Docker Sandboxes does not mount the host Docker socket. An agent can build images and start services against its private daemon without gaining control of host containers or using the socket as a path to host root. That is a materially different boundary from -v /var/run/docker.sock:/var/run/docker.sock.

State persists until the sandbox is removed. Installed packages, agent history, images, layers, and workspace changes survive a stop and restart. Persistence is convenient for long tasks and expensive setup, but it means “the process ended” is not cleanup. A reused sandbox can carry a compromised dependency, poisoned configuration, modified shell profile, stale credential association, or misleading build cache into the next task.

Docker v0.38.0, released August 6, adds first-class MCP management, version 2 kit specifications, organization-governed MCP calls, more explicit network denies, and several operational and security fixes. It also fixes a copy-out destination escape identified as CVE-2026-17106. That release is a reminder that the sandbox runtime itself is a security-sensitive product with an upgrade and regression-testing lifecycle.

Four documented exceptions deserve explicit decisions

Direct workspaces are not isolated workspaces

Direct mode mounts the developer's project path read-write. Agent edits appear on the host immediately, including changes to package scripts, task definitions, CI configuration, AI instructions, and build files that execute later. The microVM blocks arbitrary host filesystem access, but it does not make the mounted tree harmless. A later developer command can execute content written by the agent.

Clone mode is the safer default for untrusted repositories and unattended work. It mounts the source repository read-only and gives the sandbox a private clone. Review and export the resulting commit or patch instead of sharing a live checkout. This also makes the trust handoff visible: the sandbox produces an artifact; the host chooses whether to accept it.

Shared skills merge trust zones

Supported agents can mount a host-side skills store read-write across sandboxes. That creates a deliberate cross-sandbox state channel. If a low-trust sandbox can modify a script or instruction later imported by a high-trust sandbox, isolation at the VM boundary does not prevent persistence. Use --no-share-skills unless the sandboxes have the same owner, provenance, and authority. Distribute approved skills from a signed, read-only source rather than accepting in-place edits from agents.

MCP servers can execute outside the VM

Local stdio MCP servers run on the host, not inside the sandbox. A registered server may read local files, access credentials, or call systems that the sandbox itself cannot reach. Docker's MCP gateway and Cedar policies can govern registration, tool calls, resource reads, prompt retrieval, and gateway meta-tools. That policy only works when teams define it. “The agent is in a microVM” does not constrain a host tool with broad authority.

Allowed network destinations remain write surfaces

The network proxy prevents raw outbound protocols and can deny unknown hosts. An allowed API can still store public content, send email, open an issue, upload an artifact, or write to an attacker-controlled tenant. Scope destinations by account and method where the integration supports it. Prefer task-specific tokens and read-only endpoints. Do not treat a hostname allowlist as a data-loss prevention policy.

Start with clone mode and a disposable task boundary

Install commands change by platform; verify the current Docker documentation before automating them. A minimal macOS pilot currently looks like this:

brew trust docker/tap
brew install docker/tap/sbx

# Inspect the installed runtime and policy before use.
sbx version
sbx policy ls

# Create an isolated private clone for an unattended coding task.
sbx run --clone --no-share-skills codex

# After the task, inspect state and remove the sandbox explicitly.
sbx inspect <sandbox-name>
sbx rm <sandbox-name>

Do not copy a “YOLO mode” command into CI and call the result secure. Define the source commit, task, allowed destinations, agent, kit version, credential set, time limit, storage limit, and output contract. Record the sandbox runtime version because security and behavior can change between releases.

task:
  id: fix-parser-1842
  source_commit: 91d6c4f
  workspace_mode: clone
  shared_skills: false
  max_runtime_minutes: 45
  network:
    default: deny
    allow:
      - api.github.com
      - registry.npmjs.org
  credentials:
    github: branch-write-only
    production: none
  output:
    require: [commit_digest, complete_diff, tests, dependency_delta]
    deny: [merge, release, deploy]

The file is illustrative rather than a Docker kit schema. Its purpose is to make the task contract reviewable. Translate the same fields into current sbx kit, policy, identity, and orchestration settings. Reject the task if the runtime cannot enforce a required boundary.

Use policy to keep integration points narrower than the VM

Docker governance combines local, kit-defined, and organization policy. Under organization governance, only organization allow rules can grant access. Denies from organization, local, and kit sources still restrict it. Deny wins, and access without a matching allow is blocked. This prevents a developer kit from silently expanding an organization boundary.

Before a run, enumerate effective rules and test the destinations the task expects:

sbx policy ls
sbx policy inspect <policy-name>
sbx policy check network api.github.com:443
sbx policy check network example-upload.invalid:443

# Record an additional task-specific deny at creation time.
sbx run --clone --no-share-skills \
  --deny-network '*.example-upload.invalid' codex

MCP policy uses Cedar rather than the network and filesystem rule format. A useful pattern is to allow a narrow read method and forbid mutation methods even when another policy is broad:

permit (
  principal,
  action == MCP::Action::"CallTool",
  resource == MCP::Tool::"github.search_issues"
);

forbid (
  principal,
  action == MCP::Action::"CallTool",
  resource
) when {
  resource.name like "*delete*" ||
  resource.name like "*merge*" ||
  resource.name like "*deploy*"
};

Validate policy against the exact installed version. The public issue tracker shows active reports about kit schema validation, network-policy consistency, daemon behavior, credential handling, and v0.38.0 regressions. A policy that parses is not necessarily a policy that produces the intended runtime decision. Keep positive and negative integration tests in the rollout gate.

Choose the lightest boundary that can contain the task

MicroVM overhead buys a separate kernel and private daemon. It is justified when an agent installs arbitrary packages, builds images, runs services, or processes attacker-influenced repositories. A simple read-only formatter may need only a restricted container or process. Matching the boundary to the task reduces cost and removes unnecessary channels.

Failure modes that survive the microVM

The Hacker News discussion repeatedly returned to enforcement and login. One commenter summarized the enforcement gap: limiting what an agent can do inside a sandbox is different from ensuring that the agent must run there. Treat adoption controls as part of the architecture. A secure sandbox installed beside an unrestricted host command is an optional safety feature, not a platform boundary.

Roll out Docker Sandboxes as a controlled runtime

Pilot on one repository for two weeks. Seed tests that attempt to read outside the workspace, alter shared skills, call an unregistered MCP method, contact a denied domain, modify a protected workflow, copy out through a traversal path, and persist state across tasks. The pilot passes when the enforcement layer blocks the action or the review packet makes the effect unmistakable.

Frequently asked questions

Are Docker Sandboxes just containers with a new name?

No. Each sandbox uses a separate kernel in a microVM and a private Docker daemon. A normal container shares the host kernel, and a container with the host Docker socket can control host workloads.

Why does the agent have passwordless sudo inside the sandbox?

The design treats the VM interior as disposable and gives the agent enough authority to reproduce a real development environment. Safety depends on the VM boundary and the resources deliberately brokered across it. Root inside the sandbox makes strict control of mounts, network, credentials, kits, and MCP more important.

Does stopping a sandbox clean it?

No. Packages, images, state, history, and workspace changes persist until removal. Use sbx rm when the task or trust zone ends, and verify what happened to exported branches, remotes, artifacts, and logs.

Is direct mode ever appropriate?

Yes, for trusted interactive work where the developer wants immediate edits in the current tree and will review them. Clone mode is safer for unattended jobs, public issues, unknown repositories, or any task where later host execution could turn a file write into a larger effect.

Can Docker Sandboxes replace human review?

No. It can reduce the maximum consequence of a mistaken or manipulated agent. A human or independently controlled release system still needs to review the exact diff, evidence, dependencies, and destination before merge or deployment.