Docker Sandboxes is Docker's standalone sbx product for running coding agents in isolated microVMs. It does not mean putting an agent in a conventional Docker container. Each sandbox has its own Linux kernel, Docker daemon, filesystem and network. A conventional container instead shares the host kernel and relies on container controls around its processes.
This distinction identifies the primary runtime boundary, but it does not settle every security question. Workspace mounts, outbound connections, credentials, shared data and host-side integrations cross or sit outside that boundary. Each needs a separate assessment.
What “Docker Sandboxes” means today
Docker defines Docker Sandboxes as a product for running AI coding agents in isolated microVMs. The sbx CLI creates and manages those sandboxes, each with its own Docker daemon, filesystem and network. The agent can still build and run containers, but those containers live inside the sandbox's microVM. The microVM—not an inner container—is the product's primary isolation boundary.
“Container sandboxing” describes a broader class of controls applied to containerised workloads. Docker Engine uses namespaces to separate views of processes, mounts and networking, while cgroups account for and limit resources. Capabilities, user namespaces, mount configuration and access to the Docker daemon further shape what a container may reach. These configuration-dependent controls surround a workload that still uses the host kernel.
The terms name different things:
| Term | What it names | Primary isolation layer |
|---|---|---|
| Docker Sandboxes | Docker's standalone sbx product for coding agents | A microVM and its own guest kernel |
| Container sandboxing | A class of controls for containerised workloads | Host-kernel mechanisms and runtime configuration |
| gVisor | A sandboxed container runtime model | A userspace application kernel intercepting workload system calls |
| Kata Containers | A VM-backed container runtime | A lightweight VM and guest kernel |
The label “sandbox” alone does not reveal which component enforces isolation or what remains exposed. Start an assessment with the actual isolation layer, then examine the paths that cross it.
Which isolation layer forms each boundary
Each Docker Sandbox runs inside a lightweight microVM with its own Linux kernel. Docker's isolation documentation identifies the hypervisor boundary—not privilege separation inside the VM—as the isolation control. Code in the sandbox addresses the guest kernel; the microVM boundary separates that guest from the host.
A conventional Docker container has no guest kernel. Its processes use the host kernel through namespaces, cgroups and the restrictions configured around the container. This model can provide useful process and resource isolation, but the effective boundary depends on details such as mounts, capabilities, user namespaces and Docker-daemon access. “Runs in Docker” is not a complete description of the control set.
Two neighbouring models make the vocabulary more precise. gVisor inserts a userspace application kernel that intercepts workload system calls; it is neither a conventional hypervisor VM nor simply an ordinary container runtime path. Kata Containers places hardware virtualisation, a lightweight VM and a guest kernel beneath container workloads.
These mechanisms cannot be ranked by their names. gVisor's security guidance notes that VM security also depends on the host-kernel and userspace support code exposed by the architecture; virtualisation hardware alone does not determine whether a system is more or less secure. Ask a narrower question: which mechanism enforces the boundary in this architecture, and which interfaces can the workload still reach?
For a deeper explanation of guest kernels and hypervisor boundaries, see how microVMs work.
Which access paths sit outside the microVM boundary
A microVM defines where workload execution is isolated. On its own, it does not determine which files, destinations or credentials an agent can access. Docker Sandboxes exposes several separate control surfaces.
Workspace access. Direct Mount is the default. It gives the sandbox read-write access to the actual host working tree, allowing the agent to inspect and modify those files. Clone Mode prevents changes to the host checkout, but it does not prevent inspection of the cloned repository. A microVM boundary and host-workspace confidentiality are different properties.
Outbound traffic. Sandbox TCP traffic passes through a proxy on the host. Docker documents outbound TCP—including HTTP, HTTPS and SSH—as blocked unless an explicit rule allows the destination. This egress policy uses a separate enforcement mechanism; it is not an automatic consequence of the microVM.
Credentials. How a credential is delivered determines the boundary. With proxy-managed secrets, the real credential can remain on the host while the sandbox receives a sentinel value. OAuth passthrough sends the real token response into the sandbox and therefore reduces credential isolation. Docker also documents service secrets as global by default. “Runs in a microVM” does not mean that every secret remains outside the agent's environment.
Host-side integrations. Local stdio MCP servers run on the host, outside the sandbox VM. They can reach the host files, network resources and credentials granted to them. Although the agent runs inside a microVM, those server permissions still belong in the threat model.
Shared data. Shared Skills are experimental. For supported agents in newly created sandboxes from sbx 0.37.0 onward, Docker mounts a shared skills store read-write by default. One sandbox can modify material that another later loads, extending the trust boundary beyond a single sandbox.
Review these paths separately: What isolates execution? Which workspace is visible and writable? Where is egress enforced? Which credentials enter the sandbox? Which host processes act on the agent's behalf? Reducing all of them to “container or microVM?” hides controls with different enforcement points.
Which version and threat model this classification covers
This description was checked on 3 September 2026. Docker's stable release notes list sbx 0.39.0, released on 19 August 2026, as the newest stable version at that point. GitHub also lists v0.42.0-rc4, dated 2 September 2026, as a pre-release, so its changes should not be treated as the stable product state.
The product name once meant something else. Docker removed the earlier experimental Docker Desktop sandbox plugin in Docker Desktop 4.80.0 and directs users to the standalone sbx CLI instead. This history matters only because it resolves the name collision: Docker Sandboxes now refers to the standalone product described above.
Docker says its purpose-built, cross-platform VMM uses Hypervisor.framework on macOS, Windows Hypervisor Platform on Windows and KVM on Linux. That is a vendor architecture statement, not an independent security validation. A concrete assessment still requires the workload's threat model and a review of the exposed workspace, network, credential and host-integration paths.
This classification is limited to documented mechanisms at the stated versions. It does not establish that every microVM deployment has the same security properties, nor does it prove Docker's proprietary VMM secure. It identifies the documented isolation boundary so teams can evaluate the surrounding controls against their own workloads.
Where to go deeper
Use how microVMs work for the general mechanics behind guest kernels and hypervisor boundaries. The ainclave Agent Sandbox page describes ainclave's session, egress, credential and budget controls. For the enforcement layers, current limitations and roadmap, see microVM isolation and control layers.
Do not choose a control based on “sandbox”, “container” or “microVM” alone. Identify the documented runtime boundary, then review workspace access, egress, credentials, shared data and host integrations against the workload's threat model.