What you learn
- Why running AI-generated or untrusted code locally is genuinely risky
- What a sandbox is and how E2B and Daytona provide disposable environments
- The three situations where you must sandbox: user-submitted code, untrusted agent output, parallel experiments
Summary
An agent that can write code is also an agent that wants to run it, and the moment you let arbitrary code execute on your laptop or server, one bad line can delete files, leak secrets from your environment, or open a connection you did not intend. A sandbox solves this by giving the code a fresh, isolated, throwaway computer to run on. If the run goes wrong, you discard the sandbox and lose nothing. This lesson explains the risk honestly, defines what a sandbox is, introduces the main services, and gives you a clear rule for when to use one and when a local run is fine.
What you will learn
You will learn why executing AI-generated code on your own machine is a security and reliability hazard, what a sandbox actually provides (isolation, disposability, resource limits), how managed services like E2B and Daytona spin one up on demand for your agent, and the three concrete situations that always call for a sandbox. You will leave able to decide, per task, whether code can run locally or must be contained.
Prerequisites
Courses 1 to 3, especially the secrets and security material from Course 3. You should understand that your machine holds environment variables, SSH keys and logged-in sessions that any local process can read, because that is precisely what a sandbox protects. The API basics matter too, since you drive these services through their SDKs.
An API is a way for two programs to talk to each other. Learn what an API is, how it works, and why it matters for building with AI.
A .env file stores secrets like API keys outside your code so they never get published. Learn what it is, how it works and how to keep it safe.
The terminal is a text window where you type commands to control your computer. Learn the handful of commands you actually need to get started.
The problem
Agentic workflows generate code and then need to run it to see if it works, transform some data, or fulfil a request. The temptation is to just run it - and for code you wrote and reviewed, that is fine. But agent output is not always correct, and if any input came from a user or the open web, it is not always friendly either. A single rm command, an infinite loop that pins your CPU, a script that reads process.env and phones it home: these are not exotic, they are the default failure modes of running untrusted code with full access to your real system.
Comments
Loading comments.
Post a comment