KI-Sandbox: Isolierung, Codeausführung und Kosten

Eine KI-Sandbox (AI sandbox) ist eine isolierte Umgebung, in der ein KI-Agent Code ausführen, Pakete installieren und mit Dateien arbeiten kann. Ihre Aufgabe ist es, einzuschränken, worauf dieser Code zugreifen kann: die Host-Maschine, die Arbeit anderer Benutzer, Anmeldeinformationen und externe Dienste.

Bevor Sie eine Laufzeitumgebung für Ihren Agenten auswählen, prüfen Sie, wie sie Code isoliert, ob sie Ihre Workload unterstützt und was sie während der Ausführung kostet. Dieser Leitfaden erklärt diese Optionen und zeigt einen kleinen Ausführungsablauf mit Lizard SDK.

Was ist eine KI-Sandbox?

In einer Agenten-Anwendung schlägt das Modell eine Aktion vor. Ihre Anwendung entscheidet, wo und wie diese ausgeführt wird. Eine Sandbox stellt den Computer für Aktionen bereit, die Codeausführung erfordern. Das Modell kann dort ein Python-Skript schreiben, ein Repository bearbeiten oder eine Web-App starten.

Der Begriff beschreibt auch Geschäftsprogramme zum Testen von KI-Produkten. Hier bezeichnet er die Laufzeitumgebung, die den Code eines Agenten ausführt.

Die Laufzeitumgebung benötigt mehr als nur einen Ordner für jeden Benutzer. Ein nützliches Design trennt Prozesse und Dateien, begrenzt CPU und Arbeitsspeicher und gibt der Anwendung eine Möglichkeit, die Arbeit zu stoppen. Anmeldeinformationen, Netzwerkzugriff und persistenter Speicher erfordern eigene Regeln.

Ein Agent, der eine hochgeladene CSV-Datei analysiert, sollte diese Datei und genügend Rechenleistung für die Verarbeitung erhalten. Er hat keinen Grund, die Umgebungsvariablen des Webservers oder die Uploads eines anderen Kunden zu lesen.

Wie eine KI-Sandbox funktioniert

Eine typische Anfrage folgt diesem Ablauf:

1. Ihr Backend empfängt eine Aufgabe und bittet das Modell, Code oder Tool-Aufrufe zu generieren.
2. Ihr Backend erstellt eine Sandbox und kopiert die für diese Aufgabe benötigten Dateien hinein.
3. Die Sandbox führt den Code aus. Ihr Backend sammelt stdout, stderr, Dateien und den Exit-Code.
4. Ihr Backend prüft das Ergebnis, bevor es dem Benutzer angezeigt oder an einen anderen Dienst gesendet wird.
5. Ihr Backend speichert die erforderliche Ausgabe und stoppt die Sandbox.

Bewahren Sie den Schlüssel des Modellanbieters und den Sandbox-Verwaltungsschlüssel in Ihrem Backend auf. Wenn Sie generiertem Code einen Verwaltungsschlüssel geben, kann dieser über Ihr Konto weitere Ressourcen anfordern.

Eine Programmiersitzung benötigt möglicherweise dieselbe Sandbox für mehrere Durchläufe. Eine einmalige Berechnung kann für jeden Job eine neue Sandbox verwenden. Entscheiden Sie, wie lange der Zustand erhalten bleiben soll und welchem Benutzer er gehört, bevor Sie die Wiederverwendung implementieren.

Docker, gVisor und Firecracker: Was ändert sich?

Diese Technologien bieten unterschiedliche Isolationsgrenzen. Der Rest des Systems bestimmt weiterhin, auf welche Dateien, Netzwerke und Anmeldeinformationen der Code zugreifen kann.

Docker eignet sich für Workloads mit bekanntem Vertrauensniveau und einem sorgfältig konfigurierten Host. Die Sicherheit hängt von der Ausführung ab. Die Freigabe des Docker-Sockets oder weitreichende Host-Mounts verändern, was die Workload kontrollieren kann. Siehe Dockers Sicherheitsdokumentation.

