In derselben Woche fand ein KI-Agent 24 Android-Lücken, und Red Hat fragte, wer den Agenten begrenzt
Victoria Shinder2 Min. LesezeitZwei Beiträge vom 28. September beschreiben dieselbe Technik von entgegengesetzten Seiten: den KI-Agenten als Werkzeug, das Sicherheitslücken findet, und den KI-Agenten als System, das eingehegt werden muss.
Der Agent als Prüfer. GitHubs Security Lab hat nach eigenen Angaben mehr als 20 Schwachstellen in Android-Anwendungen gemeldet, gefunden mit dem quelloffenen Taskflow Agent, der Prompts und mehrstufige Abläufe so bündelt, dass ein Modell eine Prüfung Schritt für Schritt abarbeitet. Der Forscher ergänzte einen Taskflow, der mobile Einstiegspunkte, also die Stellen, an denen von Angreifern kontrollierte Daten ankommen, vom Rest eines Repositorys trennt, und einen weiteren, der das Modell jeden Einstiegspunkt gegen eine feste Liste von Android-Schwachstellenklassen prüfen lässt. Die Begründung ist aufschlussreich: Mobile Lücken sind weniger bekannt und Modellausgaben nicht deterministisch, also werden die wesentlichen Prüfungen festgeschrieben statt dem Modell überlassen. Ein Durchlauf dauert bei einem mittelgroßen Repository ein bis zwei Stunden und braucht eine Copilot-Lizenz mit Premium-Anfragen.
Der Agent als Risiko. Am selben Tag argumentiert Red Hats Technikchef, dass Schutzmechanismen im Modell allein nicht mehr genügen, sobald Agenten APIs aufrufen, Zugangsdaten nutzen und Geschäftssysteme verändern können. Die Kontrollen, die er aufzählt, liegen außerhalb des Modells: Identität und Rechte des Agenten, sein Zugriff auf Werkzeuge und Daten, seine Laufzeitumgebung, seine Netzverbindungen. Sie sollten, schreibt er, davon ausgehen, dass sich der Agent unerwartet verhält, und seinen Zugriff auch dann begrenzen.
Was sie verbindet
Beide Beiträge kommen auf verschiedenen Wegen zur selben Regel. GitHubs Prüfungen funktionieren, weil ein Mensch die Schritte und die Checkliste festlegt, statt darauf zu vertrauen, dass das Modell sie sich merkt. Red Hat argumentiert, dass Rechte vom umgebenden System durchgesetzt werden müssen, statt darauf zu vertrauen, dass das Modell sie respektiert. In beiden Fällen ist das Modell nützlich, und in beiden Fällen ist der verlässliche Teil die Struktur um es herum. Für Teams, die Agenten einsetzen, ergibt sich daraus ein einfacher Test: Welche Schutzmaßnahmen des Agenten würden noch greifen, wenn das Modell seine Anweisungen ignoriert? Diese sind die Kontrollen, der Rest ist Hoffnung.