22. March 2026
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.
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.
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]
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:
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")
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.