Docker Sandboxes redraw the trust boundary for AI coding agents

A post on dev.to by Raju Dandigam makes a pointed argument about Docker Sandboxes: putting an AI coding agent in a container does not make it safe, it moves the risk to the seams between the sandbox and the host.

An agent that can only propose a patch is one kind of risk, the post notes; an agent holding a shell, a package manager, a Docker daemon, credentials and network access is another. Containerising the second kind does not collapse that difference. According to the author, the question worth asking is which resources cross the isolation boundary, in which direction, and with what authority.

What the sandbox actually isolates

In Docker's documented local model, the agent runs inside a microVM with its own kernel and its own Docker Engine. Inside that VM the agent has broad powers, including sudo. Reach to the host is instead mediated through a defined set of boundaries covering workspace files, credentials, network, shared skills and MCP servers.

Two details stand out. The sandbox receives a private Docker Engine rather than the host daemon, which matters because mounting the host's Docker socket into an ordinary container is a well-known route to host-level control. And provider credentials can be injected by a host-side proxy into approved outbound requests, so raw API keys never enter the VM. That limits key exposure, but the agent can still exercise whatever authority those proxied keys carry.

Workspace mode sets the review boundary

The post splits file access into three modes with quite different consequences. In direct mount, the host repository is shared read-write and agent edits appear immediately in the working tree. That suits an interactive edit-review loop, but it also lets the agent rewrite CI configuration, package. scripts, editor tasks or agent configuration files that will execute later on the host, outside the sandbox.

In clone mode the host repository is mounted read-only and the agent works on a private clone inside the VM, which the author recommends as the default for exploratory work or unfamiliar repositories. Mountless mode shares no host files at all and is the strongest option when the task does not need them. The choice, the post argues, should follow the task rather than developer habit.

The bridges that stay open

Outbound network traffic passes through a host proxy under a deny-by-default policy, but the post cautions that this does not mean nothing is reachable. Docker's Balanced preset ships a baseline allowlist covering common model providers, package managers, code hosts, registries and cloud services, and it differs meaningfully from the Open and Locked Down presets. The recommendation is to inspect the effective rules with the sbx policy ls command and narrow them for the task instead of inferring behaviour from the preset's name.

Two further bridges get specific attention. A shared skill store is a deliberate exception to isolation: one sandbox can modify instructions or scripts that another sandbox later consumes, so several sandboxes sharing it read-write effectively sit in the same trust boundary. And the MCP gateway matters because local stdio MCP servers run on the host rather than inside the VM, meaning a host-side MCP tool can hold authority the sandbox itself does not have.

A pre-flight checklist

Before letting an agent run autonomously, the post recommends preferring clone or mountless mode unless live host edits are required, removing network destinations the task does not need, and issuing task-scoped credentials with the least authority that works. It also advises reviewing every local MCP server as if it were host code, disabling shared skills when cross-sandbox mutation is unnecessary, and inspecting changes before executing modified hooks, scripts or CI files.

Human approval, the author adds, should remain on publishing, deployment and other irreversible actions, because isolation governs where code runs, not whether a proposed business action is appropriate. One caveat applies: the analysis covers Docker's local sandbox model, and cloud sandboxes have their own lifecycle, credential and connectivity behaviour, so teams should record which environment executed a task before treating a sandbox result as security evidence.

Why it matters

Coding agents are rapidly acquiring exactly the capabilities that make the question "is it containerised?" insufficient: shells, package managers, daemons, credentials and network reach. Docker Sandboxes genuinely improve the execution boundary through microVM isolation, a private daemon, proxied credentials and explicit network policy. The residual risk travels through the resources deliberately shared across that boundary, and those bridges are easy to miss because each one looks like a convenience feature. The lesson the post draws generalises to any agent runtime: grant the smallest workspace, network, credential and tool surface that completes the task, and treat every bridge back to the host as part of the security model.