Agenten-Sandboxing: KI sicher Code ausführen lassen 2026

Wenn der Agent plötzlich Code ausführt

Ein KI-Agent, der nur Text zurückgibt, ist harmlos. Ein KI-Agent, der Rechnungen aus einer Datenbank zieht, ein Python-Skript schreibt und es ausführt, um eine Umsatzprognose zu rechnen, ist etwas anderes. Er handelt. Und mit dem Handeln kommt das Risiko: Was passiert, wenn das Modell ein Skript erzeugt, das rekursiv Ihr Dateisystem durchläuft, eine interne API mit Anfragen flutet oder einen Secret-Token in einen Log-Eintrag schreibt?

2026 verlassen agentische Systeme die Demo-Phase. Sie rufen Werkzeuge auf, führen generierten Code aus, bewegen sich durch Dateisysteme und sprechen mit internen Diensten. Genau das macht sie nützlich — und gefährlich. Die Frage ist nicht mehr, ob ein Unternehmen Agenten Werkzeuge in die Hand gibt, sondern wie es verhindert, dass diese Werkzeuge Schaden anrichten. Sandboxing ist die Antwort, über die zu selten gesprochen wird.

Warum Guardrails am Modell nicht reichen

Viele Teams glauben, sie hätten das Problem im Griff, weil sie Eingaben filtern und Ausgaben prüfen. Das ist der Schutz am Modell. Er fängt den Prompt ab, der nach Löschbefehlen klingt, und blockiert offensichtlich bösartige Antworten. Doch er sieht nicht, was passiert, nachdem der Agent ein Werkzeug aufruft.

Der entscheidende Punkt: Ein Agent muss gar nicht böswillig sein, um Schaden anzurichten. Ein Modell, das eine Datei bereinigen soll, kann versehentlich den falschen Ordner erwischen. Ein Skript, das eine CSV einlesen soll, kann in eine Endlosschleife laufen und den gesamten Arbeitsspeicher belegen. Prompt-Injection verschärft das Ganze: Eine manipulierte PDF im Posteingang kann den Agenten anweisen, Daten an eine externe Adresse zu schicken — und der Agent folgt der Anweisung, weil sie im Dokument steht, das er brav verarbeitet.

Sicherheit am Modell und Sicherheit bei der Ausführung sind zwei verschiedene Ebenen. Die erste prüft Absichten, die zweite begrenzt Konsequenzen. Wer nur die erste baut, verlässt sich darauf, dass das Modell nie einen Fehler macht. Das ist keine Strategie, das ist Hoffnung.

Was Sandboxing konkret bedeutet

Eine Sandbox ist eine abgeschottete Umgebung, in der der Agent seinen Code ausführt, ohne das Hostsystem zu berühren. Fällt etwas kaputt, fällt nur die Sandbox kaputt. Sie wird verworfen, eine neue startet. Der Host bleibt unberührt.

In der Praxis staffeln sich die Verfahren nach Isolationsgrad. Container wie Docker trennen Prozesse und Dateisysteme und reichen für viele interne Fälle — allerdings teilen sie den Kernel mit dem Host, was ein Restrisiko lässt. MicroVMs wie Firecracker oder gVisor ziehen eine härtere Grenze: Sie geben jedem Ausführungslauf eine eigene, minimale virtuelle Maschine, die in Millisekunden startet. WebAssembly-Laufzeiten gehen noch einen Schritt weiter und sperren den Code in eine Umgebung, die von sich aus weder Dateien noch Netzwerk kennt, solange man es nicht ausdrücklich erlaubt.

Die Wahl hängt vom Bedrohungsmodell ab. Ein Agent, der nur mit vertrauenswürdigen internen Daten rechnet, braucht weniger Härte als einer, der Inhalte aus dem offenen Netz oder aus Kundenuploads verarbeitet. Die Faustregel: Je weniger Sie dem Input vertrauen, desto stärker muss die Isolation sein.

Netzwerk, Dateisystem, Ressourcen — die drei Schrauben

Drei Dinge entscheiden, ob eine Sandbox wirklich schützt. Erstens das Netzwerk: Standardmäßig sollte eine Sandbox keinen Zugang nach außen haben. Braucht der Agent eine bestimmte API, wird genau diese Adresse freigegeben, sonst nichts. So verhindern Sie, dass abgegriffene Daten das Haus verlassen.

Zweitens das Dateisystem. Der Agent bekommt ein eigenes, leeres Verzeichnis und sieht vom Rest der Maschine nichts. Keine SSH-Schlüssel, keine Konfigurationsdateien, keine Zugangsdaten anderer Dienste. Was er zum Arbeiten braucht, wird hineinkopiert; was er produziert, wird kontrolliert herausgeholt.

