Why Coding Agents Need More Than Containers

A developer asks a coding agent to fix a failing test. The agent reads the repository, edits a source file, runs the test suite, installs a missing package, follows an error in a build script, and tries again.

For the developer, that looks like useful automation. For a security team, it is a process tree with shell access, filesystem writes, package-manager access, and possible network access. The model is only one part of the risk. The runtime around the model is where the agentʼs permissions become real.

Coding agents are starting to break the assumptions that traditional sandboxing was built around. They do not run one known binary with one fixed permission profile. They operate through loops, tools, shells, dependencies, repositories, and local developer context.

That is why recent engineering work around coding-agent sandboxes is converging on one practical question: how do you let an agent work without giving it the host?

The answer is becoming a layered runtime boundary, where filesystem rules, process controls, network policy, credential handling, and approval gates define what the agent can actually do.

The failure mode is no longer theoretical. Recent vulnerabilities in agent frameworks have shown how prompt injection can become an execution risk when the surrounding tool layer exposes unsafe paths. In one case, prompt-controlled input reached a code execution path. In another, a function intended to transfer files from a containerized environment to the host gave the model a host file-write primitive.

That second case is especially important. It was not a traditional container escape. The sandbox boundary was weakened by the tool architecture around it. If an agent can call a helper that writes to the host, the runtime has effectively handed the model a bridge across the boundary.

This is the core problem for coding-agent sandboxes. Agents need enough access to be productive. They need to inspect code, run commands, install dependencies, execute tests, and modify files. At the same time, those same capabilities can be used to exfiltrate data, poison build configuration, modify hooks, abuse credentials, or reach internal services.

OWASPʼs Agentic AI Top 10 treats unexpected code execution as a major agentic risk area, with sandboxing, input validation, and allowlisting positioned as core controls rather than optional hardening. That reflects the broader shift: once agents can act inside a runtime, security has to move closer to the place where those actions happen.

How the Mechanism Works

The most useful recent architecture is OpenAIʼs Codex Windows sandbox. It matters because it shows what happens when an AI coding agent has to work inside a real developer environment, and existing operating-system primitives do not fit cleanly.

OpenAI evaluated AppContainer, Windows Sandbox, and Mandatory Integrity Control. Each failed for a related reason. Coding agents cannot declare all required capabilities in advance, cannot easily operate inside a separate disposable desktop when they need to work on a real checkout, and cannot rely on broad workspace relabeling without changing the trust model of the developerʼs project.

The shipped Codex design combines several Windows primitives instead of relying on one sandbox feature. In elevated mode, Codex creates dedicated local sandbox users. It uses restricted tokens to reduce the privileges available to sandboxed processes. It applies filesystem ACLs so the sandbox can write only where intended. It uses Windows Firewall rules scoped to the sandbox user to enforce network restrictions. It also relies on a command-runner binary that launches child processes under the correct restricted context.

That process-tree point is the important part. Coding agents do not execute one command and stop. They spawn shells, which spawn package managers, which spawn scripts, which spawn other tools. The sandbox has to follow the full chain. If a child process can escape the original restriction set, the model does not need a sophisticated exploit. It only needs one command path that leaves the boundary behind.

Network control is another hard layer. Environment-level controls, such as proxy variables or blocking stubs earlier in the path, are not enough on their own. Processes can ignore environment variables, bypass path lookups, or open sockets directly. Stronger designs move enforcement into the operating system, firewall, proxy, container, or VM layer rather than relying only on process behavior.

Docker Sandboxes take a different route. Instead of composing Windows primitives around a local process tree, Docker places the agent inside an isolated microVM. Each sandbox gets its own Docker daemon, filesystem, and network. This lets the agent install packages, build containers, and run development tasks without mounting the host Docker socket into the agent environment.

The difference matters because a container with access to the host Docker socket can indirectly control host-level Docker resources. A microVM with its own daemon gives the agent a more complete development environment while keeping that control plane separate from the host.

