Python Sandbox Escape Prevention — ELI5

Imagine a playground with a tall fence around it. Kids can play freely inside, but they can’t run into the parking lot or the street. The fence keeps them safe by keeping them contained.

A sandbox in programming works the same way. When you run someone else’s code — a student’s homework submission, a plugin from a stranger, or a script uploaded by a user — you want to put it inside a virtual fence. The code can do things inside the sandbox, but it shouldn’t be able to read your files, delete your data, or take over your computer.

The problem with Python is that the fence has a lot of hidden holes. Python was designed to be flexible and powerful, which means there are many clever ways to reach outside the sandbox. Even if you block the obvious exits (like the ability to open files or run system commands), Python’s internal wiring lets creative people find back doors through things like special object properties and hidden modules.

It’s like building a fence but forgetting that kids can climb trees that hang over it, dig under it, or convince someone on the other side to open the gate.

Because of this, security experts say that pure-Python sandboxing is basically impossible. The real solutions use the operating system itself as the fence — running the untrusted code in a separate container, a virtual machine, or a locked-down process where the operating system enforces the boundaries, not Python.

Services like Google Colab, Replit, and online coding judges all face this problem. They don’t try to sandbox Python within Python — they run each user’s code in an isolated environment that the operating system or hypervisor controls.

The one thing to remember: Python is too flexible to fence in by itself — real sandboxing requires external walls built by the operating system, not by Python code.