gVisor fügt eine Userspace-Kernel-Grenze hinzu, was Kompromisse bei der Kompatibilität mit sich bringt. Firecracker verwendet einen kleinen Virtual Machine Monitor und ein begrenztes Gerätemodell. Beide machen den Schutz von Geheimnissen oder die Einschränkung des Zugriffs auf sensible Dienste nicht überflüssig.

Lizard Sandboxes verwenden Firecracker. Ältere Volumes oder Snapshots sowie ein Fallback nach einem fehlgeschlagenen Firecracker-Start können die Container-Laufzeitumgebung nutzen. Prüfen Sie getInfo().runtime, wenn Ihre Anwendung eine MicroVM erfordert. Das folgende Beispiel lehnt jede andere Laufzeitumgebung ab. Siehe die Lizard Sandboxes-Dokumentation.

Was Isolierung schützt und was nicht

Eine Sandbox begrenzt die Auswirkungen der Codeausführung. Ihre Anwendung muss weiterhin entscheiden, welche Aktionen ein Benutzer oder Agent ausführen darf.

Anmeldeinformationen und Netzwerkzugriff

Alles, was Sie in die Sandbox kopieren, steht der Workload unter den von Ihnen vergebenen Berechtigungen zur Verfügung. Vermeiden Sie es, Ihr gesamtes .env, SSH-Verzeichnis oder Cloud-Anmeldeinformationen zu kopieren. Wenn eine Aufgabe eine externe API benötigt, geben Sie ihr kurzlebige Anmeldeinformationen mit engen Berechtigungen oder leiten Sie die Operation über ein Backend-Tool, das jede Anfrage prüft.

Isolierung bedeutet nicht automatisch einen blockierten Internetzugang. Wenn Code ein Geheimnis lesen und ausgehende Anfragen stellen kann, kann er dieses Geheimnis möglicherweise woanders hin senden. Wählen Sie einen Anbieter und eine Konfiguration, die Ihren Anforderungen an ausgehende Netzwerke entsprechen. Gehen Sie nicht davon aus, dass eine Netzwerk-Allowlist existiert, ohne die Kontrollen des Produkts zu prüfen.

Benutzer und gespeicherte Dateien

Weisen Sie jede Sandbox einem authentifizierten Benutzer oder Job zu. Prüfen Sie die Eigentümerschaft bei jeder Anfrage zur Codeausführung, zum Herunterladen einer Datei oder zur Wiedereröffnung einer Sitzung. Eine erratene Sandbox-ID darf keinen Zugriff gewähren.

Halten Sie persistierte Dateien ebenfalls nach Benutzern getrennt. Die Wiederverwendung eines beschreibbaren Arbeitsbereichs über unabhängige Kunden hinweg kann Daten offenlegen, selbst wenn jede Ausführung eine neue virtuelle Maschine erhält.

Zeitlimits und zurückgegebene Ausgaben

Legen Sie ein Ausführungs-Timeout und eine Sandbox-Lebensdauer fest. Ein Timeout im Client kann das Warten beenden, ohne den Remote-Prozess zu stoppen. Bereinigung und ein serverseitiger Ablauf schützen vor verschiedenen Fehlern.

Behandeln Sie zurückgegebene Dateien und Texte als nicht vertrauenswürdige Eingaben. Validieren Sie JSON gegen die von Ihrer Anwendung erwartete Struktur. Maskieren Sie Text beim Rendern und vermeiden Sie es, generiertes HTML auf demselben Ursprung wie Ihr Konto-Dashboard bereitzustellen.

Für Agenten, die interaktive Genehmigungen überspringen, sind diese Kontrollen wichtig, bevor der erste Befehl ausgeführt wird. Unser Claude Code-Berechtigungsleitfaden behandelt diesen Workflow.

Eine Python-Aufgabe in Lizard Sandboxes ausführen

Dieses Beispiel verwendet Node.js als Backend-Controller und Python innerhalb der Sandbox. Es führt eine feste Berechnung aus, damit Sie den Ausführungspfad prüfen können, bevor Sie ein Modell hinzufügen. Es ruft kein LLM auf.

