Docker Sandbox: Run AI Coding Agents Without Exposing Your Machine

AI coding agents have moved well beyond autocomplete. They can install dependencies, modify files, run test suites, start services, and build container images with little or no supervision.

That capability creates an obvious security problem: the more freedom an agent receives, the greater the damage it can cause when it makes the wrong decision.

Docker Sandbox provides a safer environment for this kind of work. Instead of running the agent in a standard container, it places the workload inside an isolated microVM. The agent can behave as though it controls the machine without gaining control of your actual system.

That difference is important.

The 2024 Stack Overflow Developer Survey showed that developers expected AI tools to play a larger role in code generation, testing, and documentation. By 2025, Google’s DORA research had surveyed nearly 5,000 technology professionals about AI-assisted software development.

AI coding was no longer a side experiment. It had become part of everyday engineering work.

As agents gain more access and autonomy, isolation becomes less of an optional safeguard and more of a basic development requirement.

Why AI agents need a stronger security boundary

Containers share the host kernel

Containers isolate processes, filesystems, and resources, but they still share the host operating system’s kernel.

That model is suitable for many applications. It becomes more difficult to justify when the workload is an autonomous agent that can run arbitrary shell commands, install system packages, and rewrite project files.

A container escape or kernel vulnerability can expose the host. That risk exists with conventional workloads, but an autonomous agent makes it harder to manage because you do not approve every command before it runs.

The Docker socket introduces an even more serious concern.

Developers commonly mount the socket when a container needs to build images or launch other containers:

-v /var/run/docker.sock:/var/run/docker.sock

This mount gives the process access to the host Docker daemon. In many environments, that is effectively equivalent to granting root-level control over the machine.

An agent with access to the Docker socket could create privileged containers, mount host directories, inspect other workloads, or modify resources outside its original container.

That is not a meaningful isolation boundary.

Wider AI adoption makes the risk harder to dismiss

Developers already use AI tools for much more than code completion. An agent can inspect a repository, select tools, execute commands, diagnose failures, apply fixes, and repeat the process without requesting approval at every step.

The 2024 Stack Overflow survey found that developers expected AI adoption to grow substantially in code documentation, testing, and code generation. These are not purely passive activities. Testing and code generation often require access to package managers, build systems, command-line tools, and runtime environments.

Research published in 2024 also found that developers remain cautious about coding assistants because of trust concerns, company policies, limited project context, and uncertainty about generated output.

That tension is unlikely to disappear. You want the agent to complete more work independently, but each additional permission increases the consequences of a mistake.

Docker summarizes the issue directly:

“Powerful agents require isolation.”

The quote comes from Mark Cavage, Docker’s president and chief operating officer, in Docker’s announcement about running NanoClaw inside Docker Sandboxes.

The principle is straightforward: do not depend on an agent behaving correctly. Run it in an environment designed to limit what incorrect or harmful behavior can reach.

How Docker Sandbox and sbx work

Each sandbox runs inside a microVM

When you start a sandbox, Docker does not launch an ordinary container directly on the host.

Instead, it creates a lightweight virtual machine with its own Linux kernel, filesystem, network, and Docker daemon. Docker describes it as a microVM because it provides a stronger virtual-machine boundary without the overhead usually associated with a full traditional VM.

According to the official Docker Sandboxes overview, each sandbox includes:

• its own Docker daemon
• its own filesystem
• its own network
• an isolated workspace
• a separate Linux kernel

A hypervisor separates the sandbox from host processes and files. The agent may have root access inside the microVM, but that authority stops at the VM boundary.

Docker identifies five isolation layers in its security documentation:

1. Hypervisor isolation
2. Network isolation
3. Docker Engine isolation
4. Workspace isolation
5. Credential proxying

Together, these layers give the agent enough freedom to perform useful work while reducing the number of paths it can use to reach the host system.

Each sandbox has a private Docker daemon

Many coding agents need Docker access. They may build images, run integration tests, start databases, or launch an application with Docker Compose.

Docker Sandbox supports those tasks without exposing the host Docker socket.

The microVM runs a separate Docker daemon, so commands such as the following remain inside the sandbox:

docker build .
docker compose up
docker run hello-world

From the agent’s perspective, it has access to a normal Docker environment. From the host’s perspective, those containers and images exist inside an isolated VM.

This architecture avoids the usual Docker socket problem. The agent can create containers, perform privileged operations within the sandbox, and test multi-service applications without gaining control of your local Docker daemon.

That makes Docker Sandbox useful for more than basic code generation. It can support integration testing, build automation, repository analysis, and longer-running autonomous tasks.

How to start and manage a sandbox

Run an agent with sbx

Docker manages sandboxes through the sbx command-line tool.

Review the current platform requirements and installation process in the official getting started guide. These requirements may change as Docker adds support for more platforms and integrations.

After installing the tool and authenticating, open your project directory and launch a supported agent:

cd ~/projects/my-app
sbx run codex

You can start another supported agent in the same way:

sbx run claude

Docker creates a new sandbox for the workspace or reuses an existing one. It then launches the agent inside that environment.

The project becomes available within the sandbox, while the rest of the host remains inaccessible unless you explicitly expose additional resources.

Supported integrations may change over time, so confirm the current agent list in Docker’s documentation before building a permanent workflow around one of them.

