Official AI Sandboxes Arrived — Why I Published Mine Anyway

Source: Dev.to

Previously

In my previous article, I wrote about catching Claude Code silently reading API keys from an iOS project — not even in the current directory, but in a parent directory I never pointed it to. No prompt. No permission. It just looked.

That discovery led me down a rabbit hole — and I ended up building AI Sandbox Environment + DockMCP: a system that isolates AI inside a Docker container, hides secrets via volume mounts, and provides controlled access to other containers through MCP (Model Context Protocol).

All that was left was to clean up the repo and publish it. Or so I thought.

Right around that time, I found official solutions in the same space:

• Docker AI Sandboxes — Docker’s official AI sandbox
• Claude Code Sandboxing — Anthropic’s official sandboxing feature

My honest first reaction: “There’s no point publishing this anymore.”

If the officials have it covered, why bother releasing a personal project? So instead of giving up immediately, I decided to read what they actually offered — carefully.

---

Docker AI Sandboxes

• MicroVM‑based isolation
• Run AI agents inside lightweight VMs
• Complete isolation from the host’s Docker daemon, containers, and files
• Sync workspace directories into the VM for autonomous work

It’s a polished approach. VM‑level isolation is robust, and you can manage sandboxes with docker sandbox ls.

Drawbacks (as of this writing)

1. Full workspace sync – directory‑level sync with no mechanism to exclude specific files. If your .env or secrets/ directory lives inside the workspace, the AI sees it. (This could change — the feature is still evolving.)
2. No access to host‑side containers – each sandbox runs its own Docker daemon in a completely isolated VM. You can spin up test containers inside it, but it cannot reach containers already running on the host. When you ask the AI “check the API container logs,” it simply can’t see them.

In real multi‑container development — frontend, API, and database each running in separate containers — this limitation matters a lot.

Claude Code Sandbox

Claude Code takes a different approach. Instead of containers or VMs, it uses OS‑level security primitives (Seatbelt on macOS, bubblewrap on Linux) for process‑level restrictions.

• Filesystem read/write control – blocks writes outside the working directory
• Network access restricted by domain – proxy‑based
• Approved commands auto‑execute; everything else requires user confirmation

File access is controlled through deny rules in settings.json. You can block reads to ~/.ssh/, /etc/, or specific file paths. The network isolation is especially strong — a proxy enforces domain‑level access control, preventing data exfiltration to unauthorized servers. The sandbox runtime is even open‑sourced, which is great for the ecosystem.

Drawbacks

1. No safety net for configuration mistakes – the sandbox itself is solid at the OS level, but which files are hidden depends entirely on getting the deny rules right. Add a new secret file, forget to update the deny rules, and nothing warns you. This isn’t a flaw in the design — it’s an inherent challenge of rule‑based approaches.
2. Cross‑container access is possible but uncontrolled – since Docker commands are incompatible with the sandbox, they run via excludedCommands (outside sandbox protection). This means docker exec and docker logs work, but they bypass the sandbox entirely. There’s no control over which containers get accessed, which commands are allowed, or whether secrets in log output are visible to the AI. (Anthropic may add finer‑grained controls in the future.)

The three‑way comparison

On isolation, all three have answers. Docker AI Sandboxes is the most robust with VM‑level separation. Claude Code Sandbox wins on ease of use. AI Sandbox is container‑based — the weakest of the three, since containers share the host kernel and can’t match VM‑level isolation.

But on what happens after isolation, the existing two don’t say much. An isolated AI is safe, but it’s also powerless. It can’t see API logs, run tests, or trace errors. If “safe but unusable” is the result, people will eventually turn the sandbox off.

Why AI Sandbox + DockMCP matters

AI Sandbox + DockMCP addresses a more specific problem:

“Hide only the secrets — reliably — and let AI access everything else.”

• Mount /dev/null over a file with Docker volume mounts, and the file physically doesn’t exist.
• Mount a directory with tmpfs, and it’s empty.

Unlike deny rules, there’s no ambiguity — no “I wrote the rule but the path resolution didn’t match so it was still readable.” What you mount is what disappears.

Of course, if you forget to add a file to docker‑compose.yml, it stays visible. The same is true for deny rules. That’s why I built automatic validation that runs on every startup, cross‑checking Docker‑compose volume mounts against AI‑tool deny configurations (Claude Code, Gemini Code Assist, Gemini CLI). If something is in the deny list but missing from docker‑compose.yml, you get a warning.

The one thing it can’t catch: secrets that aren’t listed anywhere. The initial inventory — “what needs to be hidden” — is still a human responsibility. But once that list exists, the tooling catches the rest.

volumes:
  - /dev/null:/workspace/api/.env:ro      # .env physically absent
tmpfs:
  - /workspace/api/secrets:ro              # secrets/ is empty

That’s the state of the sandboxing landscape as I see it, and why I still think AI Sandbox + DockMCP has a niche worth sharing.

AI Sandbox + DockMCP

The Problem

“Let AI access other containers — with guardrails.”

DockMCP runs on the host OS as an MCP server, acting as a gateway to the Docker API. The AI can:

• Access logs
• Run whitelisted commands
• Inspect containers

All interactions go through DockMCP.

AI (in container) ──MCP──▶ DockMCP (host) ──Docker API──▶ Other containers
   No Docker socket        Policy enforced            Full access

Controlled Execution

Each container has a whitelist of allowed commands. Anything not on the list is rejected.

exec_whitelist:
  securenote-api:
    - "npm test"
    - "npm run lint"
  securenote-web:
    - "npm run build"

Example: If the AI tries to run rm -rf /, DockMCP blocks it because the command isn’t whitelisted.

File‑system access can also be restricted (e.g., /etc/shadow is blocked).

Security policies are offered in three tiers:

Secret Masking

Passwords and API keys in AI responses are automatically masked using regex patterns. The AI sees the logs, but any secrets are replaced with ***.

Network Control

Network restrictions are weak by default—there’s no AI‑specific outbound traffic filter. You can mitigate this with Docker network settings, but domain‑level granularity is better handled by:

• Claude Code Sandbox (proxy‑based approach)
• Docker AI Sandboxes (VM‑level isolation)

To improve network security, Anthropic’s official firewall scripts can be integrated into the DevContainer. A detailed setup is documented in the Network Restriction Guide.

Why This Matters

Existing solutions focus on isolating AI safely, which is essential. However, real development often requires the AI to:

• Debug multi‑container applications
• Run tests
• Read logs

Balancing isolation with usability is the key challenge. AI Sandbox + DockMCP fills that gap. It isn’t a competitor to official solutions; it’s complementary. If Docker AI Sandboxes included DockMCP‑style controls, or if Claude Code Sandbox added volume‑mount‑level hiding, the overall defense would be deeper.

A Template for Everyone

The repository is published as a GitHub Template Repository.

1. Click “Use this template.”
2. Replace demo-apps/ with your own project.

Because it’s built on plain Docker + MCP, it works with:

• Claude Code
• Gemini CLI
• Any MCP‑compatible tool

Quick FAQ

Call to Action

If you’re working with AI in a multi‑container setup and need secrets handled at the filesystem level, give this a try and let us know what’s missing.

AI Sandbox Environment + DockMCP is available on GitHub:

Click “Use this template” to start using it in your own project.

Feel free to discuss, ask questions, or share feedback in GitHub Discussions.