Verwenden Sie Node.js 22 oder neuer, ein Lizard-Projekt und einen Lizard-API-Schlüssel. Setzen Sie LIZARD_API_KEY und LIZARD_PROJECT_ID in Ihrer Backend-Umgebung. Halten Sie beide aus dem Browser-Code fern. Der API-Schlüssel gehört in Ihren Secret-Store.

Installieren Sie den JavaScript-Client:

npm install @lizard-build/sdk@0.1.69

Speichern Sie dies als run-task.mjs:

import { Lizard } from "@lizard-build/sdk";

const project = process.env.LIZARD_PROJECT_ID;
if (!project || !process.env.LIZARD_API_KEY) {
  throw new Error("Set LIZARD_PROJECT_ID and LIZARD_API_KEY");
}

const lizard = new Lizard({ project });
const sandbox = await lizard.create("base", {
  size: "small",
  timeoutMs: 120_000,
});

try {
  const info = await sandbox.getInfo();
  if (info.runtime !== "firecracker") {
    throw new Error("This task requires the Firecracker runtime");
  }

  const script = [
    "import json",
    "values = [12, 8, 5]",
    "print(json.dumps({'total': sum(values)}))",
  ].join("\n");

  await sandbox.fs.write("/tmp/task.py", script);
  const result = await sandbox.process.exec(
    ["python3", "/tmp/task.py"],
    { user: "user", timeoutMs: 30_000 },
  );

  if (result.exitCode !== 0 || result.truncated) {
    throw new Error("Task failed or returned incomplete output");
  }
  if (Buffer.byteLength(result.stdout, "utf8") > 4096) {
    throw new Error("Task output exceeds the application limit");
  }

  const output = JSON.parse(result.stdout);
  if (
    output === null ||
    typeof output !== "object" ||
    Array.isArray(output) ||
    Object.keys(output).length !== 1 ||
    output.total !== 25
  ) {
    throw new Error("Unexpected task output");
  }

  console.log(output);
} finally {
  await sandbox.kill();
}

Führen Sie es von Ihrer Backend-Maschine aus:

node run-task.mjs

Am 17. Oktober 2026 haben wir genau dieses Skript aus einer Sandbox von Lizard mit dem Template codex und Node.js 22.23.2 ausgeführt. Es erstellte eine Small-Firecracker-Sandbox aus dem Template base, führte Python als user aus, gab { total: 25 } aus und schloss die Bereinigung mit dem Exit-Code 0 ab.

Das Lizard SDK liest LIZARD_API_KEY aus der Umgebung des Controllers. Dieser Code gibt es nicht an die Sandbox weiter, die Python ausführt.

Das Argument-Array führt Python ohne Shell-Interpolation aus. Python kann weiterhin alle Operationen ausführen, die die Sandbox zulässt. Das Befehls-Timeout von 30 Sekunden begrenzt die Wartezeit des Clients. Die Sandbox-Lebensdauer von zwei Minuten legt einen separaten Ablauf fest. Der finally-Block fordert eine Bereinigung an, selbst wenn die Ausgabenvalidierung fehlschlägt. Siehe die Lizard SDK-Referenz.

Um dies in ein Agenten-Tool zu verwandeln, ersetzen Sie das feste Skript durch den Code, den Ihr Modell zurückgibt, und definieren Sie ein Ergebnisschema für diese Aufgabe. Behalten Sie Autorisierung, Ressourcenlimits und Ausgabeprüfungen im Backend. Ein erfolgreicher Exit-Code allein beweist nicht, dass die Antwort korrekt ist.

Was können Sie mit einer KI-Sandbox bauen?

Datenanalyse: Verarbeiten Sie einen Benutzer-Upload, führen Sie Python aus und geben Sie ein Diagramm oder ein kleines JSON-Ergebnis zurück. Begrenzen Sie Dateigröße und Ausführungszeit und behalten Sie nur die Ausgabe, die der Benutzer benötigt.

Programmier-Agenten: Checken Sie eine aufgabenspezifische Kopie eines Repositories aus, bearbeiten Sie Dateien und führen Sie Tests aus. Überprüfen Sie das Diff und die Testergebnisse, bevor ein separater Workflow Änderungen zusammenführt oder bereitstellt.