Manage the sandbox lifecycle

The CLI provides a small set of commands for managing day-to-day sandbox operations.

List existing sandboxes:

sbx ls

Open a shell inside a running sandbox:

sbx exec <sandbox-name> bash

Stop a sandbox:

sbx stop <sandbox-name>

Remove it:

sbx rm <sandbox-name>

When an application inside the sandbox needs to be accessible from your browser or another local tool, use sbx ports:

sbx ports my-sandbox --publish 8080:3000

This publishes port 3000 inside the sandbox as port 8080 on the host.

Because the sandbox uses its own isolated network, services are not directly reachable from the host by default. You must publish each port intentionally.

Consult the Docker Sandbox usage guide and the sbx CLI reference for the latest command syntax and available options.

Control access to files, networks, and credentials

Decide how the agent reaches your code

A secure runtime does not fully protect you if the agent can freely damage your active working tree.

You still need to decide how the sandbox accesses the source code.

With a direct workspace, the sandbox works against your current project directory. Changes made by the agent appear immediately in your local files. This approach is convenient when you are supervising the work closely and want rapid feedback.

With a cloned workspace, the agent receives a separate copy of the repository. It can add files, rewrite code, or break the build without modifying your original working tree.

A cloned workspace adds another step to the workflow, but it creates a cleaner boundary. It is usually the safer choice for long-running tasks or agents operating with a high degree of autonomy.

Git remains essential in either case. A sandbox limits access to the host, but it does not replace branches, pull requests, protected environments, or code review.

Limit network and credential access

Most agents do not need unrestricted internet access.

A task may require access to GitHub, a package registry, an internal API, or a cloud service. Allow those destinations and block everything else.

Docker Sandbox supports network policies and records outbound activity. Those logs can show which services the agent attempted to contact, helping you refine the policy around the destinations the task genuinely requires.

This is a practical application of least privilege: begin with minimal access and add exceptions only when the workload needs them.

Credentials deserve the same treatment.

Do not store long-lived secrets in the repository or bake them into a reusable image. Use controlled secret injection or Docker’s credential proxy where those features are available.

Gavriel Cohen, creator of NanoClaw, expressed the principle clearly:

“Securing agents cannot be based on trust.”

Treat the agent as a powerful process that may make a poor decision. Give it narrowly scoped credentials, short-lived access, and explicit network limits.

Production credentials should also remain outside development sandboxes. A microVM can reduce the risk to your host machine, but it cannot protect a production system from a valid credential that you deliberately gave to the agent.

Build repeatable environments with Kits

Define sandbox configuration as code

The default sandbox may be enough for simple tasks. Real projects often require specific runtimes, tools, environment variables, startup processes, and network policies.

Docker Sandbox Kits let you define those requirements as code.

A sandbox Kit can configure:

• the base image
• the agent entry point
• installation commands
• startup commands
• environment variables
• files and agent instructions
• allowed network destinations

Installation commands run when Docker creates the sandbox. Startup commands run each time the sandbox starts.

This produces a repeatable environment instead of a VM that every developer must configure manually.

You can keep the Kit in the project repository, review changes through pull requests, and reuse the same configuration across a team.

See the official Kits guide and Docker’s Kit examples for the current configuration fields and implementation patterns.

Understand what the sandbox does not solve

Docker Sandbox reduces the blast radius of an agent’s actions. It does not make those actions correct.

An agent can still:

• write broken code
• delete files within its workspace
• send data through an allowed network destination
• misuse credentials you provide
• introduce vulnerable dependencies
• create expensive cloud resources when given cloud access

You still need automated tests, code review, branch protection, secret scanning, and deployment controls.

Clear task boundaries are equally important. A sandbox should not receive production credentials simply because the runtime itself is isolated.

Docker Sandbox is closer to a seat belt than an autopilot system. It can reduce the damage caused by a bad event, but it does not remove the need for careful engineering practices.

Docker Sandbox FAQ

What is Docker Sandbox?

Docker Sandbox is an isolated runtime for AI coding agents. Each agent runs inside a microVM with its own Linux kernel, filesystem, network, workspace, and Docker daemon.

Is Docker Sandbox the same as a Docker container?

No. A standard container shares the host operating system’s kernel. Docker Sandbox uses a microVM with a separate kernel, creating a stronger boundary between the agent and the host machine.

Why does each sandbox need its own Docker daemon?

Coding agents often need to build images, run containers, and start multi-service environments. A private Docker daemon lets them perform those tasks without accessing /var/run/docker.sock or controlling the host Docker daemon.

Can an agent access my local files?

The agent can access the workspace you expose to the sandbox. It cannot browse the rest of the host filesystem unless you deliberately provide additional access.

Use a cloned workspace when you do not want the agent to modify your active working tree.

Can I run a web server inside a sandbox?

Yes. Direct access from the host is blocked by default because the sandbox has its own network. Use sbx ports to publish a sandbox port to the host.

For example:

sbx ports my-sandbox --publish 8080:3000

Does Docker Sandbox make autonomous agents completely safe?

No. It protects the host and limits the agent’s reach, but the agent can still damage files in its workspace, misuse permitted credentials, or send data to approved network destinations.

Keep code review, Git protections, automated tests, and production access controls in place.