Docker Sandboxes Changed the Trust Boundary for AI Coding Agents

A coding agent that can only suggest a patch is one kind of risk. An agent with a shell, package manager, Docker daemon, credentials, and network access is another.

The useful security question is not “Is the agent inside a container?” It is:

Which resources cross the isolation boundary, in which direction, and with what authority?

Docker Sandboxes make that question concrete. A local sandbox runs the agent inside a microVM with its own kernel and Docker Engine. The agent has broad control inside that VM—including sudo—while access to the host is mediated through explicit workspace, credential, network, skills, and MCP boundaries.

That is a stronger model than starting an agent directly on a developer laptop. It is not the same as making the agent harmless.

Start with the workspace mode

There are three materially different file boundaries:

Mode	Host repository	Agent writes
Direct mount	Shared read-write	Appear immediately in the working tree
Clone mode	Host repository mounted read-only	Private in-VM clone
Mountless	Not shared	Sandbox filesystem only

Direct mode is convenient for an interactive edit-review loop. It also means the agent can change package.json scripts, CI configuration, editor tasks, AI configuration, and other files that may execute later on the host.

Clone mode changes the review boundary. The agent works on a private clone while the original host repository remains read-only. That is a better default for broad exploratory tasks or unfamiliar repositories. Mountless mode is strongest when the task does not require host files.

The choice should follow the task, not developer habit.

Isolation does not end at the filesystem

Docker's local sandbox model separates several capabilities:

Docker Engine

The sandbox receives a private Docker Engine rather than access to the host daemon. This matters because mounting the host Docker socket into an ordinary container can effectively grant host-level control.

Credentials

Provider credentials can be injected by a host-side proxy into permitted outbound requests, so raw key values do not need to enter the VM. This reduces credential exposure, but the agent can still exercise whatever authority those proxied credentials grant.

Network

Outbound TCP traffic passes through a host proxy and a deny-by-default policy. Review the active allowlist. Broad domains may permit more services than the task needs.

“Deny by default” does not necessarily mean “nothing is reachable.” Docker's Balanced preset begins with a baseline allowlist for common model providers, package managers, code hosts, registries, and cloud services; Open and Locked Down differ materially. Inspect the effective rules with sbx policy ls and narrow them for the task instead of inferring the policy from the product name.

Shared skills

A shared skill store is a deliberate exception: one sandbox can modify instructions or scripts later consumed by another. If several sandboxes share it read-write, treat them as participating in the same trust boundary.

MCP servers

The MCP gateway is another explicit bridge. Remote servers remain outside the VM. Local stdio MCP servers run on the host, not inside the sandbox. A host-side MCP tool can therefore have authority the sandbox itself does not.

Threat-model the whole action path

For every capability, write down four facts:

type CapabilityBoundary = {
  resource: "workspace" | "network" | "credential" | "mcp" | "skill";
  direction: "into_sandbox" | "out_of_sandbox" | "both";
  authority: string;
  reviewBeforeUse: boolean;
};

For example:

const policy: CapabilityBoundary[] = [
  {
    resource: "workspace",
    direction: "both",
    authority: "private clone only",
    reviewBeforeUse: true,
  },
  {
    resource: "network",
    direction: "out_of_sandbox",
    authority: "registry and model API only",
    reviewBeforeUse: false,
  },
  {
    resource: "mcp",
    direction: "both",
    authority: "read-only issue tracker",
    reviewBeforeUse: true,
  },
];

This forces “the agent has MCP” into a specific statement about a specific server and tool set.

A practical review sequence

Before running an autonomous coding task:

1. Prefer clone or mountless mode unless live host edits are required.
2. Remove network destinations the task does not need.
3. Provide task-scoped credentials with the least useful authority.
4. Review every local MCP server as host code.
5. Disable shared skills when cross-sandbox mutation is unnecessary.
6. Inspect changes before executing modified hooks, scripts, or CI files.
7. Keep human approval around publishing, deployment, and other irreversible actions.

The last step matters because isolation controls where code runs. It does not decide whether a proposed business action is appropriate.

The discussion above is about Docker's documented local sandbox model. Cloud sandboxes have their own lifecycle, credential, and connectivity behavior. Record which environment executed the task before treating a sandbox result as security evidence.

A sandbox is a boundary, not a verdict

MicroVM isolation, a private Docker daemon, proxied credentials, and explicit network policy significantly improve the execution boundary for coding agents. The remaining risk travels through the resources intentionally shared across it.

That is the design lesson worth carrying to any agent environment: grant the smallest workspace, network, credential, and tool surface that can complete the task—and treat every bridge back to the host as part of the security model.

References

• Docker Sandboxes
• Docker Sandboxes security model

Comments

[mthburnsbarber-web]

"A sandbox is a boundary, not a verdict" — the cleanest summary of what isolation actually provides and doesn't. The microVM and private Docker daemon change where code runs; they don't evaluate whether what it does is appropriate.

The CapabilityBoundary type pattern is useful precisely because it forces specificity. "The agent has MCP" is not a security statement. "The agent has read-only access to a specific issue tracker via a remote MCP server that runs on the host" is. The difference between those two descriptions is most of the risk analysis.

The shared skills store point is easy to overlook. If sandbox A can write skills that sandbox B reads and executes, they're in the same trust boundary regardless of how isolated each VM individually appears. That cross-sandbox mutation surface is where a lot of agent pipelines accidentally expand their blast radius.

We build multi-step automation stacks at Black Label and the "clone mode for exploratory tasks, direct mode only when live edits are actually required" framing is the right default. Most agents don't need live host edits — they need the repo state at task start. Keeping the original read-only until review changes what a bad diff can actually affect.