Sandboxed AI Agents: What Docker Isolates and What It Does Not

Docker can reduce the blast radius of an AI agent, but a container is not an automatic security boundary. Namespaces give a process a restricted view of files, processes, and networks. Cgroups can limit resources when you configure them. Bind mounts, the Docker socket, elevated capabilities, privileged mode, devices, secrets, and network settings can reopen access to the host or other systems.

noHuman Team is a native app for macOS and Windows, not a Docker-based agent sandbox. Its security tradeoffs are covered below. The Docker guidance in this article applies when you build or operate a containerized agent yourself.

TL;DR

Containers isolate views of the operating system, but they share a kernel boundary rather than virtualizing hardware
A mounted host directory is reachable by the container with the permissions you grant
Mounting the Docker socket or using privileged mode can undermine most of the intended isolation
CPU and memory limits help only when they are configured and enforced by the runtime
Use a virtual machine or stronger sandbox when the workload is hostile or the isolation requirement is strict

Why AI Agents Need Boundaries

An agent may write files, run package managers, execute generated code, browse untrusted pages, and call external services. Each capability adds a path for mistakes or malicious input.

Common risk scenarios include:

A broad cleanup command deletes more files than intended
A dependency or downloaded script reads available secrets
Web content attempts to redirect the agent through prompt injection
A failed build enters a retry loop and consumes resources
An agent sends confidential material to an unintended service

Docker can constrain some of these paths. It cannot decide which instruction is trustworthy, remove secrets that you injected, or protect a host path you deliberately mounted read/write.

What a Docker Container Actually Provides

On a Linux host, containers use kernel features such as namespaces and cgroups. On macOS and Windows, Docker Desktop typically runs Linux containers inside a managed virtual machine. The exact boundary therefore depends on the host, runtime, and configuration.

A normally configured container can have:

A filesystem view built from its image and writable container layer
Its own process namespace
A separate network namespace
A configured set of Linux capabilities
CPU and memory controls, if limits are set

These controls reduce what a process can see and do by default. They are not equivalent to a separate physical computer, and they are not all enabled or restrictive by default.

Host or Docker Desktop VM
└── Container boundary
    ├── image and writable layer
    ├── namespaced processes
    ├── container network
    ├── explicitly mounted host paths
    ├── injected secrets and environment variables
    └── configured capabilities and devices

The lower half of that list is where many security assumptions fail.

The Access Paths That Matter

Bind Mounts and Volumes

A bind mount exposes a host path to the container. If it is mounted read/write, the agent can modify or delete files in that path. A read-only mount reduces write risk but still exposes the data to any process in the container.

Mount the narrowest directory the task needs. Do not mount a home directory, credential directory, or broad workspace merely for convenience.

services:
  agent:
    volumes:
      - ./task-workspace:/workspace:rw
      - ./reference-data:/reference:ro

The shared workspace is therefore not a sealed “mail slot.” It is a real access path whose scope and mode you must review.

The Docker Socket

Mounting /var/run/docker.sock lets a container control the Docker daemon. On many installations, that control can be used to start privileged containers or mount host paths. Treat Docker socket access as high privilege, not as ordinary inter-container communication.

Privileged Mode, Capabilities, and Devices

--privileged, broad capability grants, host devices, and weak security profiles expand what a container can do. Start with minimal privileges, drop capabilities that are not needed, and add back only what the task requires.

Running as a non-root user is useful defense in depth. It does not make a privileged or dangerously mounted container safe.

Network Access

Default container networking often permits outbound connections. Depending on the platform and network, a container may also reach other containers, host services, or devices on the local network.

Define what the agent must reach. Separate workloads onto appropriate networks and apply egress controls outside Docker when destination restrictions matter. A container network alone is not a complete outbound firewall.

Secrets and Environment Variables

Any secret available inside the container should be treated as available to the agent and to code it runs. Prefer short-lived, scoped credentials. Do not assume a container prevents exfiltration when the process has both the secret and outbound network access.

Resource Limits Reduce Impact, Not Risk to Zero

CPU and memory limits can keep one workload from consuming all configured resources. They must be set; Docker does not infer safe limits for an agent.

services:
  agent:
    mem_limit: 2g
    cpus: 2

Confirm the syntax and behavior for your Compose and runtime versions. Also consider process limits, storage growth, log rotation, and timeouts. A memory limit does not prevent disk exhaustion or expensive external API calls.

The host can still slow down under load, especially when several containers share the same Docker Desktop virtual machine. Test limits on the machines where the agents will run.

A Safer Baseline for Containerized Agents

Use this as a review list, not as a certification:

