SANDBOXING AND ISOLATION FOR SAFETY

A WORKED EXAMPLE OF A SANDBOX DESIGN Imagine a coding agent that writes and runs small programs to analyze a user's data file. The harness copies the file into a fresh container that has no network access and no other files. The container runs as an ordinary user, with limits of two hundred and fifty-six megabytes of memory and thirty seconds of processing time. The agent's code runs inside, and only the printed output and a small results file are copied back out, after the harness checks their size and type. When the run ends, the container is destroyed, and the log keeps a record of what was run. If the code tries to reach the internet, the attempt fails and is logged. If the code loops forever, the time limit stops it. If the code tries to read other users' files, there are none to read. Each safeguard covers a different failure, and together they provide depth. WHY SANDBOXES ARE NOT A COMPLETE ANSWER A sandbox limits damage but does not make the contents of a run trustworthy. Output that comes out of a sandbox can still be wrong, misleading, or carry hidden instructions, so it should be treated as untrusted text. Sandboxes can also contain flaws, and researchers regularly find ways out of isolation layers. Keep the software up to date, combine the sandbox with permissions and monitoring, and never rely on a single wall.