Sandboxing and execution isolation: limiting the blast radius
Assume your coding agent will eventually run something it shouldn't. The job of sandboxing is to make sure that when it does, nothing outside the box notices.
This is the third post in our series on securing AI coding agents, and it builds on the first two. If you're just landing here, read those first: what the security risks of AI coding agents actually are, which frames the problem as the lethal trifecta, and network egress control, the discipline this one sits next to. For the whole framework across all four disciplines, plus a maturity self-assessment, download The Agentic AI Security Maturity Guide.
Egress control decides whether data can leave. Sandboxing decides how far a compromise can reach before it hits the exit. It is the second control, and it starts from a different assumption: the agent will sometimes run something it should not. Design for that. Sandboxing an AI agent means running its execution inside a containment boundary strong enough that when the bad thing happens, it stops at the edge of the box instead of reaching the host, the credentials, or the network.
For an agent that reads untrusted content and runs shell commands, this is not hardening. It is the control that decides whether one poisoned input becomes a contained incident or a host compromise.
Shared-kernel containers are not a boundary
Most teams reach for a standard container and call it done. Containers are a fine default for trusted workloads. An AI coding agent running attacker-influenced code is not a trusted workload, and containers share the host kernel. A container escape puts the attacker on the host, and the escape is not hypothetical.
For adversarial workloads, use isolation that does not share the host kernel. Firecracker microVMs, Kata Containers, or gVisor. That is the difference between a speed bump and a wall.
What execution isolation requires
Kernel-level isolation is the foundation. Three controls sit on top of it.
- Restrict filesystem writes to the workspace. The agent writes to its working directory and nowhere else. Writes outside the workspace, especially to configuration files, are a persistence vector. A compromised agent that can edit a config file survives past the current session. Close that path.
- Provision short-lived, scoped secrets per task. Do not mount long-lived credentials into the agent environment. Issue secrets scoped to the task that expire fast. If the sandbox is breached, the attacker gets a nearly worthless credential instead of a standing key to production.
- Treat the default as the risk. Most coding agents ship sandboxing opt-in. As of mid 2026, only OpenAI's Codex enables it by default. In most environments the isolation is available and switched off. The single highest-return move is often flipping that default on, then hardening it.
Sandboxing caps the consequences
Egress control removes a leg of the lethal trifecta. Sandboxing does something complementary. It caps what happens when the legs do converge. Access to private data becomes access to a small set of short-lived secrets. Arbitrary execution becomes arbitrary execution inside a box with no path to the host. The OWASP Agentic Top 10 now treats sandboxing as a required control for exactly this reason, and the Agentic AI Security Maturity Guide maps every discipline to a leg of the trifecta.
The honest part: strong isolation is infrastructure work, not a toggle. You map what each agent actually needs, provision per-task credentials, and build the isolation layer so the developer experience does not degrade. Done well, engineers barely notice it. Done as a memo telling people to turn sandboxing on, it gets ignored. You do not need a perfect model. You need a perfect cage.
Frequently asked questions
What does sandboxing an AI agent mean? Running the agent's execution inside an isolation boundary strong enough that a compromise cannot reach the host, the credentials, or the wider network. It assumes the agent will sometimes execute something malicious and contains the result.
Are containers enough to sandbox an AI coding agent? Usually not. Standard containers share the host kernel, and container escapes have been demonstrated against agent execution. For adversarial workloads, use kernel-level isolation such as Firecracker, Kata, or gVisor.
Are AI coding agents sandboxed by default? Mostly not. Sandboxing is typically opt-in. As of mid 2026, only OpenAI's Codex ships with it enabled by default, so in most environments isolation is available and switched off.
Why restrict filesystem writes outside the workspace? Writes to configuration files outside the working directory are a persistence vector. A compromised agent that can modify config survives past the current session, so writes should be limited to the workspace.
Where to start
Confirm whether your agents are actually sandboxed today, not whether sandboxing is available. If it is off, turning it on is the fastest high-return move. Then harden it: kernel-level isolation for adversarial workloads, workspace-only writes, per-task secrets.
Sandboxing is one of four disciplines that close the agent security gap, alongside network egress control, architectural trust boundaries, and observability and composition. For the full framework and a maturity self-assessment, download The Agentic AI Security Maturity Guide.
