"Don't you trust the AI vendor's own sandbox?" I didn't have a good answer.

An open-source AI sandbox project developer compared its approach with vendor-provided sandboxes like Claude Code Sandbox, highlighting differences in threat models and protection layers. The project, AI Sandbox + HostMCP, offers filesystem-level secret hiding and automatic output masking, addressing gaps in vendor sandboxes such as application-level deny rules and Docker socket access.

I build an open-source AI sandbox project, and when I mention it to people building products and solutions for a living, I sometimes get this reaction: "Don't AI vendors already ship their own sandbox? Don't you trust that?" I froze for a second. It's not that I don't trust it. It's that the layer an AI vendor's own sandbox like Claude Code Sandbox protects, and the layer my project protects, are simply different things. Once you start looking into how to run AI coding agents safely, you keep running into tools with confusingly similar names: Claude Code Sandbox, Docker AI Sandboxes, Docker MCP Toolkit, firejail, gVisor, Firecracker... They all seem to point in the same direction — "isolate the AI agent" — but what they actually protect, and how they work, differ more than you'd expect. This post is my attempt to actually answer that question properly. Here's the comparison up front, as a table. | Feature | Claude Code Sandbox | Docker AI Sandboxes | AI Sandbox + HostMCP this project | |---|---|---|---| | Execution restriction | OS-level | microVM isolation | Container isolation | | File-read blocking | Deny rules application-level | None | Volume mounts filesystem-level | | Multi-project scope | Limited no parent-directory traversal | Single workspace | Whole workspace + per-file hiding | | Cross-container access | Restricted | Isolated | Controlled via HostMCP | | Output secret masking | None | None | Automatic | | Startup validation | None | None | Automatic sync check | | Setup complexity | None needed on macOS; Linux/WSL2 needs bubblewrap + socat | Docker Desktop | Docker + docker-compose | The point isn't "which one is strongest" — it's that each tool targets a different threat model. Let's go through them one by one. Claude Code Sandbox https://code.claude.com/docs/en/sandboxing uses OS-level primitives Seatbelt on macOS, Bubblewrap on Linux to restrict filesystem writes and network access. Adding a Read deny rule in the permission settings also lets you block the AI from reading specific files. The strength here is clear: on macOS it gives you OS-level execution restriction with zero extra setup Linux/WSL2 needs bubblewrap and socat installed . It also cuts down on permission-confirmation friction. That said, there are two gaps that aren't covered. First, deny rules are an application-level mechanism. They depend both on correct configuration and on the AI tool actually respecting the rule. Worse, these deny rules don't traverse parent directories https://github.com/anthropics/claude-code/issues/12962 . In a monorepo or multi-project workspace, that means one project's config won't protect a sibling project's secrets. AI Sandbox sidesteps this at the file level entirely. Each project's secret files are individually hidden from the AI's filesystem via volume mounts, regardless of directory hierarchy. There's no rule to traverse in the first place — the idea is that the rule shouldn't need to exist. Second, there's friction with Docker commands. Docker commands need direct access to the Docker socket, which is structurally incompatible with the sandboxing mechanism. In fact, Claude Code Sandbox's own troubleshooting docs https://code.claude.com/docs/en/sandboxing troubleshooting recommend adding docker to excludedCommands i.e., excluding it from the sandbox . The result: Docker operations run with unrestricted host privileges, entirely outside the sandbox's protection. Aside: firejailOn Linux, firejail often comes up in comparisons. It sandboxes at theprocess levelusing Linux namespaces — the same category as the bubblewrap that Claude Code Sandbox uses. Unlike this project's approach of carving out the AI agent's entire execution environment, firejail is meant to nest inside a larger sandbox.On the narrow question of "hiding secrets," though, it's a different story. firejail's --blacklist option denies access to target paths at the OS kernel level. According to firejail's own docs , blacklisted files/directories "remain visible in the filesystem, but become completely inaccessible." I couldn't confirm from public docs whether the underlying implementation is bind-mount-based, but in the sense that it doesn't depend on the AI tool respecting a rule, it's closer in spirit to AI Sandbox's volume-mount approach than to application-level deny rules though the AI-facing appearance may differ — AI Sandbox shows empty files/directories, which may not be exactly how firejail presents it .That said, firejail is limited to a single process, isn't designed to treat a whole multi-project workspace as one unit, and doesn't cover controlled access to other containers. It's Linux-only, so it's not available on macOS, which is AI Sandbox's primary target. On a Linux dev machine specifically, --blacklist alone could plausibly reproduce secret-hiding on its own, but it doesn't cover the rest. Docker AI Sandboxes https://docs.docker.com/ai/sandboxes runs the AI agent inside an isolated microVM with its own Docker daemon. The agent can't touch the host system at all. The strength : strong microVM-based isolation, full autonomy for the AI agent inside the sandbox, and each sandbox gets its own Docker daemon. There are two gaps . It syncs the entire workspace directory into the microVM, with no mechanism to exclude specific files — so .env files are plainly visible from the inside. This isn't a flaw so much as a difference in design goals: Docker AI Sandboxes exists to "protect the host from the AI agent's execution," not to "hide secrets from the AI." The other gap: because it's fully isolated, a sandbox can't talk to other containers, which rules out cross-container debugging. Docker MCP Toolkit https://www.docker.com/blog/mcp-toolkit-mcp-servers-that-just-work/ provides 200+ containerized MCP servers with built-in isolation and secret management. Its strengths are a rich catalog of pre-built MCP servers and built-in secret management for MCP server configuration. But this tool is focused on isolating MCP servers — hiding project-level secrets from the AI is out of scope. It doesn't address .env files or private keys sitting in your source tree. Given the comparison so far, AI Sandbox + HostMCP can be summarized as filling two specific gaps. Gap 1: Filesystem-level secret hiding Instead of blocking access to secrets via rules which can be misconfigured or bypassed , Docker volume mounts physically remove secrets from the AI's filesystem. volumes: - /dev/null:/workspace/my-app/.env:ro appears as an empty file to the AI tmpfs: - /workspace/my-app/secrets appears as an empty directory to the AI Secrets don't exist in the AI's world at all. Not blocked by a rule, not filtered by a config — they're simply not there. The application container, meanwhile, mounts the real files as usual. As a safeguard against misconfiguration, the sandbox runs a validation check at startup to confirm the AI tool's deny rules stay in sync with the volume mounts in docker-compose.yml . If a secret file is only configured on one side, a warning fires before the AI can access it. A separate check also scans for secret-looking files that aren't hidden in docker-compose.yml , every time an AI session starts. This catches configuration gaps early for files created mid-development, and the AI itself asks the user how to handle a flagged file — whether it actually needs hiding or is fine to leave as-is. Gap 2: Controlled cross-container access HostMCP acts as a gateway between AI Sandbox and Docker containers, enforcing a security policy. The AI can read logs, run whitelisted commands, and inspect containers — but can't access blocked paths or run arbitrary commands. Starting/stopping containers is disabled by default and only works if explicitly enabled in config. Sensitive data passwords, API keys, tokens is automatically masked in output, and HostMCP itself binds only to loopback 127.0.0.1 by default, so it's not reachable from other machines on the network out of the box. So far this has been framed as "versus," but in practice these tools sort into two layers with different properties, and thinking of it that way clarifies where each one fits. Isolation boundary: something you choose based on your threat model Docker AI Sandboxes and AI Sandbox both answer the question "where do you draw the line around the AI agent's entire execution environment?" The former uses a microVM; the latter uses containers plus volume-mount-based secret removal. Since their roles overlap, they're not meant to be stacked — you pick one based on your threat model. Claude Code Sandbox targets something different — it only restricts Bash command execution at the OS level — so it can be nested inside whichever outer environment you chose. That said, when nesting inside an unprivileged container like AI Sandbox, bubblewrap can fail to mount a fresh /proc , per the official docs https://code.claude.com/docs/en/sandboxing troubleshooting , requiring enableWeakerNestedSandbox — in which case the nested sandbox's process-space isolation ends up depending on the outer container boundary instead the permission deny rules themselves are unaffected and keep working . So it's not quite true that "nesting inside AI Sandbox gets you maximum protection" — there's an added benefit, but it's limited. | Isolation boundary option | Role | |---|---| | Claude Code Sandbox | Restricts Bash command execution at the OS level nestable inside other boundaries, with the caveat above | | Docker AI Sandboxes | Isolates the whole AI agent in a microVM | | AI Sandbox this project | Container isolation + volume mounts to remove secrets from the AI's filesystem | If you're curious how these boundaries relate to the kernel-level isolation tech gVisor, Firecracker that managed cloud AI services use, and whether it's worth adopting locally, I cover that in Part 2 — it's a tangent from AI Sandbox's own scope, so I split it out to keep this post focused. Permission layer: usable independently, alongside anything above HostMCP's cross-container access control and Managed Settings' deny rules sit at a different layer from the isolation boundary. They control access at the level of individual tool calls, so they can be layered independently on top of whichever isolation boundary you pick above. "How should you isolate an AI agent?" doesn't have a single right answer. Claude Code Sandbox restricts command execution, Docker AI Sandboxes isolates everything inside a microVM, and gVisor/Firecracker are used in production as even stronger isolation technologies in the cloud. Each protects a different layer, against a different threat model. What AI Sandbox + HostMCP chose to focus on is: physically erasing secrets at the filesystem level, and safely bridging cross-container access behind an approval flow. It's built specifically to fill those two gaps, and designed to be additive — not in competition with the other isolation boundaries or permission layers above. Safe AI-driven development needs both: protecting secrets, and not getting in the way of the humans and AI actually doing the work. AI Sandbox is built to try to hold both of those at once. If you've ever looked at your own dev setup and thought "wait, is the AI reading my private keys too?" — take a look at the repo.