Sandboxes: sichere Code-Ausführung mit E2B, Daytona und Co.

Überblick

Ein Agent, der Code schreiben kann, ist auch ein Agent, der ihn ausführen will, und in dem Moment, in dem du beliebigen Code auf deinem Laptop oder Server ausführen lässt, kann eine schlechte Zeile Dateien löschen, Secrets aus deiner Umgebung leaken oder eine Verbindung öffnen, die du nicht beabsichtigt hast. Eine Sandbox löst das, indem sie dem Code einen frischen, isolierten, wegwerfbaren Computer zum Laufen gibt. Geht der Lauf schief, wirfst du die Sandbox weg und verlierst nichts. Diese Lektion erklärt das Risiko ehrlich, definiert, was eine Sandbox ist, stellt die wichtigsten Dienste vor und gibt dir eine klare Regel dafür, wann du eine nutzt und wann ein lokaler Lauf in Ordnung ist.

Was du lernst

Du lernst, warum es ein Security- und Zuverlässigkeitsrisiko ist, KI-generierten Code auf deiner eigenen Maschine auszuführen, was eine Sandbox tatsächlich bietet (Isolation, Wegwerfbarkeit, Ressourcenlimits), wie verwaltete Dienste wie E2B und Daytona eine auf Abruf für deinen Agent hochfahren, und die drei konkreten Situationen, die immer nach einer Sandbox verlangen. Du gehst hinaus und kannst pro Aufgabe entscheiden, ob Code lokal laufen kann oder eingesperrt werden muss.

Voraussetzungen

Kurse 1 bis 3, besonders das Secrets- und Security-Material aus Kurs 3. Du solltest verstehen, dass deine Maschine Umgebungsvariablen, SSH-Keys und eingeloggte Sessions hält, die jeder lokale Prozess lesen kann, denn genau das schützt eine Sandbox. Die API-Grundlagen zählen auch, da du diese Dienste über ihre SDKs steuerst.

Das Problem

Agentische Workflows generieren Code und müssen ihn dann ausführen, um zu sehen, ob er funktioniert, um Daten zu transformieren oder eine Anfrage zu erfüllen. Die Versuchung ist, ihn einfach laufen zu lassen - und für Code, den du geschrieben und geprüft hast, ist das in Ordnung. Aber Agent-Output ist nicht immer korrekt, und wenn irgendein Input von einem Nutzer oder dem offenen Web kam, ist er nicht immer freundlich. Ein einziges rm-Kommando, eine Endlosschleife, die deine CPU lahmlegt, ein Skript, das process.env liest und nach Hause telefoniert: das sind keine exotischen Fälle, das sind die Standard-Fehlermodi, wenn man nicht vertrauenswürdigen Code mit vollem Zugriff auf dein echtes System ausführt.

Was eine Sandbox eigentlich ist

Eine Sandbox ist eine isolierte, wegwerfbare Ausführungsumgebung - in der Praxis eine leichtgewichtige virtuelle Maschine oder ein gehärteter Container -, die keinen Zugriff auf dein echtes Dateisystem, deine Secrets oder dein Netzwerk hat, ausser dem, was du ausdrücklich erlaubst. Code läuft darin mit seinem eigenen Dateisystem, seinen eigenen Speicher- und CPU-Limits und einem harten Zeitbudget. Wenn der Lauf fertig ist, reisst du die Sandbox ab und nichts bleibt bestehen. Das mentale Modell ist ein Reinraum: Der Code bekommt genau die Inputs, die du ihm gibst, und erzeugt genau die Outputs, die du einsammelst, und er kann nichts ausserhalb des Raums erreichen.

• Isolation: der Code kann dein Host-Dateisystem, Umgebungsvariablen oder andere Prozesse nicht sehen.
• Wegwerfbarkeit: jeder Lauf ist eine frische Umgebung; eine kompromittierte oder kaputte Sandbox wird einfach zerstört.
• Ressourcenlimits: CPU, Speicher und Wanduhrzeit sind gedeckelt, sodass eine ausser Kontrolle geratene Schleife deine Maschine nicht lahmlegen kann.
• Kontrolliertes I/O: du entscheidest, welche Dateien hineingehen und was herauskommt; der Netzwerkzugriff kann eingeschränkt oder verweigert werden.

E2B, Daytona und Freunde

Du baust Sandboxes nicht selbst - du rufst einen Dienst auf, der sie über ein SDK in unter einer Sekunde hochfährt. E2B ist speziell dafür gebaut, dass KI-Agents Code ausführen: du erstellst eine Sandbox, führst Code oder Shell-Kommandos darin aus, liest den Output und beendest sie, alles aus ein paar Zeilen in deiner App. Daytona bietet schnelle, ephemere Entwicklungsumgebungen im selben Geist, nützlich, wenn ein Agent einen volleren Workspace statt einer einzelnen Ausführung braucht. Beide abstrahieren die VM- und Container-Klempnerei weg, sodass dein Agent einen sicheren Ort bekommt, um Code auf Abruf auszuführen. Das Muster unten ist, wie fast jede Integration aussieht.

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

// Eine frische, isolierte Sandbox nur für diesen Lauf hochfahren
const sandbox = await Sandbox.create()

try {
  // Agent-generierten Code laufen lassen, wo er dir nicht schaden kann
  const execution = await sandbox.runCode(agentGeneratedPython)
  console.log(execution.logs.stdout)
  console.log(execution.error) // eingesperrt: ein Fehler hier ist nicht dein Problem
} finally {
  // Immer abreissen - nichts bleibt bestehen
  await sandbox.kill()
}

