How to Run Untrusted Code Safely

Fly.io's guide to running untrusted code argues that code written by an AI agent, or submitted by a user, needs two boundaries that an ordinary container does not supply. A container gives a program its own view of files and processes, but every container on a machine shares the host's kernel, the core of the operating system that controls memory, devices and permissions. A flaw in that shared kernel can let code escape the container and reach the host. The post points to NIST's container security guide (SP 800-190), which ranks container escapes among the most critical threats, and to MITRE ATT&CK, which catalogs the technique as T1611. Its first requirement is therefore hardware isolation: the code runs inside a virtual machine with a kernel of its own instead of the one everything else on the machine depends on.

The second boundary is the network. Code that cannot touch your files can still send data to an attacker's server, download further malicious programs, take instructions from a remote controller or simply spend your computing budget. The post says outbound connections should be blocked unless explicitly allowed, and that the rules should be enforced from outside the sandbox so the code cannot loosen them. In its example, a deny-all policy is set through the Sprites API: DNS lookups are refused, direct connections to IP addresses are blocked, and the post says even code with root access inside cannot change the policy. A narrower version allows only the OpenAI and Anthropic API domains. Vercel's description of its own sandbox makes the same case that isolation without control over outgoing traffic leaves an exit open, and it names a reachable DNS resolver as one path that can let code out of an otherwise disconnected environment.

The rest of the post is a tutorial for Sprites, Fly.io's own sandbox product. It adds two more requirements, rollback and support for many programming languages, and shows Sprites meeting them: a damaged Sprite can be destroyed and replaced, or restored from a checkpoint in about a second by the post's account, and common language runtimes come preinstalled. Sprites also sleep when idle, so the post says a code runner costs nothing between jobs. The post presents these as product features and offers no escape tests or measurements, and it does not explain how Sprites implement hardware isolation. Its useful contribution is the checklist itself: a separate kernel, and network rules the code cannot rewrite, are the two questions to ask of any sandbox, from Fly.io or anyone else.