An AI agent that writes and executes its own code is only as safe as the environment in which that code runs. In a tutorial published by Machine Learning Mastery, the author shows how to isolate this code across three levels: a limited subprocess, a hardened Docker container, and a Firecracker microVM, then compares their security and latency.
The subprocess is the lightest level: it is a child process with limited compute time, memory, and file size, but it shares the kernel and files of the host machine. A container adds namespaces and control groups (cgroups), but remains a set of processes on the host kernel. The article recalls that in November 2025, three vulnerabilities in the runc runtime engine allowed attackers to escape containers. A microVM, on the other hand, gives each environment its own kernel, behind a hypervisor, the software that runs virtual machines.
The setup relies on a single tool, run_python, made available to the agent. Each piece of code produced by the model goes through a ‘sandbox’ object with a run(code) method, so that changing the isolation level does not modify the agent. The tutorial requires Python 3.10 or newer, a Linux or WSL system for the subprocess level, Docker for the container, and an account and an E2B API key for the microVM. An Anthropic API key is useful for the agent but can be avoided for testing.
Six identical attacks against each level
To compare the three levels, the same six hostile programs are executed: an infinite loop, a 512 MB memory allocation, a 200-process ‘fork flood’, writing a 50 MB file, reading a fake credentials file, and connecting to a fake internal service. An attack is considered blocked when the token word does not appear in the output, or, for the infinite loop, when execution times out.
At the subprocess level, executed with a standard Linux user, four attacks are blocked and two succeed. The process limit only applies to a dedicated user, so the fork flood is allowed, and the fake credentials file remains readable because the code runs under the user’s identity. The author concludes that this level is best suited for trusted code.
For the Docker container, the author states that, with the chosen options, Docker should block all six attacks, since the container has no network, its filesystem does not contain the user’s files, and memory, process, and disk limits apply. In a microVM, attacks on memory, processes, and disk can reach the limits of the virtual machine, but they remain confined to it, and the secret file and local service do not exist there.
Latency and level selection
The subprocess should be the fastest, as it only launches Python. For the other two levels, the author specifies that the published figures are claims, not guarantees: a cited article indicates that E2B starts in about 150 ms, while AWS and Docker describe near-instant launches for their microVM products. The bench.py script allows measuring, on one’s own machine, the median and longest time over ten executions of a print(1) program.
The author recommends reserving the subprocess for trusted code, such as personal development scripts, and the hardened container for cases where the host is controlled and the stakes are low, while ensuring runc is kept up to date. The microVM is essential for code from multiple users, for anything involving secrets, and when the agent must build and execute containers itself, which traditional containers handle poorly, according to Docker. Docker launched its microVM-based Docker Sandboxes in April 2026, and AWS offers Lambda MicroVMs that retain their state for up to 8 hours and suspend when inactive. According to Docker, files, network rules, and secrets must be defined by the infrastructure, not by the agent, before its execution.