Other coding-agent tools are applying known local primitives to the same problem, including macOS Seatbelt, Linux controls such as Landlock and seccomp, and Docker or Podman-based isolation. These implementations are useful signals that the same pattern is spreading: coding agents need a runtime boundary that travels with the commands they execute.

Across these approaches, the runtime has to answer six practical questions:

What can the agent read?

What can the agent write?

What commands can it run?

Do child processes inherit the same limits?

Can it reach the network?

Can it access credentials or host services?

Those questions define the real authority of the agent.

Analysis: Why This Matters Now

The key change is that coding agents are becoming local execution systems. The security boundary can no longer sit only at the model interface. It has to exist where actions happen.

The most interesting engineering tradeoff is not whether to sandbox. It is where to place the boundary.

A local OS sandbox preserves the developer experience. The agent can work in the real checkout, use local tools, and operate close to the normal development loop. The cost is platform-specific complexity. OpenAIʼs Windows design needed dedicated users, restricted tokens, ACLs, firewall rules, a setup binary, and a command runner because no single Windows primitive matched the workload.

A microVM sandbox gives a stronger host boundary. Dockerʼs model lets the agent operate inside an isolated environment with its own Docker daemon and network controls. The cost is lifecycle and workflow complexity. The workspace still has to be mounted or synchronized because the agent needs to modify real project files.

A container-based sandbox is familiar and often easier to deploy, but it can be weaker if the agent has access to sensitive mounts, host sockets, broad network egress, or inherited credentials.

Approval gates help, but they are not a substitute for runtime controls. If every command requires approval, developers may stop reviewing carefully. If approvals are too loose, the agent can cross important boundaries with a click. The better pattern is to let routine actions proceed inside a constrained environment and reserve approval for boundary crossings.

The design goal is a boundary strong enough for the risk and usable enough for developers to keep it enabled.

Implications for Enterprises

Enterprises evaluating coding agents should audit four control areas: filesystem scope, network egress, credential inheritance, and tool-layer exposure. The first three are familiar security questions in a new runtime. The fourth is easier to miss because it often sits outside the sandbox itself.

Tool-layer exposure matters because a sandbox can be technically sound while the surrounding tool layer creates a host bridge. File-transfer helpers, command runners, plugin APIs, MCP tools, and privileged operations all need security review. The right question is not only where the agentʼs process runs. It is also what the agent is allowed to call.

For platform teams, the adoption question is practical. Which sandbox mode works across the organizationʼs operating systems? Which workflows break under default-deny network rules? How are private package registries handled? Can developers inspect what changed? Can security teams see commands, network requests, approvals, and file writes?

For governance teams, the evidence model matters. Agent usage logs are useful, but they are not enough. The stronger evidence is action-level: what the agent executed, what it changed, what it tried to access, what was blocked, and what required human approval.

Risks and Open Questions

The main unresolved risk is workspace mutation. Even a strong sandbox may allow the agent to edit repository files. That is the point of a coding agent. But repository files can also define future execution. Git hooks, CI workflows, package scripts, IDE tasks, and build configuration can turn a normal-looking file change into a delayed execution path.

The second risk is fallback behavior. Some systems provide weaker modes for compatibility or environments where an elevated setup is unavailable. Those modes may be reasonable, but they should be treated as different security postures.

The third risk is developer pressure. If the sandbox makes common tasks painful, teams will disable it, bypass it, or approve everything. That is an engineering requirement, not just a user-training issue. The runtime boundary has to support real development without quietly expanding the agentʼs authority.

Coding-agent sandboxing is becoming less about one containment technology and more about runtime design. The emerging question is simple: when the agent acts, what boundary acts with it?

Further Reading

• OpenAI, “Building a safe, effective sandbox to enable Codex on Windows” OpenAI, “Running Codex safely at OpenAI” “Running Codex safely at OpenAI”
• Docker Docs, “Docker Sandboxes”
• Microsoft Security Blog, “When prompts become shells: RCE vulnerabilities in AI agent frameworks.”
• Cursor, “Implementing a secure sandbox for local agents.”
• Gemini CLI documentation, “Sandboxing in the Gemini CLI.”
• OWASP, “Top 10 for Agentic Applications”