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

Description and use

By combining container isolation with volume‑mount secret removal and a controlled gateway, the project fills gaps left by vendor sandboxes: it hides secrets at the filesystem level, validates configurations, and allows safe cross‑container interaction.

Problem

Developers building AI coding agents need to protect secrets and control container access, but existing vendor sandboxes (Claude Code Sandbox, Docker AI Sandboxes) do not cover all threat models.

Outcome

By combining container isolation with volume‑mount secret removal and a controlled gateway, the project fills gaps left by vendor sandboxes: it hides secrets at the filesystem level, validates configurations, and allows safe cross‑container interaction.

Workflow

• 1. Configure docker‑compose.yml with volume mounts to hide secret files (e.g., /dev/null:/workspace/.env:ro).
• 2. Run AI Sandbox container; startup validation checks deny rules against mounts and warns on mismatches.
• 3. HostMCP starts as a gateway, exposing only whitelisted commands and masking sensitive output.
• 4. AI agent interacts with containers via HostMCP, reading logs and running allowed commands, but cannot access blocked paths or start/stop containers unless explicitly enabled.
• 5. If new secret files appear, AI Sandbox prompts the user to decide whether to hide them or leave exposed.

Evidence

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.

Source

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.

Source