App-Builder: Installieren Sie Abhängigkeiten, starten Sie einen Entwicklungsserver und stellen Sie eine private Vorschau bereit. Halten Sie die Vorschau vom Ursprung und der Authentifizierung Ihres Dashboards getrennt. Unser Leitfaden für App-Builder im Lovable-Stil zeigt den breiteren Anwendungsablauf.

Browser-Agenten: Verwenden Sie eine Laufzeitumgebung mit Browser und Desktop, wenn die Aufgabe UI-Interaktion erfordert. Behandeln Sie jede angemeldete Sitzung als Anmeldeinformation mit Zugriff auf dieses Konto.

Lizard Sandboxes bieten Shell-Befehle, Dateizugriff und private HTTPS-Vorschauen. Browser- und Desktop-Arbeiten verwenden das Template desktop. Eine Entwicklungsvorschau und eine bereitgestellte Anwendung haben unterschiedliche Lebensdauern. Wählen Sie, welche Ihr Benutzer benötigt. Siehe Lizard Sandboxes.

Was kostet eine KI-Sandbox?

Beginnen Sie mit der Gesamtlaufzeit, einschließlich der Zeit zwischen Befehlen. Fügen Sie dann Speicher, Modellaufrufe und alle anderen Dienste hinzu, die Ihre Anwendung nutzt.

Lizard listet diese Rechenraten mit Stand Oktober 17, 2026 auf:

Lizard berechnet die Rechenleistung pro Sekunde, während eine Sandbox läuft, einschließlich Leerlaufzeiten. Lizard Pro kostet $19 pro Monat und beinhaltet $19 an Nutzung. Darüber hinausgehende Nutzung wird als pay as you go abgerechnet. Persistent Volumes kosten $0.14 pro GB pro Monat. Prüfen Sie die aktuellen Preise vor der Budgetierung.

Für 1,000 Small-Jobs, die jeweils eine Sandbox für fünf Minuten ausführen:

1,000 × (5 / 60 hours) × $0.0162 = $1.35 in compute usage

Das ist der Rechenanteil der Workload. Ihre Gesamtrechnung umfasst weiterhin das Pro-Abonnement und jede Nutzung über das Freikontingent hinaus. Modell-Token sind separate Kosten.

Wenn diese Jobs jeweils eine Sandbox für eine zusätzliche Stunde laufen lassen, kommen $16.20 an Rechennutzung hinzu. Eine explizite Lebensdauer und zuverlässige Bereinigung können wichtiger sein als ein kleiner Unterschied bei den Stundensätzen.

Wie man eine KI-Sandbox auswählt

Testen Sie mit dem Job, den Ihre Benutzer ausführen werden. Ein schneller Shell-Befehl sagt wenig über einen Repository-Build oder eine Browser-Sitzung aus.

Erfassen Sie Startzeit, Zeit für die Abhängigkeitsinstallation, Gesamtaufgabenzeit, Fehler und gesamte Laufzeit in Sekunden. Prüfen Sie die langsamsten Anfragen sowie den Median. Unser Vergleich von E2B, Daytona und Modal bietet einen Ausgangspunkt für den Vergleich von Ausführungs-Workflows.

Bevor Sie eine Laufzeitumgebung einführen, beantworten Sie diese Fragen:

• Was trennt den Code und die Dateien eines Kunden von denen eines anderen?
• Welche Geheimnisse und externen Dienste kann generierter Code erreichen?
• Kann die Laufzeitumgebung die Sprachen, Pakete und Browser-Tools ausführen, die die Aufgabe benötigt?
• Was passiert, wenn der Controller abstürzt oder seine Verbindung verliert?
• Welche Dateien überleben das Herunterfahren und wie sichern Sie diese?
• Was kostet die gesamte Workload mit Leerlaufzeit, Speicher und Modellaufrufen?

Beginnen Sie für eine erste Implementierung mit einer Aufgabe, einer temporären Sandbox und einem kleinen validierten Ergebnis. Erstellen Sie Lizard Sandboxes, messen Sie diesen Ablauf und fügen Sie dann Persistenz oder längere Sitzungen hinzu, wenn die Anwendung sie benötigt.