Claude Code Sandbox: The Complete Guide to Sandboxing AI Agents in Production
How to sandbox Claude Code, Codex, and other AI coding agents for production use. Compare local Docker, Daytona, E2B, and Qovery approaches - with architecture diagrams and real-world examples.
AI agents running on developer laptops are a security liability. Claude Code, Codex, and Cursor have access to SSH keys, API tokens, and production credentials. One runaway task and your blast radius is everything the developer can reach.
Sandbox-only platforms solve half the problem. Tools like Daytona and E2B provide isolated execution environments, but they have no path to production. Code stays in the sandbox forever.
The enterprise answer is sandbox-to-production governance. You need isolated environments with scoped secrets, network isolation, and audit trails - AND a deployment pipeline that takes agent-written code to staging and production.
If your engineering team uses Claude Code, Codex, Cursor, or OpenCode, your AI agents are running with the same permissions as your developers. That means:
Full access to SSH keys and AWS credentials on the developer's machine
Unaudited command execution - no log of what the agent did, accessed, or modified
No network isolation - the agent can reach any API, database, or service the developer can
No cost controls - agents can spin up cloud resources, create databases, or run expensive operations indefinitely
This is not hypothetical. As AI coding agents become autonomous - running for hours on tasks, working on multiple tickets in parallel - the blast radius of an uncontrolled agent grows exponentially.
The 5 Approaches to Sandboxing AI Agents
1. Local Docker Containers (DIY)
The simplest approach: run your AI agent inside a Docker container on the developer's machine.
How it works:
BASH
docker run -it --rm \ -v $(pwd):/workspace \ -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \ node:20 bash# Then run Claude Code inside the container
Pros:
Free, no vendor dependency
Full control over the container image
Works offline
Cons:
Still runs on the developer's machine (their credentials are one volume mount away)
No network isolation (container shares the host network by default)
No audit trail
No scalability - one agent per developer machine
Docker Desktop licensing costs for enterprise teams
Best for: Individual developers experimenting with AI agents.
2. Daytona Sandboxes
Daytona is an open-source sandbox infrastructure platform that provides isolated compute environments for AI agents.
How it works:
PYTHON
from daytona import Daytonadaytona = Daytona()sandbox = daytona.create()response = sandbox.process.exec("claude --task 'Fix the login bug'")
Pros:
Sub-90ms sandbox creation
Dedicated kernel per sandbox (real isolation)
Snapshot/restore for reproducible agent states
SDKs for Python, TypeScript, Go, Java
Cons:
No deployment capability - code stays in the sandbox
Control plane runs on Daytona's infrastructure (not true BYOC)
Basic RBAC (org-level only)
No managed databases, no production infrastructure
Individual sandboxes only - no multi-service environments
Best for: Teams building AI coding agent products (code interpreters, eval platforms).
3. E2B Sandboxes
E2B offers cloud sandboxes optimized for AI agent code execution, with a focus on the code interpreter use case.
How it works:
PYTHON
from e2b_code_interpreter import Sandboxsandbox = Sandbox()execution = sandbox.run_code("print('Hello from sandboxed agent')")
Pros:
Purpose-built for code execution
Good SDK ergonomics
Instant sandbox creation
Cons:
Similar limitations to Daytona: sandbox-only, no deployment
Managed infrastructure only (no BYOC)
Focused on code interpreter use cases, less on full development environments
No enterprise governance features documented
Best for: AI products that need code execution as a feature (chatbots, data analysis tools).
4. Claude Code's Built-in Sandboxing
Claude Code itself supports Docker-based sandboxing and the --sandbox flag for macOS sandbox mode.
How it works:
BASH|macOS sandbox (limited file/network access)
claude --sandbox# Docker-based sandboxclaude --docker
Pros:
Zero setup - built into Claude Code itself
Restricts file system access and network calls
Cons:
macOS sandbox is limited (no Linux support)
Docker mode still runs on the developer's machine
No centralized audit trail
No way for platform teams to enforce sandboxing across the organization
No multi-agent orchestration
Best for: Individual developers who want basic protection while using Claude Code locally.
5. Qovery: Sandbox to Production (Full Lifecycle)
Qovery provides full-stack sandboxed environments for AI agents that run on your own Kubernetes infrastructure, with database seeding, E2E testing, and a governed path from sandbox to production.
How it works:
BASH|Platform team creates a blueprint environment
qovery environment create --name agent-sandbox --blueprint ai-agent# Agent gets an isolated environment with scoped secrets# Network isolation via allowlists# Auto-shutdown on idle# Every action logged and attributed# When code is ready, deploy through the same platformqovery deploy --environment production --service backend
Pros:
Full lifecycle: sandbox -> staging -> production on the same platform
True BYOC: everything runs on your AWS/GCP/Azure account
Use Docker (DIY) if you're an individual developer experimenting with AI agents and want basic isolation with zero cost.
Use Daytona or E2B if you're building an AI product that needs code execution as a feature - code interpreters, eval platforms, data analysis tools. The sandbox is the product.
Use Claude's built-in sandbox if you want quick local protection while coding with Claude and don't need centralized governance.
Use Qovery if your AI agents need to:
Write code that eventually ships to production
Access real databases, APIs, and services - but with scoped permissions
Run on infrastructure you own (BYOC)
Comply with SOC 2, HIPAA, or GDPR requirements
Scale from 1 agent to 100 agents with governance
The fundamental question is: does your agent's code need to go to production? If yes, you need more than a sandbox. You need the full lifecycle - and that's the gap Qovery fills.
Getting Started with Qovery Agent Sandboxes
Install the Qovery CLI: curl -fsSL https://get.qovery.com | bash
Connect your cloud account: Qovery provisions infrastructure on your AWS, GCP, or Azure
Create a blueprint environment: Define what agents get access to (databases, APIs, secrets)
Install the MCP Server: AI agents can now provision and deploy through Qovery
Set policies: Define RBAC rules, cost caps, and network allowlists per agent
Don't run Claude Code on developer laptops with full access to SSH keys and AWS credentials. Instead, use a remote sandboxed environment where the agent has scoped secrets, network isolation, and an audit trail. Qovery provisions these environments on your own cloud (AWS, GCP, Azure) with per-agent RBAC, cost controls, and a deployment pipeline to take agent-written code from sandbox to staging to production.
What is the best way to isolate AI coding agents?
The best approach depends on your use case. For individual experimentation, local Docker containers work. For AI products that need code execution, Daytona or E2B are solid choices. For enterprise teams where agent-written code needs to eventually ship to production - with compliance, audit trails, and multi-service environments - Qovery is the answer. The key distinction is whether your agent's code stays in a sandbox or needs a path to production.
How does Qovery compare to Daytona and E2B for AI agent sandboxes?
Daytona and E2B are purpose-built sandbox platforms. They excel at isolated code execution. But they stop there - no deployment pipeline, no production hosting, no multi-service environments. Qovery covers the full lifecycle: sandbox with scoped secrets and network isolation, then CI/CD to staging, then promotion to production. If your agent's code is just for eval or analysis, use a sandbox tool. If it needs to ship, use Qovery.
Can AI agents access production databases safely?
Yes, with proper governance. Qovery lets you create environments where agents access database replicas or read-only snapshots - not production databases directly. Secrets are scoped per environment, network rules limit what the agent can reach, and every database query is auditable. The agent gets real data to work with, but the blast radius of a mistake is contained.
What is sandbox-to-production governance for AI agents?
It means your agents work in isolated environments with scoped permissions, then deploy through a governed pipeline - staging, code review, approval gates - to production. Every action is logged and attributed to the specific agent and the human who authorized it. Without this governance chain, you have agents writing code that either stays in a sandbox forever or gets deployed with zero oversight. Qovery provides the full chain.
How do I run Claude Code safely in Kubernetes?
Install the Qovery CLI and MCP Server. Create a blueprint environment that defines what Claude Code gets access to - specific databases, APIs, secrets, and network rules. Claude Code runs inside an isolated Kubernetes namespace with enforced resource limits, network policies, and auto-shutdown timers. Every command the agent executes is logged. When the code is ready, it deploys through your standard PR and review pipeline.
Romaric founded Qovery to make Kubernetes accessible to every engineering team. He writes about platform strategy, developer experience, and the future of cloud infrastructure.
Next step
Your agents need infrastructure. Not just a prompt.
Qovery provisions sandboxed, audited runtime environments for every AI agent - from development to production.
