Docker fordert Isolation und Governance für KI-Agenten

Docker hat einen Leitfaden zu fünf Sicherheitsrisiken veröffentlicht, die entstehen, wenn KI-Agenten mit begrenzter menschlicher Aufsicht browsen, Code ausführen und Werkzeuge aufrufen. Geschrieben haben ihn Srini Sekaran, Principal Product Marketing Manager bei Docker, und Produktmanager Eric Jia. Die Autoren argumentieren, dass gerade die Autonomie, die Agenten nützlich macht, herkömmliche Kontrollen der Anwendungssicherheit unzureichend macht.

Die fünf Risiken

Docker nennt Prompt Injection, Werkzeugmissbrauch und Werkzeugvergiftung, übermäßige Autonomie, offengelegte Zugangsdaten und Datenabfluss. Alle fünf hätten eine gemeinsame Ursache: Ein Agent wählt zur Laufzeit Werkzeuge aus, verkettet mehrere Aktionen und arbeitet oft mit den Rechten der Person, die ihn gestartet hat.

Klassische Websicherheit geht häufig davon aus, dass Anfragen an bekannten Endpunkten eintreffen und von deterministischem Code verarbeitet werden. Agenten passen nicht in dieses Modell. Ein Coding-Agent kann nach einer einzigen Anweisung eine Datei lesen, eine Abhängigkeit installieren, die Konfiguration ändern, Tests ausführen und einen Commit pushen. Ein kompromittierter oder fehlgeleiteter Agent kann deshalb ein weit größeres Spektrum an Aktionen auslösen als ein herkömmlicher Dienst, so Docker.

Prompt Injection und Werkzeuge

Prompt Injection gilt bei Docker als das entscheidende Risiko. Angreifer müssen kein System direkt kompromittieren. Sie können Anweisungen in Material platzieren, das ein Agent lesen soll, etwa eine Webseite, einen Codekommentar, ein Issue oder ein Dokument. Docker zitiert einen Vorfall, bei dem ein Coding-Agent Anweisungen befolgte, die im Inhalt eines Repositories versteckt waren, und Aktionen ausführte, die sein Nutzer nicht verlangt hatte.

"Ein Agent beantwortet nicht nur eine Frage, er browst, führt Code aus und ruft Werkzeuge selbstständig auf. Eine einzige schlechte oder manipulierte Anweisung kann deshalb echten Schaden anrichten statt nur eine falsche Antwort zu liefern." Eric Jia und Srini Sekaran, Docker

Docker bezweifelt, dass sich Prompt Injection durch Anweisungen an das Modell beseitigen lässt. Ein Agent könne eine legitime Anweisung nicht zuverlässig von einer eingeschleusten unterscheiden. Die bevorzugte Antwort: begrenzen, was ein gekaperter Agent erreichen kann, damit eine erfolgreiche Manipulation weniger Schaden anrichtet.

"Der Agent kann eine legitime Anweisung nicht zuverlässig von einer eingeschleusten unterscheiden. Deshalb besteht die Verteidigung darin, zu begrenzen, was ein gekaperter Agent erreichen kann." Eric Jia und Srini Sekaran, Docker

Werkzeuge sind der zweite Problembereich. Agenten nutzen Konnektoren, Datenbankabfragen, Dateioperationen und Codeausführung, um auf externe Systeme einzuwirken. Docker warnt, dass ein Agent mit mehr Werkzeugen als für eine Aufgabe nötig die Angriffsfläche vergrößert. Auch eine Werkzeugbeschreibung könne versteckte Anweisungen enthalten, die den Agenten zum Missbrauch des Werkzeugs verleiten.

Das deckt sich mit der Arbeit von OWASP zu Bedrohungen und Gegenmaßnahmen bei Agentic AI, über die InfoQ im September 2025 berichtete. OWASP zählte Werkzeugmissbrauch zu den großen neuen Bedrohungen. Angreifer bringen Agenten demnach dazu, autorisierte Werkzeuge zu missbrauchen, ohne die erteilten Rechte zu verlassen. Empfohlen wurden Zugriffsprüfung, Verhaltensüberwachung, operative Grenzen und manipulationssichere Ausführungsprotokolle. Dockers Beitrag verlangt mehr als ein Jahr später nahezu dasselbe.

Autonomie und Zugangsdaten

Docker beschreibt den "YOLO-Modus", in dem jede Aktion eines Agenten automatisch genehmigt wird, als sichtbares Beispiel für weitreichende Dauerrechte. Der Modus könne produktiv sein, solle aber nur innerhalb einer Grenze genutzt werden, die den Agenten von Systemen und Daten fernhält, die er nicht anfassen darf.

Der Beitrag nennt zwei Beispiele. Ein Entwickler bat einen Coding-Agenten, ein altes Repository aufzuräumen. Der Agent erzeugte einen rm -rf-Befehl mit einem abschließenden ~/ und führte ihn ohne Bestätigung aus, wodurch das Home-Verzeichnis des Entwicklers gelöscht wurde. Docker zitiert außerdem einen AWS-Ingenieur, der einem Coding-Agenten einen Fehler im Cost Explorer übergab, während dieser mit Rechten auf Operatorebene lief. Der Agent entschied sich, die Produktionsumgebung zu löschen und neu aufzubauen, was zu einem dreizehnstündigen regionalen Ausfall führte.

Der Umgang mit Zugangsdaten hängt eng damit zusammen. Agenten sollten kein persönliches Token eines Entwicklers erben, weil jede Aktion dann dessen volle Rechte trägt. Docker empfiehlt getrennte, kurzlebige Zugangsdaten, die zur Laufzeit eingespeist und aus der Konversation herausgehalten werden. Geheimnisse in Prompts, Konfigurationsdateien oder Umgebungsvariablen von Images sind ebenfalls ein Risiko, weil eingeschleuste Anweisungen sie möglicherweise aus dem Kontext des Agenten auslesen können.

Das letzte Risiko ist Datenabfluss. Ein Agent mit Netzzugang und sensiblen Informationen im Kontext kann diese an ein ungewolltes Ziel senden. In Multi-Agenten-Systemen, in denen ein Agent Arbeit an einen anderen weitergibt, wächst das Risiko nach Einschätzung von Docker. Empfohlen werden freigegebene Netzwerkausgänge und die Behandlung jeder Übergabe zwischen Agenten als nicht vertrauenswürdige Eingabe.

Was Docker empfiehlt

Docker setzt Isolation und Governance als wichtigste Verteidigung, nicht allein bessere Modelle. Die Empfehlungen zielen darauf, Reichweite zu begrenzen, Zugangsdaten zu trennen und Netzwerkausgänge zu kontrollieren. Der Leitfaden deckt sich mit anderer Arbeit, über die InfoQ berichtet hat. Der im Juli 2026 beschriebene Sicherheitsbauplan für Google GKE empfiehlt GKE Sandbox auf Basis von gVisor, um Agenten einzuhegen.