Produktdetails und SDK-Namen ändern sich in diesem Feld schnell, also behandle das Snippet als die Form des Musters und bestätige die aktuellen Methodennamen gegen die offiziellen E2B- und Daytona-Docs, bevor du baust. Das Konzept - erstellen, ausführen, einsammeln, zerstören - ist stabil, auch wenn sich die APIs bewegen.

Wann du tatsächlich eine Sandbox brauchst

Nicht jeder Code-Lauf braucht Isolation, und Über-Sandboxing fügt Latenz und Kosten hinzu. Die Regel ist einfach: sandboxe immer dann, wenn der Code oder seine Inputs nicht voll vertrauenswürdig sind, und lauf lokal, wenn sie es sind. Drei Situationen überschreiten diese Linie immer.

• Vom Nutzer eingereichter Code: alles, was ein Produkt Nutzer schreiben und ausführen lässt (ein "führe dieses Snippet aus"-Feature, ein Datentransformations-Feld, eine Formel-Engine), muss gesandboxt werden. Du führst fremden Code auf deiner Infrastruktur aus.
• Nicht vertrauenswürdiger Agent-Output: wenn ein Agent Code aus nicht vertrauenswürdigem Input generiert (eine gescrapte Seite, eine Nutzeranfrage, ein Drittanbieter-Dokument) und du ihn ausführst, ohne jede Zeile zu lesen, sperr ihn ein. Der Agent ist nur so sicher wie der schlimmste Input, den er gesehen hat.
• Parallele Experimente: wenn du viele Varianten auf einmal laufen lassen willst - ein generiertes Skript gegen zehn Datensätze testen, eine Idee fuzzen, mehrere Agents Lösungen probieren lassen - geben dir Sandboxes saubere, isolierte, parallele Umgebungen, die sich nicht gegenseitig oder deinen Host stören können.
• Wann lokal in Ordnung ist: Code, den du geschrieben oder voll geprüft hast, gegen vertrauenswürdige Inputs ausgeführt, auf einer Maschine, deren Secrets du kontrollierst. Zahl dafür nicht die Sandbox-Steuer.

Typische Fehler

Die gefährlichen: agent-generierten Code lokal "nur dieses eine Mal" ausführen und einen API-Key aus deiner Umgebung leaken; ein Produkt-Feature bauen, das Nutzer-Input ohne Isolation ausführt, was eine Lehrbuch-Remote-Code-Execution-Schwachstelle ist; vergessen, CPU-, Speicher- und Zeitlimits zu setzen, sodass ein ausser Kontrolle geratener Lauf dir trotzdem schadet; und Sandboxes am Leben lassen, statt sie abzureissen, was Geld verschwendet und die Wegwerfbarkeit aushebelt. Der entgegengesetzte Fehler existiert auch: trivialen, vertrauenswürdigen Code zu sandboxen und dich ohne Sicherheitsgewinn auszubremsen.

Business-ROI

Sandboxing ist der Unterschied zwischen einem agentischen Feature, das du sicher vor Nutzer stellen kannst, und einer Haftung, die du nicht ausliefern kannst. Ein einziger eingesperrter Vorfall - ein feindlicher Input, der einen Server gelöscht hätte, der jetzt nur eine wegwerfbare Sandbox zerstört - bezahlt die ganze Praxis. Für Produkte, die Nutzer- oder Agent-Code ausführen, sind Sandboxes kein optionaler Feinschliff; sie sind die Kontrolle, die dir erlaubt, das Feature überhaupt anzubieten. Und für internes Experimentieren lassen günstige parallele Sandboxes ein kleines Team zehn Ideen in der Zeit probieren, die es bräuchte, um eine sorgfältig zu fahren.

Checkliste

Du bist bereit weiterzugehen, wenn jedes davon sitzt, denn die nächste Lektion lässt dich Tools bauen, die generierten Code ausführen können.

• In einem Satz erklären, warum nicht vertrauenswürdigen Code lokal auszuführen riskant ist.
• Die vier Eigenschaften einer Sandbox definieren (Isolation, Wegwerfbarkeit, Limits, kontrolliertes I/O).
• Das Erstellen-Ausführen-Einsammeln-Zerstören-Muster mit einem Dienst wie E2B beschreiben.
• Die drei Situationen nennen, die immer eine Sandbox verlangen, und eine, die es nicht tut.

Ressourcen

Halt die E2B- und Daytona-Docs als Lesezeichen, da sich ihre SDKs entwickeln und die aktuellen Methodennamen zählen, wenn du baust. Das Security-Material aus Kurs 3 zu Secrets und Umgebungsvariablen ist hier das Fundament - eine Sandbox hilft nur, wenn du auch echte Secrets aus dem Code heraushältst, den du ihr gibst. Im Zweifel, ob du sandboxen sollst, setze auf Ja für alles, was Nutzer- oder Drittanbieter-Input berührt.

Deine Aufgabe

Melde dich bei E2B an (es hat ein kostenloses Kontingent), dann schreib ein winziges Skript, das eine Sandbox hochfährt, ein paar Zeilen generiertes Python darin laufen lässt, den Output ausgibt und sie abreisst. Lass bewusst eine Zeile laufen, die auf deiner echten Maschine destruktiv wäre (etwa eine Mülldatei schreiben), und bestätige, dass sie eingesperrt bleibt. Dieser praktische Beweis ist, was Sandboxing von einer abstrakten Idee in eine Gewohnheit verwandelt.

Nächste Lektion

Mit sicherer Ausführung abgedeckt bist du bereit, echte Tools auf Modell-APIs zu bauen. Die nächste Lektion zeigt wie, anhand zweier Gründer-Fallstudien: ein Rechnungszuordnungs-Tool und ein Schweizer Sammelkarten-Katalogisierer, die ein Foto in einen Datenbank-Datensatz verwandeln.