Sandboxing AI Coding Agents: Why Isolation Matters

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.

C4Context
    title AI Coding Agent — Unsandboxed Access
    Person(dev, "Developer", "Grants broad permissions to stay in flow")
    System(agent, "AI Coding Agent", "Claude Code / Codex / Gemini CLI")
    System(project, "Project Codebase", "Source code, configs, secrets")
    System_Ext(registry, "Package Registry", "npm, PyPI, crates.io")
    System_Ext(apis, "External APIs", "Cloud services, SaaS endpoints")
    System_Ext(host, "Host System", "SSH keys, credentials, other projects")
    Rel(dev, agent, "Prompts")
    Rel(agent, project, "Reads / writes files")
    Rel(agent, registry, "Installs packages")
    Rel(agent, apis, "Makes API calls")
    Rel(agent, host, "Has access to")

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.
flowchart LR
    A[Attacker] --> B{Attack Vector}
    B --> C[Prompt Injection]
    B --> D[Model Vulnerabilities]
    B --> E[Dependency Poisoning]
    B --> F[Misconfiguration]
    C --> G[Agent executes\nunintended commands]
    D --> G
    E --> H[Malicious package\ninstalled]
    F --> I[Credentials or\nhost access exposed]
    G --> J((Impact))
    H --> J
    I --> J
    J --> K[Data exfiltration]
    J --> L[Supply chain\ncompromise]
    J --> M[Host 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.

flowchart TB
    subgraph Remote["Remote Sandbox"]
        direction TB
        R1[Cloud Server]
        R2[Project Code Copy]
        R3[AI Agent]
        R1 --> R2
        R1 --> R3
    end
    subgraph Local["Local Sandbox"]
        direction TB
        L1[Your Machine]
        subgraph Container["Container"]
            L2[Mounted Project Code]
            L3[AI Agent]
        end
        L1 --> Container
    end
    Dev[Developer] --> Remote
    Dev --> Local

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.

C4Context
    title devc — Sandboxed AI Agent Architecture
    Person(dev, "Developer", "Initializes and manages containers via devc CLI")
    System(devc, "devc CLI", "Creates and manages AI-safe dev containers")
    System(container, "Dev Container", "Isolated environment with security profile applied")
    System(agent, "AI Agent", "Claude / Codex / Gemini / Opencode")
    System(project, "Project Code", "Mounted read/write into container")
    System_Ext(registry, "Package Registry", "Allowed via network allowlist")
    System_Ext(aiapi, "AI API", "Allowed via network allowlist")
    Rel(dev, devc, "devc init / up / attach")
    Rel(devc, container, "Creates with security profile")
    Rel(container, agent, "Runs inside")
    Rel(agent, project, "Reads / writes")
    Rel(container, registry, "Scoped network access")
    Rel(container, aiapi, "Scoped network access")
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.

flowchart LR
    subgraph Strict["Strict"]
        S1[No network access]
        S2[2 CPUs / 4 GB RAM]
        S3[Minimal capabilities]
    end
    subgraph Moderate["Moderate"]
        M1[Network allowlist]
        M2[4 CPUs / 8 GB RAM]
        M3[Standard capabilities]
    end
    subgraph Permissive["Permissive"]
        P1[Full network access]
        P2[No resource caps]
        P3[Extended capabilities]
    end

    Strict -- "More trust\nneeded" --> Moderate -- "Full trust" --> Permissive

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.

flowchart LR
    A[More Agent\nAutonomy] --> B[Greater Need\nfor Isolation]
    B --> C[Sandboxed\nEnvironments]
    C --> D[Agents Can Do\nMore Safely]
    D --> A

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.