Agent Sandbox aufbauen: Vollständiger Leitfaden für sichere KI-Codeausführung

Im Frühjahr 2025 testeten Sicherheitsforscher alle 16 öffentlichen AI Agents der YCombinator-Spring-Batch. Ergebnis: Sieben wurden kompromittiert. Manche leckten Nutzerdaten, andere erlaubten Remote-Code-Ausführung – einer löschte gleich die gesamte Datenbank.

Das ist der Preis dafür, einem AI Agent Code ausführen zu lassen. Geben Sie ihm Freiheit, und er gräbt Ihnen ein Loch.

Alle nutzen KI zum Schreiben, Ausführen und Verarbeiten von Code und Daten. Aber haben Sie sich gefragt, ob Sie LLM-generierten Code direkt auf dem Server laufen lassen sollten? Was, wenn er rm -rf / ausführt oder heimlich AWS-Schlüssel an einen externen Server schickt?

Dafür gibt es die Agent Sandbox.

Der größte Unterschied zwischen AI Agents und klassischen Anwendungen ist nicht das Gespräch oder das Verstehen von Anweisungen – sondern dass sie selbst Code schreiben und ausführen.

Stellen Sie sich vor: Sie bitten einen Datenanalyse-Agenten, 1 GB Verkaufsdaten zu verarbeiten. Er schreibt Python-Code zum Lesen, Analysieren und Erzeugen von Charts – vollständig vom LLM generiert, von Ihnen nie geprüft. Und dann läuft er.

Dabei drohen mehrere kritische Risiken:

Beliebige Codeausführung. LLMs kennen keine Sicherheitsgrenzen. os.system(), subprocess.run() – sie nutzen, was nötig scheint, ohne Konsequenzen zu bedenken. Ein gezielter Prompt kann beliebige Systembefehle auslösen.

Ressourcenerschöpfung. Agent-Code hat kein Ressoursenbewusstsein. Eine Endlosschleife blockiert die CPU, unendliche Rekursion sprengt den Speicher – Ihr Server fällt aus.

Dateisystem-Eskalation. Ohne Pfadbeschränkungen liest der Code die gesamte Festplatte, schreibt beliebige Dateien – Konfiguration, Schlüssel, Nutzerdaten.

Netzwerk-Exfiltration. Ein versteckter HTTP-Request sendet sensible Daten an einen Angreifer – oft unbemerkt.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

OWASP veröffentlichte 2025 die Top-10-Bedrohungen für AI Agents. Platz eins: Manipulation der Tool-Interaktion – Angreifer nutzen Prompt Injection oder andere Mittel, um Tool-Aufrufe vom vorgesehenen Verhalten abzulenken.

Es gibt bereits reale Fälle:

• Langflow-RCE-Schwachstelle: Horizon3 entdeckte Remote-Code-Ausführung über bösartige Eingaben.
• Cursor-Auto-Ausführung: Forscher fanden, dass Cursor bestimmte MCP-Befehle automatisch ausführt – auslösbar per bösartigem Prompt.
• Replit-Datenbank gelöscht: KI-generierter Code löschte versehentlich die gesamte Datenbank.

Eine Sandbox ist keine Option, sondern Infrastruktur – wie Sie keinen Server ohne Firewall ins Internet stellen, sollten Sie keinen Agent ohne Sandbox Code ausführen lassen.

Der Kernwert einer Sandbox in drei Punkten: Isolation – Risikocode im Käfig; Begrenzung – Limits für CPU, RAM, Netzwerk, Dateizugriff; Audit – protokollieren, was passiert ist, wenn etwas schiefgeht.

Vergleich gängiger Sandbox-Technologien

Welche Technologie? Drei Hauptlinien: Container (Docker), gVisor, Firecracker-Mikro-VMs.

Docker: schnell, aber unsicher genug

Docker ist verbreitet: schneller Start, geringer Overhead, reife Ökosystem. Problem: Container und Host teilen den Kernel.

Prozesse sind per Namespace getrennt – nutzt ein Angreifer aber einen Kernel-Exploit, kann er ausbrechen und Root auf dem Host erlangen.

2024 wurden mehrere Container-Escape-Schwachstellen veröffentlicht. Für nicht vertrauenswürdigen KI-Code reicht Docker nicht.

gVisor: ein „Pseudo-Kernel“ im Userspace

