· Graham Brooks · 8 min read

Sandboxing AI Coding Agents: Why Isolation Matters

Contents

The more context and tools an AI coding agent has access to, the better it performs. But more power means more risk. How do we harness the full capability of AI coding assistants while keeping our systems safe?

AI coding agents like Claude Code, Codex, GitHub Copilot and Gemini CLI are remarkably capable — they can read your codebase, run commands, install packages, and modify files across your project. To be most useful, you want to give them broad access. To maintain flow you want the agent to run to completion without continuously interrupting and asking for permission for every action or confirming that it can use use something safely in the future. But every tool you grant is a tool that can misfire.

AI Coding Agent — Unsandboxed Access«Person»DeveloperGrants broad permissions to stay inflow«System»AI Coding AgentClaude Code / Codex / Gemini CLI«System»Project CodebaseSource code, configs, secrets«External System»Package Registrynpm, PyPI, crates.io«External System»External APIsCloud services, SaaS endpoints«External System»Host SystemSSH keys, credentials, otherprojectsPromptsReads / writes filesInstalls packagesMakes API callsHas access toAI Coding Agent — Unsandboxed Access
AI Coding Agent — Unsandboxed Access«Person»DeveloperGrants broad permissions to stay inflow«System»AI Coding AgentClaude Code / Codex / Gemini CLI«System»Project CodebaseSource code, configs, secrets«External System»Package Registrynpm, PyPI, crates.io«External System»External APIsCloud services, SaaS endpoints«External System»Host SystemSSH keys, credentials, otherprojectsPromptsReads / writes filesInstalls packagesMakes API callsHas access toAI Coding Agent — Unsandboxed Access

Most agents offer confirmation prompts before running commands, but in practice developers disable these to stay in flow. The result is an agent with wide access running with minimal oversight. This isn’t hypothetical — in February 2026, the Cline VS Code extension ( with over 5 million users) was compromised through a prompt injection chain that exfiltrated npm release tokens and led to an unauthorized package being published.

Real-world incident: The Cline VS Code extension compromise in February 2026 demonstrated that prompt injection attacks against AI coding agents are not theoretical — they can lead to supply chain compromise at scale.

The industry has noticed. Sandbox session volumes on platforms like E2B grew from 40,000 per month to roughly 15 million per month in a single year. Docker launched experimental sandbox support specifically for AI agent workflows. The message is clear: isolation isn’t optional.

  • Data leaks — An agent with access to your codebase and credentials can exfiltrate sensitive information if compromised. This includes API keys, database credentials, and proprietary code.
  • Malicious actions — A compromised agent could run destructive commands, install malware, or modify code in harmful ways. Even without malicious intent, a bug in the agent’s reasoning could lead to unintended consequences.
  • Supply chain attacks — If an agent can install packages, it could be tricked into installing a malicious package from a registry, leading to a supply chain compromise.
  • Reputation damage — A security incident involving an AI agent could damage your reputation, especially if it leads to a data breach or compromised customer data.
  • User Error — Starting the agent in a directory outside of the project, or with elevated permissions, could lead to unintended consequences. Even well-intentioned users can make mistakes that lead to security incidents.
AttackerAttack VectorPrompt InjectionModel VulnerabilitiesDependency PoisoningMisconfigurationAgent executes\nunintendedcommandsMalicious package\ninstalledCredentials or\nhost accessexposedImpactData exfiltrationSupply chain\ncompromiseHost system\ncompromised
AttackerAttack VectorPrompt InjectionModel VulnerabilitiesDependency PoisoningMisconfigurationAgent executes\nunintendedcommandsMalicious package\ninstalledCredentials or\nhost accessexposedImpactData exfiltrationSupply chain\ncompromiseHost system\ncompromised
  • Prompt injection — Attackers can craft inputs that manipulate the agent’s behavior, causing it to execute unintended commands or leak information.
  • Model vulnerabilities — Flaws in the underlying AI model could be exploited to bypass security controls or cause erratic behavior.
  • Third-party dependencies — If the agent relies on external APIs or packages, vulnerabilities in those dependencies could be exploited to compromise the agent.
  • Misconfiguration — Incorrectly configured permissions, network access, or resource limits can create openings for attackers to exploit.

There are broadly two approaches to sandboxing AI agents.

Remote sandboxes run your project code and the AI agent on a remote server. Services like E2B, GitHub Codespaces, and various cloud development environments provide this model. The agent never touches your local machine, which provides strong isolation. The trade-off is latency, cost, and dependency on external infrastructure.

Local sandboxes use containers or virtual machines on your own machine. The agent runs in an isolated environment with access only to what you explicitly mount. Your SSH keys, cloud credentials, and other projects remain invisible. If something goes wrong, the blast radius is limited to that container.

Remote SandboxLocal SandboxContainerCloud ServerProject Code CopyAI AgentYour MachineMounted Project CodeAI AgentDeveloper
Remote SandboxLocal SandboxContainerCloud ServerProject Code CopyAI AgentYour MachineMounted Project CodeAI AgentDeveloper

