Official AI Sandboxes Arrived — Why I Published Mine Anyway

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.

The Officials Showed Up

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.

What Docker AI Sandboxes Solve

Docker AI Sandboxes provide 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.

But as I read further, a few things stood out.

The entire workspace gets synced. As of this writing, it's 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.)

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.

What Claude Code Sandboxing Solves

Claude Code's sandboxing 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.

But here too, some things caught my attention.

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.

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 well add finer-grained controls in the future.)

Where They Overlap — and Where They Don't

At this point, things started to crystallize.

Here's the three-way comparison:

	Docker AI Sandboxes	Claude Code Sandbox	AI Sandbox + DockMCP
Isolation	microVM	OS primitives	Docker container
Secret handling	Full sync (no exclusion)	Deny rules (config-based)	Volume mounts (physically absent)
Multi-container	Not possible (isolated VM)	Possible but uncontrolled (docker outside sandbox)	Controlled access via DockMCP
Network control	VM-level	Domain-level (proxy-based)	Docker network (no AI-specific control)
Output masking	None	None	Automatic (regex-based)
Config drift detection	None	None	Validated on startup

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. It can't run tests. It can't trace errors. If "safe but unusable" is the result, people will eventually turn the sandbox off.

The Gap My Project Fills

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, 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

And the second 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. AI accesses logs, runs whitelisted commands, and inspects containers — all through DockMCP.

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

"Controlled" here is specific. Each container has a whitelist of allowed commands. Everything else is rejected.

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

If the AI tries to run rm -rf /, DockMCP blocks it — not on the whitelist. File access to specific paths inside containers (like /etc/shadow) can also be blocked. Security policies come in three tiers: strict, moderate, and permissive.

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

On the other hand, network control is weak. There's no AI-specific restriction on outbound traffic from the container. You can constrain it with Docker network settings, but domain-level granularity is where Claude Code Sandbox's proxy-based approach and Docker AI Sandboxes' VM-level isolation clearly do better. To address this, Anthropic's official firewall scripts can be integrated into the DevContainer. I've documented the setup in a network restriction guide.

Why I Decided to Publish Anyway

Existing solutions focus on isolating AI safely. That's the right problem to solve.

But in real development, AI doesn't work in isolation alone. You need it to debug multi-container applications. Run tests. Read logs. The balance between isolation and usability is what matters.

AI Sandbox + DockMCP fills that gap.

It's not competing with the official solutions — it's complementary. If Docker AI Sandboxes had something like DockMCP built in, they'd be more practical. If Claude Code Sandbox combined its filesystem controls with volume-mount-level hiding, the defense would be deeper.

And there's one more thing that mattered to me personally:

It's a template.

The repo is published as a GitHub Template Repository. Click "Use this template," replace demo-apps/ with your own project, and it works. It's not tied to any specific product — it's Docker + MCP, so it works with Claude Code, Gemini CLI, or any MCP-compatible tool.

It's reassuring when official solutions set the standard. But there are always gaps the officials don't cover. Sharing one answer to those gaps, in a usable form, felt worthwhile.

Summary

Question	Answer
Full overlap with official solutions?	No — isolation approaches are similar, but secret hiding and cross-container access are different
Are officials better in some areas?	Yes — VM-level robustness (Docker), OS-primitive ease of use and network isolation (Claude Code)
Unique value beyond officials?	Yes — filesystem-level secret hiding, controlled cross-container access, config validation
Publish?	Yes

When I first thought "someone already did this," I almost stopped there. I'm glad I didn't. When I actually read what existed, I realized we were solving different problems.

If you're working with AI in a multi-container setup and want secrets handled at the filesystem level, give it a try — and let me know what's missing.

---

AI Sandbox Environment + DockMCP is available on GitHub:
https://github.com/YujiSuzuki/ai-sandbox-dkmcp

Click "Use this template" to start using it in your own project.
Feedback, suggestions, and feature requests are welcome in GitHub Discussions.