Docker Sandboxes: more room for agents.

A coding agent fixing a failing build may need a compiler, a different runtime, a browser for tests and a temporary database. Each missing tool interrupts the work if installing it means changing your main development machine.

Docker Sandboxes gives that work its own environment. The useful idea is broad freedom inside a deliberately limited boundary: let the agent prepare its tools and test its changes, while controlling which files, services and credentials it can reach.

As of 18 October 2026: this comparison covers local Docker Sandboxes. The current installation uses the standalone sbx CLI; Docker Desktop and Docker Engine are not prerequisites. Supported platforms have specific hardware and virtualization requirements, so check the installation guide first.

Why the agent can work more freely

Each local sandbox has a microVM, its own Linux kernel and a private Docker Engine. The agent can use sudo, install packages and start containers inside that environment. A container escape within that VM would still face a VM boundary protecting host resources that have not been shared. That is an additional isolation layer, not an absolute guarantee against vulnerabilities. Docker’s isolation architecture

Docker’s built-in agent integrations use their full-autonomy modes, reducing repeated command approvals. The enclosing sandbox supplies the boundary. This is why a more capable agent can be useful here: it can investigate, install a missing dependency, rerun a test and continue. Agent tutorial

The distinction matters: permission to install software inside the sandbox is not permission to administer the developer’s machine. Prompt instructions still describe the task; externally enforced controls limit the consequences when the agent misunderstands it.

Compared with hardened Podman and Docker

A serious container setup can already restrict an agent substantially. Rootless execution, a non-root process, dropped capabilities, no-new-privileges, a read-only root filesystem, narrow writable mounts and resource limits are useful building blocks. Podman exposes these controls in its run options. Docker also supports rootless mode; running a non-root process alone does not make a rootful Docker daemon rootless.

Keep syscall filtering and the platform’s applicable AppArmor or SELinux confinement enabled. Docker’s seccomp documentation explains how its default profile restricts system calls. Outbound access also needs an explicit policy: an ordinary container network is not a destination allowlist.

The table compares a conventional hardened container with Docker’s sandbox security model. The best-fit row is our assessment: a fixed linting or test job often needs less freedom than an agent investigating an unfamiliar project.

A fair comparison must also include virtualization. Podman Machine uses a VM on macOS and Windows. Docker Desktop’s Linux containers also run inside a Linux VM; its optional Enhanced Container Isolation adds user namespaces and other protections. Neither arrangement automatically creates a separate kernel for every agent container.

You can also put a hardened Podman or Docker setup inside a dedicated VM per task. That can provide a similar kind of outer boundary. Docker Sandboxes packages the agent environment and its controls together; it is not the only way to construct them. A VM also brings its own memory, storage and maintenance costs.

Downloading software without opening everything

Imagine asking an agent to repair a web app’s integration tests. It could install a browser and its Linux dependencies, build the app, start a disposable database and reproduce the failure. The package sources and download hosts must be allowed, and the sandbox needs enough resources for the job.

With the Balanced network preset, common development destinations are allowed and unmatched requests are blocked pending approval. Open allows all outbound TCP traffic. Locked Down removes the baseline allowances, but agent kits can still add rules. Inspect the effective policy instead of relying on the preset’s name. Local network policy

Allowing a registry does not establish that every package in it is trustworthy. Nor does allowing a code-hosting domain distinguish every legitimate request from data leaving through that domain. Narrow destinations and, where appropriate, HTTP methods and paths; leave unrelated services unavailable. Network access controls

The developer’s benefit is practical: an agent can assemble a temporary test environment without accumulating those tools on the host. Record the dependencies that become part of the project in its build configuration so colleagues and CI can reproduce the result.

Where Docker Desktop helps

For developers already using Docker Desktop, it remains useful for the application stack they run and inspect themselves. Its Containers view groups Compose applications and exposes logs, configuration and resource usage. A useful workflow is to let the agent experiment in a sandbox, review the resulting Dockerfile or Compose changes, then run the accepted version in the usual Desktop environment.

The sandbox’s private engine is separate from Desktop’s main engine. Do not assume that its containers appear in Desktop’s ordinary container list. That separation lets the agent build and discard its own test services without taking control of your existing ones. Sandbox architecture

Giving a container the host’s Docker socket undermines this distinction: control of that daemon can grant extensive access to its host. Rootless mode reduces the privilege involved, but still exposes resources available to that daemon’s user. Docker daemon security

The boundaries that still need attention

Proxy-managed credentials can stay on the host while the proxy authenticates allowed requests. That prevents reading the raw secret, but the agent can still exercise the access it grants. SSH agent forwarding likewise allows signing or authentication without copying the private key. Review those permissions and disable unnecessary forwarding. Credential handling

Connected tools also matter. A local MCP server runs on the host, outside the sandbox VM; its actions have that server’s permissions. Writable shared skills can affect other sandboxes using the same store. Treat both as explicit extensions of the boundary. Integration trust boundaries

For Mainframe, the useful division is clear: give an agent enough room to install tools, investigate and test in an isolated environment. Keep production access and publishing behind deliberate permissions, and review the code that comes back. A hardened container fits a predictable job well; a dedicated sandbox becomes especially useful when the agent needs to discover its toolchain along the way.