Sandboxing für KI-Agenten: Least Privilege konsequent umgesetzt

Ein Agent, der nur Text erzeugt, kann peinlich werden. Ein Agent, der Werkzeuge ausführt, kann Schaden anrichten: Dateien überschreiben, Nachrichten verschicken, Datensätze löschen, interne Systeme abfragen. Dabei gibt es zwei Fehlerquellen, und beide sind real. Der Agent kann fehlgeleitet sein, weil er eine Aufgabe falsch versteht oder ein Tool-Ergebnis falsch interpretiert. Und er kann manipuliert sein, weil eine Prompt Injection in einem verarbeiteten Dokument, einer E-Mail oder einer Webseite ihm fremde Anweisungen unterschiebt.

Keine der beiden Fehlerquellen lässt sich vollständig ausschließen. Prompts härten und Eingaben filtern hilft, aber es bleibt eine Wahrscheinlichkeitsrechnung. Die verlässliche Verteidigung setzt deshalb eine Ebene tiefer an: beim Sandboxing und beim Prinzip Least Privilege. Die Frage ist nicht, ob der Agent irgendwann etwas Falsches versucht, sondern wie viel Schaden dieser Versuch maximal anrichten kann. Diese Obergrenze bestimmt die Architektur, nicht der Prompt.

Ausführungs-Sandboxes: Container und VMs

Sobald ein Agent Code ausführt, etwa selbst geschriebene Skripte oder Shell-Kommandos, gehört diese Ausführung niemals in den Prozess der eigenen Anwendung. Sie gehört in eine Sandbox mit klar gezogener Grenze.

Container sind dafür der pragmatische Standard: schnell gestartet, gut automatisierbar, ressourcenbeschränkbar. Für viele Anwendungsfälle reichen sie aus, solange man ihre Grenze kennt: Container teilen sich den Kernel mit dem Host. Wo generierter oder fremder Code läuft, der gezielt bösartig sein könnte, ist die stärkere Grenze einer virtuellen Maschine oder einer Micro-VM angemessen. Die Abwägung ist klassisch: Startzeit und Betriebsaufwand gegen Isolationsstärke.

Unabhängig von der Technologie gilt das Wegwerf-Prinzip. Jeder Lauf bekommt eine frische Umgebung, die danach verworfen wird. Keine persistenten Zustände, die sich über Läufe hinweg ansammeln, keine Umgebung, in der ein früherer Lauf einem späteren etwas hinterlassen kann. Ressourcenlimits für Rechenzeit, Speicher und Plattenplatz gehören dazu, damit ein außer Kontrolle geratenes Skript nicht die Nachbarn beeinträchtigt.

Berechtigungen pro Tool statt Sammel-API-Key

Der häufigste Fehler in Agenten-Setups ist ein einzelner, mächtiger API-Key in der Umgebung des Agenten, der alles kann: lesen, schreiben, löschen, über alle Systeme hinweg. Sobald eine Prompt Injection durchkommt, steht ihr damit alles offen, was dem Key offensteht. Der Schaden wird nicht durch die Raffinesse des Angriffs bestimmt, sondern durch die Breite des Schlüssels.

Die Alternative ist Kleinarbeit, aber sie lohnt sich: Jedes Tool bekommt eigene, minimale Zugangsdaten. Das Such-Tool darf lesen, und nur lesen. Das Ticket-Tool darf Tickets anlegen, aber keine löschen. Die Zugangsdaten leben im Tool selbst, serverseitig gekapselt, und tauchen nie im Kontext des Modells auf. Der Agent ruft eine Funktion auf, er besitzt keinen Schlüssel.

Dazu kommen zwei Verfeinerungen. Erstens die Trennung von Lese- und Schreibpfaden: Ein Agent, der für eine Aufgabe nur lesen muss, bekommt für diesen Lauf auch nur die Lese-Tools eingeblendet. Zweitens die Bestätigungspflicht für destruktive Operationen: Löschen, Überweisen, Versenden an Externe laufen über eine explizite Freigabe, durch einen Menschen oder durch eine strenge, deterministische Policy. Zeitlich begrenzte Berechtigungen, die nur für die Dauer eines Laufs gelten, runden das Bild ab.

