Sandboxes, explained

Where AI-generated code runs, how isolation works, and why the files, connections and actions you permit still matter.

5 min read2 October 2026

A sandbox is an isolated environment for running code with controlled access to the surrounding system. It gives software somewhere to execute while limiting which files, connections and other resources it can use. An AI agent, meaning AI that uses tools to carry out a task, can use a sandbox to edit files, run commands and inspect the results.

Why this is timely

On 30 September 2026, Cloudflare announced changes to its Containers platform designed for AI agent workloads, including faster startup, choices made at runtime and filesystem snapshots in public beta. The underlying need is easy to understand. A model can write code as text, but testing that code requires a place to run it. The sandbox is part of that execution infrastructure.

Follow one shop-website task

Our illustrative task asks an AI to change a shop website. The workspace contains the relevant project files and sample orders. It can run tests and show a test-shop preview. A controlled connection permits downloading code libraries from an approved site. Live orders and payment credentials are not provided. Releasing the change is a separate action after review.

This is a proposed configuration, not a default that every product supplies. A local folder called sandbox does not create these restrictions. Software or operating-system controls must enforce them. Anthropic’s sandboxing design, for example, combines restrictions on file access with restrictions on network destinations.

Containers and virtual machines

An ordinary container isolates processes and gives them their own view of files and other resources, while sharing the host’s operating-system kernel. The kernel is the core that manages processes, memory and devices. Sharing it reduces overhead. A virtual machine, or VM, runs its own operating system and kernel, adding another separation boundary and more resource cost. Providers can combine both approaches. Cloudflare describes each of its Containers instances as a microVM with its own kernel.

The label alone cannot tell you whether a configuration is suitable. Docker’s security guidance covers isolation, resource limits and configuration risks. Sharing powerful host access or broad directories can undermine the protection you expected. We would check the actual setup and the consequences of failure before choosing it.

Control the openings

Files. Provide the project files and test data required for the task. Avoid exposing unrelated work or real customer records.
Connections. Restrict which destinations code can reach. Downloading a dependency needs an opening, and that opening can also carry data out.
Actions. A permitted service connection still needs limits on what it may do. Reading a result and making a payment are different permissions.

A key or token is a credential that permits access to a service. One pattern keeps the real credential outside the workspace. Code sends a request to an external access check, which allows a specific operation and uses the credential itself. The sandbox receives the result. This narrows access, but any permitted operation can still be misused.

A workspace needs a lifecycle

A separate workspace per task or user helps keep unrelated work apart. A snapshot is a saved copy of workspace files that lets work resume later. It can also preserve secrets accidentally left in those files. Stopping compute, deleting an environment and deleting every saved copy are different operations. Check the provider’s retention and cleanup behaviour rather than assuming that closing a session removes its data.

Review what comes out

Isolation does not establish that the code is correct. Inspect the changed files, run meaningful tests and decide whether the result meets the task. A preview also runs code in the viewer’s browser. Cloudflare recommends a separate hostname for previews so that they cannot use the main application’s cookies and access in the same way.

Our view is to make the permitted work useful and the boundary explicit. Grant only what the task needs, keep release authority separate, and check the result. That lets a sandbox contain more of the consequences of a mistake without treating it as a guarantee.