KI-Agenten sicher ausführen: Die Sandbox allein reicht nicht

Eine Sandbox ist die notwendige Ausführungsgrenze für nicht vertrauenswürdigen Code, aber keine vollständige Sicherheitsarchitektur für KI-Agenten. Sie begrenzt lokale Datei- und Prozesszugriffe; Berechtigungen gegenüber APIs, mögliche Datenabflüsse und schädliche Werkzeugaufrufe müssen andere Kontrollen stoppen.

Die Mindestkonfiguration besteht deshalb aus einer kurzlebigen isolierten Laufzeit, einer eng begrenzten Identität, standardmäßig gesperrten Verbindungen, einer Positivliste für Werkzeuge, risikobasierten Freigaben, validierten Ein- und Ausgaben, abgeschirmten Geheimnissen und geschützter Telemetrie. Diese Schichten müssen unabhängig voneinander greifen, damit eine einzelne Fehlkonfiguration nicht unmittelbar zu einer wirksamen Aktion führt.

1. Die Sandbox als enge Ausführungsgrenze konfigurieren

Starten Sie generierten Code und nicht vertrauenswürdige Werkzeuge in einer vom Host getrennten Umgebung, die nach dem Auftrag verworfen wird. Geben Sie nur benötigte Verzeichnisse frei, bevorzugt schreibgeschützt, und begrenzen Sie CPU, Arbeitsspeicher, Laufzeit, Prozesszahl sowie Ein- und Ausgabegröße. Prozesse sollten ohne Root-Rechte und ohne unnötige Betriebssystemfähigkeiten laufen.

Die GKE-Anleitung zur Agent Sandbox isoliert nicht vertrauenswürdigen KI-generierten Code und verlangt in ihrem Beispiel einen Nicht-Root-Kontext, deaktivierte Service-Account-Tokens, entfernte Linux-Capabilities und Ressourcenlimits. Diese Maßnahmen härten die Laufzeit, legen aber nicht fest, welche externen Ressourcen oder Geschäftsaktionen ein Agent verwenden darf.

• Erzeugen Sie pro Auftrag eine frische Laufzeit und bereinigen Sie sie anschließend.
• Mounten Sie nur ausdrücklich benötigte Pfade und vermeiden Sie Host-Verzeichnisse.
• Trennen Sie Laufzeit, Orchestrator und Freigabedienst in eigene Sicherheitszonen.
• Beenden Sie Aufträge automatisch, sobald ein Ressourcenlimit erreicht ist.

2. Identitäten, Rechte und Geheimnisse begrenzen

Jeder Agent und jedes Werkzeug benötigt eine eigene technische Identität. Gemeinsam genutzte Servicekonten und statische Schlüssel vergrößern den möglichen Schaden und erschweren die Zuordnung. Berechtigungen sollten auf eine konkrete Ressource und Aktion beschränkt sein: Ein Agent, der einen Pull Request analysiert, benötigt weder Schreibrechte am Repository noch Zugriff auf Produktionsdaten.

Übergeben Sie Geheimnisse nicht im Prompt oder im Arbeitsverzeichnis. Eine robuste Referenzarchitektur stellt kurzlebige, zweckgebundene Zugangsdaten erst unmittelbar vor einem zulässigen Werkzeugaufruf bereit. Der Werkzeugdienst prüft zusätzlich Identität, Mandant, Zielressource und Aktion; eine syntaktisch korrekte Modellantwort gilt nicht als Autorisierung.

Protokolle sollten nur die Referenz auf ein verwendetes Geheimnis und dessen Zweck enthalten, nicht das Token selbst. Auch vollständige Prompts und Werkzeugergebnisse gehören nicht automatisch in die Telemetrie, weil sie personenbezogene Daten, Quellcode oder Zugangsdaten enthalten können.

3. Netzwerk und Werkzeuge standardmäßig sperren

Beginnen Sie mit gesperrtem ausgehendem Verkehr und öffnen Sie nur die für den Auftrag nötigen Ziele. Ein kontrollierter Proxy sollte Entscheidungen zu Domain, Protokoll, Port und möglichst auch Konto oder Zielressource durchsetzen. Direkte IP-Verbindungen, DNS-Ausnahmen und alternative Tunnelwege müssen derselben Richtlinie unterliegen.