Netzwerk- und Dateisystem-Isolation

Die Sandbox begrenzt, was der Agent ausführen kann. Netzwerk- und Dateisystemregeln begrenzen, wohin er dabei greifen kann. Beim Netzwerk hat sich eine einfache Grundhaltung bewährt: standardmäßig alles verweigern. Die Agentenumgebung erreicht nur die Endpunkte, die ihre Tools tatsächlich brauchen, und sonst nichts. Damit wird der gefürchtete Datenabfluss, bei dem ein manipulierter Agent interne Informationen an einen fremden Server schickt, von einer offenen Tür zu einem kontrollierten und überwachbaren Pfad.

Beim Dateisystem gilt dasselbe Muster: ein eigenes Arbeitsverzeichnis pro Lauf, kein Zugriff auf Konfigurationsdateien, Zugangsdaten oder Daten anderer Mandanten. Was der Agent nur lesen muss, wird schreibgeschützt eingebunden. Besondere Aufmerksamkeit verdienen Umgebungsvariablen und eingebundene Geheimnisse, denn sie sind das erste Ziel, wenn generierter Code die eigene Umgebung erkundet.

Allowlists statt Blocklists

Bei der Frage, welche Kommandos, Domains oder Pfade ein Agent nutzen darf, verlieren Blocklists auf Dauer immer. Es gibt mehr gefährliche Varianten, als sich aufzählen lassen, und Modelle sind erstaunlich einfallsreich darin, ein gesperrtes Kommando durch ein gleichwertiges ungesperrtes zu ersetzen. Jede Blocklist ist eine Einladung zur Umgehung.

Allowlists drehen die Beweislast um: Erlaubt ist, was explizit freigegeben wurde, alles andere scheitert. Das gilt für ausführbare Kommandos in der Sandbox, für erreichbare Domains, für Dateipfade und, wo möglich, für die Wertebereiche von Tool-Argumenten. Der Preis ist Pflegeaufwand: Freigaben brauchen eine dokumentierte Begründung und eine regelmäßige Durchsicht, sonst wächst die Liste schleichend, bis sie keine Grenze mehr ist. Dieser Aufwand ist der laufende Betriebspreis von Least Privilege, und er ist deutlich niedriger als der Preis eines einzigen ernsten Vorfalls.

Audit-Trail: jede Aktion nachvollziehbar

Die letzte Schicht ist die Nachvollziehbarkeit. Jede ausgeführte Aktion wird protokolliert: welches Tool, mit welchen Argumenten, mit welchem Ergebnis, in welchem Lauf, ausgelöst durch welche Eingabe. Dieses Protokoll ist nur anfügbar und liegt außerhalb der Reichweite des Agenten, denn ein Agent, der sein eigenes Protokoll verändern könnte, hätte im Ernstfall genau das als erstes Ziel.

Der Audit-Trail hat drei Aufgaben. Er ermöglicht Forensik nach einem Vorfall: Was genau ist passiert, ab welchem Schritt, mit welchen Daten. Er schafft Nachweisbarkeit gegenüber Kunden und Prüfern, die zunehmend wissen wollen, was autonome Systeme im eigenen Haus tun dürfen und getan haben. Und er ist die Datenbasis, um Berechtigungen weiter zu verengen: Rechte, die über Monate nie genutzt wurden, sind Kandidaten für den Entzug. Least Privilege ist kein Zustand, sondern ein Prozess, und der Audit-Trail ist sein Messinstrument.

Fazit

Sandboxing für KI-Agenten ist kein einzelner Schalter, sondern ein Schichtenmodell: Ausführung in wegwerfbaren Containern oder VMs, minimale Zugangsdaten pro Tool statt eines Sammel-Keys, Netzwerk und Dateisystem standardmäßig geschlossen, Allowlists statt Blocklists und ein unveränderliches Protokoll über jede Aktion. Keine dieser Schichten verhindert, dass ein Agent etwas Falsches versucht. Zusammen sorgen sie dafür, dass aus dem Versuch kein Vorfall wird. Wer Agenten mit echten Werkzeugen betreibt, sollte diese Architektur nicht als Ausbaustufe betrachten, sondern als Voraussetzung für den ersten produktiven Lauf.