Sandboxing¶

Some coding agents allow you to set permissions within them, for example, automatically, using a whitelist or within a sandbox. However, these permissions remain vulnerable to the Lethal Trifecta if your coding agent has access to private data, is exposed to untrusted content and can communicate externally.

In such cases, we define our own sandbox so that the agents’ code runs in isolated environments with restricted file system access, controlled network connectivity and limited resource usage.

As coding agents are increasingly able to autonomously execute code, perform builds and interact with the file system, unrestricted access to a development environment poses real risks, ranging as far as the disclosure of login credentials. Sandboxing should therefore be standard practice, rather than merely an optional extension.

There is now a wide range of sandboxing options available. In addition to the coding agents’ built-in sandbox modes, there are various options spanning the spectrum between short-lived and permanent solutions:

Sprites
Sprites is a stateful sandbox environment from Fly.io, developed using Firecracker microVMs for the isolated execution of coding agents.

Whilst most sandboxes are short-lived – they are launched for a single task and then disappear again – Sprites provides persistent Linux environments with unlimited checkpointing and rollback capabilities. This enables development teams to take a snapshot of the entire environment state – including installed dependencies, runtime configuration and changes to the file system – and perform a rollback if an agent goes off the rails. This goes beyond what Git alone can restore, as it captures the system state that version control does not track.

Development Containers
Development Containers provide a standardised method for defining reproducible, containerised development environments using the devcontainer.json configuration file.

Originally developed to provide teams with consistent development environments, dev containers have found a compelling new use case as isolated execution environments for coding agents. Running an agent in a dev container isolates it from the host’s file system, credentials and network, allowing teams to grant the agent extensive permissions without compromising the host machine.

The open specification is natively supported by VS Code and VS Code-based tools such as Cursor.

DevPod
extends Dev Container support via SSH to any editor or terminal workflow. Dev Containers follow an ephemeral-by-default approach, meaning that the container is recreated from the configuration each time it is started, which provides a clean security boundary, albeit at the cost of having to reinstall tools and dependencies.

In addition to basic isolation, development teams should take into account the practical requirements for a productive sandbox. These include all the components required for development and testing, as well as secure and straightforward authentication with external services. Development teams require port forwarding as well as sufficient CPU and memory resources to handle the workloads of the coding agents. Whether the sandbox should be ephemeral by default or persistent to allow for session recovery is a design decision that depends on the team’s priorities regarding security, cost and the continuity of workflows.