Auch Werkzeuge gehören auf eine Positivliste. Trennen Sie lesende und schreibende Funktionen, definieren Sie Parameter als strukturierte Felder und erzwingen Sie Typen, Wertebereiche und Größenlimits. Dateipfade müssen nach der Normalisierung innerhalb erlaubter Verzeichnisse liegen; SQL- und Shell-Kontexte benötigen parametrisierte Schnittstellen statt zusammengesetzter Zeichenketten.

Beim internen Einsatz von Codex verbindet OpenAI laut seiner Beschreibung der Sicherheitskontrollen Sandboxing mit Freigaberichtlinien, verwalteten Netzwerkzielen, geschützten Anmeldedaten und agenteneigener Telemetrie. Anbieterneutral entscheidend ist die Trennung dieser Kontrollflächen: Eine Netzwerkfreigabe darf nicht zugleich eine Werkzeug- oder Datenfreigabe ersetzen.

4. Prompt Injection und Modellausgaben als untrusted behandeln

Inhalte aus Webseiten, Tickets, E-Mails, Repositorys oder einer RAG-Suche können versteckte Anweisungen enthalten. Solche Daten dürfen nicht in eine höher privilegierte Systemrolle gelangen. Systemanweisungen und Sicherheitsregeln müssen ausschließlich aus entwicklerkontrollierten Quellen stammen.

Die Sicherheitshinweise für Microsoft Agent Framework erläutern, dass indirekte Prompt Injection aus abgerufenen Dokumenten das Modell beeinflussen und Daten über Werkzeugaufrufe abfließen lassen kann; Modellausgaben sollen deshalb vor dem Rendern, Ausführen oder Übergeben an sicherheitsrelevante Kontexte validiert und bereinigt werden. Das Modell darf eine Aktion vorschlagen, aber ein deterministischer Policy-Dienst entscheidet anhand von Werkzeug, Parametern, Ziel, Datenklassifikation und Berechtigung.

Verwenden Sie für Werkzeugparameter strikte Schemas und Positivlisten. HTML, SQL, Shellbefehle und Dateipfade dürfen nicht allein deshalb ausgeführt werden, weil sie formal aus einer Modellantwort stammen. Zusätzlich begrenzen Sie Eingabe- und Ausgabelängen sowie die Aufrufrate, damit manipulierte oder fehlerhafte Antworten keine unkontrollierte Ressourcenlast erzeugen.

5. Folgenreiche Aktionen freigeben und Entscheidungen auditieren

Eine Freigabe ist vor allem bei irreversiblen, extern sichtbaren oder weitreichenden Aktionen sinnvoll: beim Löschen und Überschreiben von Daten, Senden von Nachrichten, Tätigen von Käufen, Ändern von Rechten, Veröffentlichen von Code oder Zugriff auf besonders sensible Informationen. Die Freigabeansicht muss Aktion, Ziel, wesentliche Parameter, Datenumfang und erwartete Wirkung zeigen. Eine pauschale Sitzungsfreigabe ist dafür zu grob.

Erfassen Sie mindestens Auftrag, technische Identität, Modell- und Richtlinienversion, Werkzeugaufruf, normalisierte Parameter, Freigabe- und Netzwerkentscheidung, Ergebnisstatus sowie Laufzeitkennung. Schützen Sie diese Datensätze vor nachträglicher Veränderung und beschränken Sie den Zugriff. Vertrauliche Inhalte sollten nur gespeichert werden, wenn ein klarer Zweck und eine passende Schutzregel bestehen.

Testen Sie die Kontrollen als zusammenhängende Kette: blockierte Dateizugriffe, unbekannte Ziele, manipulierte RAG-Dokumente, Pfadüberschreitungen, übergroße Ausgaben, abgelaufene Zugangsdaten und verweigerte Freigaben. Die Mindestkonfiguration erfüllt ihren Zweck, wenn eine unzulässige Aktion vor ihrer Wirkung stoppt und anschließend nachvollziehbar bleibt, welcher Auftrag, welche Richtlinie und welche Entscheidung beteiligt waren.