AI coding agents are incredible. They refactor code, write tests, debug across files. But there's a problem nobody talks about enough: they read everything in your project directory, including your .env files, API keys, and private certificates.
I found out the hard way.
The Incident
I was using Claude Code to investigate an issue that spanned both a server-side project and an iOS app. The server repo was my working directory, but the iOS source lived in a sibling directory. I asked Claude Code if it could see the iOS code too. It said yes — so I let it investigate.
What I didn't realize: the iOS project had its own .claude/settings.json with deny rules to protect API keys. But Claude Code only reads the settings from the directory it was launched in. The iOS project's deny rules were ignored. The AI read the API keys.
Fortunately, they were ad network keys — not catastrophic. But the experience stuck with me. I had configured the protection correctly, and it still didn't work because of a scoping limitation I didn't know about.
And the data backs this up. GitHub reported 39 million leaked secrets in repositories in 2024 alone. With 82% of developers now using AI tools, the attack surface is only growing.
The Problem Is Getting Worse, Not Better
2025 brought a wave of new attack vectors targeting AI coding tools specifically:
PromptPwnd — Attackers inject malicious instructions into PR descriptions and commit messages. When an AI agent processes these in CI/CD, it leaks secrets or modifies workflows. At least five Fortune 500 companies were affected.
IDEsaster — Prompt injection through legitimate IDE features. CVEs were issued for Cursor, Roo Code, JetBrains Junie, GitHub Copilot, and Claude Code.
Rules File Backdoor — Hidden Unicode characters in configuration files silently instruct AI to insert malicious code. Virtually invisible to developers during code review.
These aren't theoretical. They're happening now.
What Existing Solutions Do — and Don't Do
The industry is responding, and there are real options available now:
Claude Code Sandboxing uses OS-level primitives (Seatbelt on macOS, bubblewrap on Linux) to restrict filesystem writes and network access. You can also add Read deny rules in permissions to block AI from reading specific files. This is solid for preventing command execution attacks and prompt injection damage.
Docker AI Sandboxes run AI agents in isolated microVMs with their own Docker daemon. The agent can't touch your host system. Great for giving agents full autonomy without risking your machine.
Docker MCP Toolkit provides 200+ containerized MCP servers with built-in isolation and secret management.
These are good tools. But there are two gaps they don't fully address:
Gap 1: Filesystem-level secret hiding. Claude Code's deny rules are application-level — they depend on correct configuration and the AI tool respecting them. There are also scope limitations: deny rules don't traverse parent directories, so in a monorepo or multi-project workspace, settings in one project won't protect secrets in a sibling project. Docker AI Sandboxes sync your entire workspace directory into the microVM with no mechanism to exclude specific files. In both cases, a .env file sitting in your project directory is either visible or requires careful per-tool configuration to hide.
What if the secrets simply didn't exist in AI's filesystem? Not blocked by a rule, not filtered by a config — just not there.
Gap 2: Cross-container debugging. Docker AI Sandboxes are fully isolated — each sandbox can't communicate with others. Claude Code's sandbox restricts outbound access. But in a real microservice setup, AI needs to check API logs, run tests in other containers, and inspect services to be useful. How do you give it that access safely?
My Solution: AI Sandbox + DockMCP
The existing tools above are valuable — and you should use them. Claude Code's sandboxing reduces permission fatigue. Docker AI Sandboxes provide strong isolation for autonomous agents.
But I needed something that works at a different layer: making secrets physically absent from AI's filesystem, while still giving AI controlled access to other containers for debugging.
I built AI Sandbox — a Docker-based development environment that fills these two gaps:
- Secret hiding: Specific files don't exist in AI's filesystem — not blocked, not filtered, just absent
- Cross-container access: AI can check logs and run tests in other containers through a controlled gateway
It's complementary to existing tools. You can use Claude Code's sandbox inside the AI Sandbox for defense in depth.
How Secret Hiding Works
The trick is surprisingly simple: Docker volume mounts.
# docker-compose.yml
volumes:
# AI sees an empty file instead of real .env
- /dev/null:/workspace/my-app/.env:ro
tmpfs:
# AI sees an empty directory instead of real secrets
- /workspace/my-app/secrets:ro
When AI runs inside the container, it literally cannot see the real files. They don't exist in its filesystem. But other containers — the ones actually running your app — mount the real files normally.
AI Sandbox (where AI runs)
├── my-app/
│ ├── src/ ← AI can read and edit all code
│ ├── .env ← Empty (mounted from /dev/null)
│ └── secrets/ ← Empty directory (tmpfs)
API Container (where your app runs)
├── my-app/
│ ├── src/ ← Same code
│ ├── .env ← Real secrets
│ └── secrets/ ← Real private keys
No runtime agents scanning for secrets. No AI configuration that could be bypassed. The secrets simply don't exist in AI's world.
The risk with this approach is forgetting to hide a file. To catch that, the sandbox runs startup validation that automatically checks whether your AI tool's deny rules (e.g., .claude/settings.json) and your docker-compose.yml volume mounts are in sync. If a secret file is blocked in one but not the other, you get a warning on startup — before AI ever sees it.
How Cross-Container Access Works
Hiding secrets creates a new problem: AI can't access other containers for debugging. That's where DockMCP comes in.
DockMCP is an MCP (Model Context Protocol) server that runs on the host OS and acts as a controlled gateway between the AI sandbox and other Docker containers.
AI Sandbox → DockMCP (host) → API Container
"show me checks returns last
the logs" security policy 100 log lines
AI can:
- Read logs from any allowed container
- Run whitelisted commands (like
npm test) - Check resource usage (CPU, memory)
- Inspect container configuration
AI cannot:
- Start or stop containers
- Access files outside allowed paths
- Run arbitrary commands
- Bypass the security policy
The security policy is defined in a simple YAML file:
security:
mode: "moderate"
allowed_containers:
- "my-api-*"
- "my-web-*"
exec_whitelist:
"my-api":
- "npm test"
- "npm run lint"
blocked_paths:
- "/etc/shadow"
- "**/.env"
DockMCP also automatically masks sensitive data (passwords, API keys, tokens) in log output and command results, so even when AI reads logs from other containers, secrets don't leak through.
For the full configuration reference, see the DockMCP documentation.
Architecture Overview
┌─────────────────────────────────────────┐
│ Host OS │
│ │
│ DockMCP Server (:8080) │
│ ├── Security policy enforcement │
│ └── Container access gateway │
│ │
│ Docker Engine │
│ ├── AI Sandbox │
│ │ ├── Claude Code / Gemini / etc. │
│ │ └── secrets → hidden │
│ │ │
│ ├── API Container │
│ │ └── secrets → real files │
│ │ │
│ └── Web Container │
└─────────────────────────────────────────┘
What This Looks Like in Practice
Here's a real debugging session. I ask AI to help investigate a failing API endpoint:
Me: The
/api/notesendpoint returns 500. Can you check the API logs?
AI uses DockMCP to fetch logs from the API container:
AI: I can see the error in the logs. There's a JWT verification failure at line 42 of
auth.js. The token format changed after a recent update. Let me check the code...
AI reads the auth middleware code (visible in the sandbox), identifies the bug, and proposes a fix. It never sees the JWT secret key (hidden via volume mount), but it doesn't need to — it can see the code and the error logs.
Me: Looks good. Run the tests to make sure it passes.
AI runs npm test via DockMCP in the API container and confirms all tests pass.
The AI had everything it needed to debug and fix the issue, without ever accessing a single secret.
How to Try It
Minimal Setup (Sandbox Only)
If you just want secret hiding without cross-container access:
git clone https://github.com/YujiSuzuki/ai-sandbox-dkmcp.git
cd ai-sandbox-dkmcp
code .
# Cmd+Shift+P → "Dev Containers: Reopen in Container"
Edit docker-compose.yml to hide your secret files, and you're done.
Full Setup (Sandbox + DockMCP)
# 1. Clone and enter
git clone https://github.com/YujiSuzuki/ai-sandbox-dkmcp.git
cd ai-sandbox-dkmcp
# 2. Start DockMCP on host OS
cd dkmcp
make install
dkmcp serve --config configs/dkmcp.example.yaml
# 3. Open DevContainer in VS Code
code .
# Cmd+Shift+P → "Dev Containers: Reopen in Container"
# Or use the CLI sandbox (no VS Code needed):
# ./cli_sandbox/claude.sh or ./cli_sandbox/gemini.sh
# 4. Register DockMCP as an MCP server (inside the container)
claude mcp add --transport sse --scope user dkmcp http://host.docker.internal:8080/sse
# Or for Gemini CLI:
gemini mcp add --transport sse dkmcp http://host.docker.internal:8080/sse
The repo includes a demo application (SecureNote) so you can see the full flow in action. For detailed setup instructions, troubleshooting, and connection verification, see the README.
Honest Limitations
I want to be upfront about what this does and doesn't do:
- Local development only. DockMCP has no authentication yet, so it's designed for local use only. I'd like to add authentication in the future, but no timeline has been set.
- No network restriction by default. AI can still make outbound HTTP requests. You can add network restrictions using Anthropic's official firewall script or Docker network policies.
- Docker required. The volume mount approach means you need a Docker-compatible runtime. No Docker, no secret hiding.
- Only tested on macOS. It should work on Linux and Windows, but I haven't verified it.
- Not a replacement for proper secrets management. This is a development-time protection layer. Use HashiCorp Vault, AWS Secrets Manager, etc. for production.
- Complementary, not competing. This works alongside Claude Code's sandbox and Docker AI Sandboxes. Use them together for defense in depth.
Why This Matters
85% of developers now use AI coding tools (JetBrains, 2025). AI writes 29% of new code in the US. These tools aren't going away — they're becoming the default way we write software.
But the security model hasn't caught up. We give AI full read access to our projects and hope for the best. When something leaks, we rotate keys and move on.
We can do better. The approach doesn't have to be complicated:
- Isolate AI in a container so secrets can be hidden at the filesystem level
- Provide controlled access to other containers for debugging
- Define explicit security policies for what AI can and cannot do
The AI Sandbox + DockMCP template is one implementation of this idea. Hit "Use this template" on GitHub to start your own.
The goal isn't to restrict AI — it's to let AI work freely in a space where secrets simply don't exist.
AI Sandbox + DockMCP is open source (MIT License). Contributions and feedback are welcome on GitHub.
Top comments (0)