gVisor ist Googles Open-Source-Projekt: statt direkt den Host-Kernel zu nutzen, implementiert es im Userspace einen Pseudo-Kernel (Sentry).

Systemaufrufe werden abgefangen und von Sentry verarbeitet – nur sichere Operationen erlaubt. Schadcode erreicht den echten Kernel nicht.

Vorteil: gute Docker-Kompatibilität, die meisten Images laufen direkt. Nachteil: ca. 10–20 % Performance-Overhead, manche Syscalls nicht unterstützt.

GKE unterstützt gVisor nativ – eine Zeile in der Pod-Konfiguration: runtimeClassName: gvisor.

Firecracker: echte Hardware-Isolation

Firecracker ist AWS’ Open-Source-Mikro-VM-Technik. Jede Sandbox ist eine kleine VM mit eigenem Kernel.

Selbst mit Root und Kernel-Exploit in der Sandbox bleibt der Schaden in der VM – der Host bleibt unberührt.

Start in 100–800 ms, deutlich schlanker als klassische VMs (Minimum ca. 128 MB RAM).

E2B, AWS Bedrock AgentCore und ähnliche Dienste nutzen Firecracker im Unterbau.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Entscheidungsrahmen

1. Nur lokale Entwicklung/Test? Docker reicht – schnell und unkompliziert.
2. Produktion?
   • Mittlere Sicherheit, Performance wichtig → gVisor
   • Hohe Sicherheit, Compliance → Firecracker
3. Kein eigener Betrieb? Managed Services (E2B, Bedrock AgentCore)

Praxis: lokale Dev-Sandbox

Theorie reicht – bauen wir eine: FastAPI + Jupyter Kernel + gVisor-Container.

Warum diese Kombination?

• FastAPI: schlanke HTTP-API, Agent reicht Code per REST ein
• Jupyter Kernel: interaktives Python, Variablen bleiben erhalten
• gVisor-Container: Isolation gegen Schadcode auf dem Host

Schritt 1: FastAPI-Service

main.py anlegen:

# main.py
import asyncio
from contextlib import asynccontextmanager
from fastapi import FastAPI, HTTPException
from jupyter_client.manager import AsyncKernelManager
from pydantic import BaseModel

app = FastAPI()

class CodeRequest(BaseModel):
    code: str

class ExecutionResult(BaseModel):
    output: str

@asynccontextmanager
async def kernel_client():
    """Jupyter-Kernel-Lebenszyklus verwalten"""
    km = AsyncKernelManager(kernel_name="python3")
    await km.start_kernel()
    kc = km.client()
    kc.start_channels()
    await kc.wait_for_ready()
    try:
        yield kc
    finally:
        kc.stop_channels()
        await km.shutdown_kernel()

async def execute_code(code: str, timeout: int = 30) -> str:
    """Code ausführen und Ergebnis zurückgeben"""
    async with kernel_client() as kc:
        msg_id = kc.execute(code)
        try:
            while True:
                reply = await asyncio.wait_for(
                    kc.get_iopub_msg(),
                    timeout=timeout
                )
                if reply["parent_header"]["msg_id"] != msg_id:
                    continue
                msg_type = reply["msg_type"]
                if msg_type == "stream":
                    return reply["content"]["text"]
                elif msg_type == "error":
                    return f"Error: {reply['content']['evalue']}"
                elif msg_type == "status" and reply["content"]["execution_state"] == "idle":
                    break
        except asyncio.TimeoutError:
            return "Error: Execution timed out"
    return ""

@app.post("/execute", response_model=ExecutionResult)
async def execute(request: CodeRequest):
    """Code-Ausführungs-Endpunkt"""
    try:
        output = await execute_code(request.code)
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))
    return ExecutionResult(output=output)

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

Kernlogik: pro Anfrage ein eigener Jupyter-Kernel – ausführen, Ergebnis zurückgeben, Kernel beenden.

Schritt 2: Dockerfile

FROM jupyter/base-notebook:latest

WORKDIR /app

COPY main.py /app/main.py
COPY requirements.txt /app/requirements.txt

RUN pip install --no-cache-dir -r requirements.txt

# Nicht-root-Benutzer (Security Best Practice)
USER jovyan

EXPOSE 8000

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

USER jovyan ist wichtig: bei einem Escape sind die Rechte begrenzt.

