{"slug": "docker-sandboxes-changed-the-trust-boundary-for-ai-coding-agents", "title": "Docker Sandboxes Changed the Trust Boundary for AI Coding Agents", "summary": "Docker Sandboxes introduce a new trust boundary for AI coding agents by running them inside a microVM with its own kernel and Docker Engine, mediating host access through explicit workspace, credential, network, skills, and MCP boundaries. The writeup details three file boundary modes—direct mount, clone mode, and mountless—and argues that the useful security question is which resources cross the isolation boundary, in which direction, and with what authority. It also notes that shared skill stores and host-side MCP servers can extend authority beyond the sandbox itself.", "body_md": "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.\n\nThe useful security question is not “Is the agent inside a container?” It is:\n\nWhich resources cross the isolation boundary, in which direction, and with what authority?\n\nDocker 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.\n\nThat is a stronger model than starting an agent directly on a developer laptop. It is not the same as making the agent harmless.\n\nThere are three materially different file boundaries:\n\n| Mode | Host repository | Agent writes | \n|---|---|---|\n| Direct mount | Shared read-write | Appear immediately in the working tree | \n| Clone mode | Host repository mounted read-only | Private in-VM clone | \n| Mountless | Not shared | Sandbox filesystem only | \n\nDirect 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.\n\nClone 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.\n\nThe choice should follow the task, not developer habit.\n\nDocker's local sandbox model separates several capabilities:\n\nThe 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.\n\nProvider 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.\n\nOutbound 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.\n\n“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.\n\nA 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.\n\nThe 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.\n\nFor every capability, write down four facts:\n\n```\ntype CapabilityBoundary = {\n  resource: \"workspace\" | \"network\" | \"credential\" | \"mcp\" | \"skill\";\n  direction: \"into_sandbox\" | \"out_of_sandbox\" | \"both\";\n  authority: string;\n  reviewBeforeUse: boolean;\n};\n```\n\nFor example:\n\n``` js\nconst policy: CapabilityBoundary[] = [\n  {\n    resource: \"workspace\",\n    direction: \"both\",\n    authority: \"private clone only\",\n    reviewBeforeUse: true,\n  },\n  {\n    resource: \"network\",\n    direction: \"out_of_sandbox\",\n    authority: \"registry and model API only\",\n    reviewBeforeUse: false,\n  },\n  {\n    resource: \"mcp\",\n    direction: \"both\",\n    authority: \"read-only issue tracker\",\n    reviewBeforeUse: true,\n  },\n];\n```\n\nThis forces “the agent has MCP” into a specific statement about a specific server and tool set.\n\nBefore running an autonomous coding task:\n\nThe last step matters because isolation controls *where* code runs. It does not decide whether a proposed business action is appropriate.\n\nThe 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.\n\nMicroVM 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.\n\nThat 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.", "url": "https://wpnews.pro/news/docker-sandboxes-changed-the-trust-boundary-for-ai-coding-agents", "canonical_source": "https://dev.to/raju_dandigam/docker-sandboxes-changed-the-trust-boundary-for-ai-coding-agents-10k6", "published_at": "2026-09-20 16:42:38+00:00", "updated_at": "2026-09-20 16:54:20.442876+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-tools", "developer-tools", "agent-protocols"], "entities": ["Docker", "Docker Sandboxes", "MCP"], "alternates": {"html": "https://wpnews.pro/news/docker-sandboxes-changed-the-trust-boundary-for-ai-coding-agents", "markdown": "https://wpnews.pro/news/docker-sandboxes-changed-the-trust-boundary-for-ai-coding-agents.md", "text": "https://wpnews.pro/news/docker-sandboxes-changed-the-trust-boundary-for-ai-coding-agents.txt", "jsonld": "https://wpnews.pro/news/docker-sandboxes-changed-the-trust-boundary-for-ai-coding-agents.jsonld"}}