Sandboxed Code Execution for Agents

A data scientist wants to say "analyze this CSV and create visualizations" and have an agent write and actually run Python code to do it. That is enormously useful, and also, described plainly, a little terrifying: an LLM generating code that then executes with real system access could delete files, exfiltrate data, or run arbitrary commands, whether through a genuine mistake or a maliciously crafted input designed to trick it into doing so.

The fix is not trying to make the model itself perfectly trustworthy. It is running whatever code the model generates inside an isolated environment that cannot cause real damage even if the code is malicious: no network access, strictly limited memory and CPU, and only a whitelisted set of safe packages available. This is precisely the same sandboxing concept behind this course's own runnable code blocks, applied to agent-generated code instead of pre-written examples.

Generated code rarely works on the very first try, and that is fine by design: generate code, execute it in the sandbox, and if it fails, feed the actual error message back to the model as new context and let it generate a fix. Most real tasks succeed within two or three attempts this way. The loop needs its own cap too, the same lesson as ReAct's max_iterations, since an agent that never gives up trying to fix broken code burns tokens exactly as unboundedly as one that never stops researching.