---
title: "Sandboxes: Safe Code Execution with E2B, Daytona and Co."
description: "Run agent-generated and untrusted code safely in isolated, disposable sandboxes instead of on your own machine"
type: "lesson"
locale: "en"
course: "Automation and Agentic Systems"
number: "4.3"
canonical: "https://agenticschool.dev/courses/automation-agentic-systems/sandboxes-safe-code-execution-with-e2b-daytona-and-co"
datePublished: "2026-06-12"
dateModified: "2026-06-12"
---

# Sandboxes: Safe Code Execution with E2B, Daytona and Co.

- Course: Automation and Agentic Systems
- Lesson: 4.3
- Duration: 24 min
- Level: fortgeschritten
- Status: published
- Canonical URL: https://agenticschool.dev/courses/automation-agentic-systems/sandboxes-safe-code-execution-with-e2b-daytona-and-co
- Locale: en

> Run agent-generated and untrusted code safely in isolated, disposable sandboxes instead of on your own machine

## Summary

Letting an agent run arbitrary code on your machine is a real risk, not a hypothetical one. A sandbox gives the code an isolated, disposable environment so a bad or hostile run cannot touch your system or data. This lesson explains why sandboxing matters, what a sandbox actually is, how E2B and Daytona work, and exactly when you need one.

## 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.

## 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.

## What a sandbox actually is

A sandbox is an isolated, disposable execution environment - in practice a lightweight virtual machine or a hardened container - that has no access to your real filesystem, your secrets, or your network except what you explicitly allow. Code runs inside it with its own filesystem, its own memory and CPU limits, and a hard time budget. When the run finishes, you tear the sandbox down and nothing persists. The mental model is a clean-room: the code gets exactly the inputs you hand it and produces exactly the outputs you collect, and it cannot reach anything outside the room.

- Isolation: the code cannot see your host filesystem, environment variables or other processes.
- Disposability: each run is a fresh environment; a compromised or broken sandbox is simply destroyed.
- Resource limits: CPU, memory and wall-clock time are capped, so a runaway loop cannot take down your machine.
- Controlled I/O: you decide what files go in and what comes out; network access can be restricted or denied.

## E2B, Daytona and friends

You do not build sandboxes yourself - you call a service that spins them up in under a second through an SDK. E2B is purpose-built for AI agents executing code: you create a sandbox, run code or shell commands inside it, read the output, and kill it, all from a few lines in your app. Daytona offers fast, ephemeral development environments in a similar spirit, useful when an agent needs a fuller workspace rather than a single execution. Both abstract away the VM and container plumbing so your agent gets a safe place to run code on demand. The pattern below is what almost every integration looks like.

```typescript
import { Sandbox } from '@e2b/code-interpreter'

// Spin up a fresh, isolated sandbox for this run only
const sandbox = await Sandbox.create()

try {
  // Run agent-generated code where it can do no harm to you
  const execution = await sandbox.runCode(agentGeneratedPython)
  console.log(execution.logs.stdout)
  console.log(execution.error) // contained: an error here is not your problem
} finally {
  // Always tear it down - nothing persists
  await sandbox.kill()
}
```
The core sandbox pattern: create, run untrusted code inside, collect output, destroy. The exact SDK surface evolves, so check the current E2B docs.

Product details and SDK names change quickly in this space, so treat the snippet as the shape of the pattern and confirm the current method names against the official E2B and Daytona docs before you build. The concept - create, execute, collect, destroy - is stable even as the APIs move.

## When you actually need a sandbox

Not every code run needs isolation, and over-sandboxing adds latency and cost. The rule is simple: sandbox whenever the code or its inputs are not fully trusted, and run locally when they are. Three situations always cross that line.

- User-submitted code: anything a product lets users write and run (a "run this snippet" feature, a data-transformation field, a formula engine) must be sandboxed. You are executing strangers code on your infrastructure.
- Untrusted agent output: when an agent generates code from untrusted input (a scraped page, a user request, a third-party document) and you run it without reading every line, contain it. The agent is only as safe as the worst input it saw.
- Parallel experiments: when you want to run many variations at once - test a generated script against ten datasets, fuzz an idea, let several agents try solutions - sandboxes give you clean, isolated, parallel environments that cannot interfere with each other or your host.
- When local is fine: code you wrote or fully reviewed, run against trusted inputs, on a machine whose secrets you control. Do not pay the sandbox tax for that.

## Typical mistakes

The dangerous ones: running agent-generated code locally "just this once" and leaking an API key from your environment; building a product feature that executes user input with no isolation, which is a textbook remote-code-execution vulnerability; forgetting to set CPU, memory and time limits so a runaway run still hurts you; and leaving sandboxes alive instead of tearing them down, which wastes money and defeats disposability. The opposite mistake also exists: sandboxing trivial, trusted code and slowing yourself down for no security gain.

## Business ROI

Sandboxing is the difference between an agentic feature you can safely put in front of users and a liability you cannot ship. A single contained incident - a hostile input that would have wiped a server, now just destroying a throwaway sandbox - pays for the whole practice. For products that run user or agent code, sandboxes are not optional polish; they are the control that lets you offer the feature at all. And for internal experimentation, cheap parallel sandboxes let a small team try ten ideas in the time it would take to carefully run one.

## Checklist

You are ready to move on when each of these is solid, because the next lesson has you building tools that may run generated code.

- Explain in one sentence why running untrusted code locally is risky.
- Define the four properties of a sandbox (isolation, disposability, limits, controlled I/O).
- Describe the create-run-collect-destroy pattern with a service like E2B.
- Name the three situations that always require a sandbox and one that does not.

## Resources

Keep the E2B and Daytona docs bookmarked, since their SDKs evolve and the current method names matter when you build. The security material from Course 3 on secrets and environment variables is the foundation here - a sandbox only helps if you also keep real secrets out of the code you hand it. When in doubt about whether to sandbox, default to yes for anything touching user or third-party input.

## Your task

Sign up for E2B (it has a free tier), then write a tiny script that spins up a sandbox, runs a few lines of generated Python inside it, prints the output, and tears it down. Deliberately run a line that would be destructive on your real machine (like writing a junk file) and confirm it stays contained. That hands-on proof is what turns sandboxing from an abstract idea into a habit.

## Next lesson

With safe execution covered, you are ready to build real tools on top of model APIs. The next lesson shows how, using two founder case studies: an invoice-assignment tool and a Swiss trading-cards cataloguer that turn a photo into a database record.

## Transcript

This lesson is a written, text-first guide. Letting an agent run arbitrary code on your machine is a real risk, not a hypothetical one. A sandbox gives the code an isolated, disposable environment so a bad or hostile run cannot touch your system or data. This lesson explains why sandboxing matters, what a sandbox actually is, how E2B and Daytona work, and exactly when you need one. You will run agent-generated and untrusted code safely in isolated, disposable sandboxes instead of on your own machine. Work through the sections in order, try the task at the end in a real project, and move on once it works for you. There is no video required - everything you need is in the written steps above.