For most individual developers, local containerized isolation hits the sweet spot — fast, free, and under your control.

The devcontainer specification provides a standardized way to define containerized development environments. You describe your toolchain in a devcontainer.json file, and your IDE or CLI tool builds and runs the container. AI coding agents with terminal interfaces — Claude Code, Codex CLI, Gemini CLI — can run inside these containers directly.

In theory, this is straightforward. In practice, the setup quickly becomes complex. Authentication (API keys, git credentials, SSH keys) needs to be forwarded or mounted securely. Network access needs to be scoped — the agent needs to reach package registries and AI APIs but shouldn’t have unrestricted internet access. Configuration varies per agent, per project, and per team.

What we actually need is:

  • Seamless agent integration — pre-configured support for multiple AI coding agents within the container
  • Security profiles — granular control over network access, Linux capabilities, and resource limits
  • IDE compatibility — the ability to edit code and interact with agents from your normal editor
  • Multi-project support — shared configuration that doesn’t require copy-pasting between repositories
  • Simple upgrades — easy adoption of new tools and agent versions without rebuilding from scratch

This is exactly the problem I set out to solve with devc, an open-source CLI tool for creating AI-safe development containers.

devc extends the devcontainer specification with security-focused features. It provides three built-in security profiles — strict, moderate, and permissive — that control network access, Linux capabilities, and resource limits. The strict profile eliminates all network connectivity and caps resources at 2 CPUs and 4 GB of memory, giving you a tightly constrained sandbox. The permissive profile opens things up for workflows that need broader access.

devc — Sandboxed AI Agent Architecture«Person»DeveloperInitializes and manages containersvia devc CLI«System»devc CLICreates and manages AI-safe devcontainers«System»Dev ContainerIsolated environment with securityprofile applied«System»AI AgentClaude / Codex / Gemini /Opencode«System»Project CodeMounted read/write into container«External System»Package RegistryAllowed via network allowlist«External System»AI APIAllowed via network allowlistdevc init / up / attachCreates with security profileRuns insideReads / writesScoped network accessScoped network accessdevc — Sandboxed AI Agent Architecture
devc — Sandboxed AI Agent Architecture«Person»DeveloperInitializes and manages containersvia devc CLI«System»devc CLICreates and manages AI-safe devcontainers«System»Dev ContainerIsolated environment with securityprofile applied«System»AI AgentClaude / Codex / Gemini /Opencode«System»Project CodeMounted read/write into container«External System»Package RegistryAllowed via network allowlist«External System»AI APIAllowed via network allowlistdevc init / up / attachCreates with security profileRuns insideReads / writesScoped network accessScoped network accessdevc — Sandboxed AI Agent Architecture
Getting started is three commands: devc init --agent claude — initialize the project with Claude Code support and a security profile. devc up — build and start the container. devc attach — open a shell session inside the container.

The tool communicates directly with container runtimes (Docker, Podman, Colima) via the Docker Engine API rather than shelling out to CLI binaries, which makes it more reliable and portable. It includes session tracking to prevent accidental container stops while agents are active, and containers persist between uses so you don’t lose state.

StrictModeratePermissiveNo network access2 CPUs / 4 GB RAMMinimal capabilitiesNetwork allowlist4 CPUs / 8 GB RAMStandard capabilitiesFull network accessNo resource capsExtended capabilitiesMore trust\nneededFull trust
StrictModeratePermissiveNo network access2 CPUs / 4 GB RAMMinimal capabilitiesNetwork allowlist4 CPUs / 8 GB RAMStandard capabilitiesFull network accessNo resource capsExtended capabilitiesMore trust\nneededFull trust

Choose the profile that matches your threat model. Working on a sensitive codebase with credentials in the environment? Start with strict. Prototyping a new side project? Permissive gets you moving fast with the option to tighten later.

Multi-agent support is built in — Claude, Codex, Gemini, and Opencode are all pre-configured. Configuration lives in .devcontainer/devcontainer.json under customizations.devc, so it’s compatible with the broader devcontainer ecosystem while adding the isolation controls that AI agent workflows demand.

The landscape for AI coding agents is moving fast. As agents become more autonomous — planning multi-step tasks, installing dependencies, running tests, deploying code — the case for isolation only gets stronger. The goal isn’t to limit what agents can do, but to create environments where they can do more with less risk.

More Agent\nAutonomyGreater Need\nfor IsolationSandboxed\nEnvironmentsAgents Can Do\nMore Safely
More Agent\nAutonomyGreater Need\nfor IsolationSandboxed\nEnvironmentsAgents Can Do\nMore Safely

If you’re using AI coding agents in your workflow, I’d encourage you to think about your isolation story. Whether it’s devc, a cloud sandbox, or your own container setup, the cost of sandboxing is low and the cost of not sandboxing is growing every month.

devc is on GitHub — contributions and feedback welcome.