Drittens die Ressourcen. Ohne Grenzen kann ein einziger fehlgeleiteter Lauf eine ganze Maschine lahmlegen. Deshalb gehören feste Obergrenzen für CPU, Arbeitsspeicher und Laufzeit dazu. Ein Skript, das nach dreißig Sekunden nicht fertig ist, wird abgebrochen. Ein Prozess, der zu viel Speicher fordert, wird gestoppt. Diese Grenzen sind nicht nur Sicherheit, sie sind auch Kostenkontrolle.

Rechte vergeben wie einem neuen Mitarbeiter

Ein hilfreiches Bild: Behandeln Sie den Agenten wie einen Praktikanten am ersten Tag. Sie geben ihm nicht die Admin-Zugänge für alles, nur weil er vielleicht irgendwann etwas davon braucht. Sie geben ihm genau die Rechte, die seine Aufgabe erfordert — und erweitern sie, wenn sich Vertrauen aufgebaut hat.

Für Agenten heißt das: feingranulare Berechtigungen pro Werkzeug. Der Agent, der Rechnungen liest, darf lesen, aber nicht schreiben. Der Agent, der einen Report in ein Verzeichnis legt, darf dorthin schreiben, aber nirgendwo sonst. Jedes Werkzeug bekommt seinen eigenen, minimalen Zugriff. Dieses Prinzip der geringsten Rechte klingt nach Mehraufwand, zahlt sich aber beim ersten Zwischenfall aus — weil der Schaden dann auf das begrenzt bleibt, was dieses eine Werkzeug durfte.

Besonders heikel sind Werkzeuge, die schreiben, löschen oder Geld bewegen. Hier lohnt sich eine menschliche Freigabe im Ablauf: Der Agent bereitet die Überweisung vor, ein Mensch bestätigt sie. Für Agenten, die in Produktion mit echten Konsequenzen laufen, ist dieser Zwischenschritt kein Hindernis, sondern eine Versicherung.

Selbst gehostet heißt: Sie kontrollieren die Sandbox

Hier zahlt sich eine eigene Infrastruktur doppelt aus. Wer Agenten über einen externen Dienst laufen lässt, muss darauf vertrauen, dass dessen Sandbox hält und dass sensible Daten den fremden Server nie dauerhaft erreichen. Wer selbst hostet, legt die Isolationsschicht selbst fest, protokolliert jeden Werkzeugaufruf im eigenen Haus und entscheidet, welche internen Systeme überhaupt erreichbar sind.

Das passt zu einem Thema, das viele Unternehmen 2026 beschäftigt: Datensouveränität. Ein Agent, der auf Patientenakten, Konstruktionsdaten oder Vertragsunterlagen zugreift, sollte diese Daten nicht durch eine Sandbox schicken, die jemand anderes betreibt. Die Werkzeuge dafür sind reif und quelloffen verfügbar — von gVisor über Firecracker bis zu WebAssembly-Laufzeiten lässt sich eine belastbare Ausführungsschicht auf eigener Hardware aufbauen.

Wichtig bleibt die Protokollierung. Jeder Werkzeugaufruf, jedes ausgeführte Skript, jeder Netzwerkzugriff gehört aufgezeichnet. Nicht nur für die Fehlersuche, sondern auch, um nach einem Vorfall rekonstruieren zu können, was der Agent getan hat. Ein Agent ohne Audit-Spur ist eine Blackbox — und Blackboxen gehören nicht in regulierte Prozesse.

Der pragmatische Einstieg

Niemand muss am ersten Tag eine perfekte MicroVM-Architektur bauen. Der sinnvolle Weg beginnt kleiner: Isolieren Sie die Codeausführung in Containern, kappen Sie den Netzwerkzugang bis auf das Nötigste, setzen Sie harte Ressourcengrenzen und vergeben Sie Werkzeugrechte sparsam. Das deckt den Großteil der alltäglichen Risiken ab.

Wer dann Agenten auf weniger vertrauenswürdige Eingaben loslässt — Kundendokumente, Web-Inhalte, fremde Dateien —, härtet die Isolation nach und ergänzt menschliche Freigaben für kritische Aktionen. So wächst die Sicherheit mit dem Einsatz, statt ihn auszubremsen. Agentische KI wird sich durchsetzen, weil sie Arbeit abnimmt. Aber nur die Unternehmen, die ihren Agenten eine sichere Bühne bauen, werden sie ruhigen Gewissens in Produktion laufen lassen.

Sie möchten agentische KI auf eigener Infrastruktur sicher aufsetzen — mit sauberer Isolation, feingranularen Rechten und voller Kontrolle über Ihre Daten? Bei AI-Designers begleiten wir Unternehmen von der ersten Architektur bis zum produktiven Betrieb. Sprechen Sie uns an.

Bilder: AI-Designed