Schritt 3: Deployment auf GKE (gVisor)

Auf GKE reicht eine Zeile in der Pod-Konfiguration:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: agent-sandbox
spec:
  template:
    spec:
      runtimeClassName: gvisor  # gVisor aktivieren
      containers:
      - name: sandbox
        image: your-registry/agent-sandbox:latest
        ports:
        - containerPort: 8000
        resources:
          limits:
            memory: "512Mi"
            cpu: "500m"

Damit läuft die Ausführungsumgebung in gVisor.

Schritt 4: zusätzliche Sicherheitslimits

Für Produktion mindestens ergänzen:

# Netzwerkrichtlinie: nur nötige APIs
# Schreibgeschütztes Root-Dateisystem
securityContext:
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false

# Ausführungs-Timeout
# Im FastAPI-Code bereits via timeout-Parameter

Fortgeschritten: Kubernetes-Cluster

Bei großflächigem Agent-Betrieb reicht ein einzelner Container nicht. Dann hilft der Kubernetes Agent Sandbox Controller.

Google open-sourcete 2025 Agent Sandbox – deklarative Sandbox-API.

Sandbox-CRD-Kernkonzepte

• Sandbox: einzelne Instanz mit stabiler Identität, persistentem Storage, Lifecycle
• SandboxTemplate: Standardkonfiguration als Vorlage
• SandboxClaim: Sandbox on demand anfordern

Beispiel:

apiVersion: sandbox.k8s.io/v1alpha1
kind: Sandbox
metadata:
  name: my-agent-sandbox
spec:
  template:
    spec:
      runtimeClassName: gvisor
      containers:
      - name: executor
        image: python:3.11-slim
        command: ["sleep", "infinity"]
      # Persistenter Storage
      volumes:
      - name: workspace
        emptyDir: {}
      # Ressourcenlimits
      resources:
        limits:
          memory: "1Gi"
          cpu: "1"

Lifecycle-Management

Pause und Resume:

# Sandbox pausieren (CPU und meiste RAM freigeben)
kubectl patch sandbox my-agent-sandbox --type=merge -p '{"spec":{"paused":true}}'

# Sandbox fortsetzen
kubectl patch sandbox my-agent-sandbox --type=merge -p '{"spec":{"paused":false}}'

Ideal für intermittierende Agents – ohne Aufgabe fast keine Ressourcen, bei Bedarf Sekunden-Recovery.

Warm Pool

Vorgehaltene, pausierte Sandboxes reduzieren Cold-Start von Sekunden auf Millisekunden.

Managed Services

Ohne eigenen Infrastrukturbetrieb sind Managed Services sinnvoll:

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

E2B: Open Source + Cloud

Speziell für AI-Agent-Code-Sandboxen:

• E2B Cloud: SaaS, nutzungsbasiert
• E2B on AWS: Open Source in Ihrem AWS-Account

Unterbau: Firecracker. SDK ist schlank:

from e2b import Sandbox

# Sandbox erstellen
sandbox = Sandbox()

# Code ausführen
result = sandbox.run_code("print('Hello, World!')")

# Sandbox schließen
sandbox.close()

E2B on AWS passt bei Datenhoheit – alles in Ihrem Account.

AWS Bedrock AgentCore

2025 eingeführt: Code-Ausführung und Browser-Steuerung für Agents.

Code Interpreter: Python/JavaScript/TypeScript, jede Session in eigener Mikro-VM, bis 5 GB Dateien.

Browser Tool: Webseiten öffnen, Formulare, Klicks – für Crawling und SaaS-Automation.

Abrechnung nach tatsächlicher vCPU- und RAM-Nutzung, nicht nach Laufzeit der Instanz.

Auswahl-Empfehlung

Fazit

Kernbotschaft: Sicherheit ist keine Option, sondern Infrastruktur für AI-Agent-Anwendungen.

Technisch:

• Kleine Teams, schnelle Tests: Docker oder gVisor
• Enterprise, hohe Sicherheit: Firecracker oder Managed Service
• Bereits auf Kubernetes: Agent Sandbox Controller

Egal welche Wahl – lokal mit minimalem FastAPI + Docker starten, dann härten und produktiv deployen.

Sandbox so früh wie möglich einplanen. Nach einem Vorfall ist der Aufwand deutlich höher.