Use a dedicated, minimal image. Pin dependencies and rebuild from reviewed sources.
Run as a non-root user. Consider user namespaces or rootless Docker where compatible.
Avoid privileged mode. Drop unnecessary capabilities and do not expose host devices.
Never mount the Docker socket unless daemon control is the explicit requirement. Isolate that workload separately if it is required.
Keep mounts narrow. Prefer read-only access for reference material and a dedicated writable workspace for output.
Set resource and execution limits. Cover memory, CPU, processes, storage, logs, wall-clock time, and external spending.
Restrict network paths. Allow only the destinations and peers the workflow needs.
Use scoped credentials. Rotate them and avoid long-lived secrets in images or environment files.
Keep the host, Docker, images, and dependencies patched. Container escapes and supply-chain vulnerabilities are real possibilities.
Log and review actions. Preserve commands, tool calls, approvals, and relevant network events.

If the container runs untrusted code with valuable host mounts, daemon access, privileged mode, or broad secrets, “it runs in Docker” is not a meaningful safety conclusion.

Docker vs Virtual Machines and Stronger Sandboxes

Containers and virtual machines solve different problems.

Boundary	Main benefit	Important limitation
Standard container	Efficient packaging and process isolation	Shares a kernel boundary; configuration can expose host resources
Virtual machine	Separate guest kernel and stronger workload boundary	More operational and resource overhead
Sandboxed container runtime	Adds an isolation layer around container workloads	Compatibility and operational tradeoffs vary
Native process	Direct host integration and simple desktop UX	Usually runs with the user's operating-system permissions unless separately sandboxed

Use a virtual machine or a sandboxed runtime when you must execute hostile code or enforce a stronger tenant boundary. Docker can still be used inside that boundary for packaging.

Containers and VMs do not provide interchangeable security boundaries. Threat model, configuration, host platform, and runtime matter.

How noHuman Team Approaches the Boundary

noHuman Team currently runs each noHuman as a supervised native process on macOS or Windows. It does not claim full filesystem isolation from the user's account.

Its controls address different risks:

For gateway-managed Claude and ChatGPT connections, workers use stand-in credentials and the local gateway adds provider authentication
Agents have their own working state and browser profiles while collaborating through a workspace selected by the user
Approval controls govern sensitive actions according to the configured autonomy level
Per-agent budgets and turn limits constrain unattended work

Native sign-ins and fallback paths can store real credentials in worker files. A native process can still reach data allowed by the operating-system account; separate folders do not provide a filesystem sandbox. Choose the workspace carefully, review permissions, and use a VM or other sandbox if you require a hard filesystem boundary. The AI accounts guide explains credential storage and access.

How to Choose the Right Isolation Level

Ask:

Is the agent running code from the public internet?
What host data must it read or write?
Which secrets will it receive?
Can it reach internal services or the local network?
What happens if its process, dependency, or instruction is malicious?
Do you need protection from mistakes, hostile code, or both?

For a trusted build in a narrow workspace, a hardened container may be appropriate. For untrusted code with sensitive host data nearby, use a stronger boundary and remove unnecessary connectivity.

Key Takeaways

Docker reduces access by default, but configuration determines the real boundary
Bind mounts expose host data, and read/write mounts allow host-file changes
Docker socket access, privileged mode, devices, capabilities, networks, and secrets deserve explicit review
Resource limits must be configured and do not cover every form of exhaustion
noHuman Team is a native macOS and Windows app; use stronger isolation separately when your threat model requires it

Frequently Asked Questions

Is Docker safe enough for an AI agent?

It can be appropriate for a defined threat model when hardened and monitored. It is not safe merely because the process is in a container. Review mounts, daemon access, privileges, network paths, secrets, limits, and host patching.

Can a Docker container access host files?

Yes, when host paths are mounted or when another privileged path provides host access. A normal container cannot browse arbitrary host paths by default, but a bind mount exposes exactly what you configure, with the configured read or write permissions.

Can a container reach my local network?

Often, yes. Behavior depends on the platform and network configuration. Default outbound access should not be confused with a restricted allowlist. Test and enforce the network policy you need.

Can a Docker container escape?

Container escapes are possible through runtime or kernel vulnerabilities and dangerous configuration. Keep the stack patched, reduce privileges, and use a stronger isolation layer when the consequence of escape is unacceptable.

Are Docker containers as secure as virtual machines?

Not as a general rule. A VM has a separate guest kernel, while a standard Linux container shares a kernel boundary with its host or Docker Desktop VM. Which is appropriate depends on the threat model and operational constraints.

Does noHuman Team run agents in Docker?

No. The current app runs supervised native processes on macOS and Windows. It uses credential, approval, workspace, budget, and execution controls, but it does not claim container-level filesystem isolation.

Want a native local team with visible approval controls? Get noHuman Team for macOS or Windows. If your threat model requires a container or VM boundary, add that boundary explicitly rather than assuming the native app provides it.