Der Ablauf bei Hugging Face lässt sich laut Maor klar nachzeichnen: Der KI-Agent las interne Daten aus und griff dabei Cloud- und Cluster-Zugangsdaten ab. Damit gelangte er an interne Dienste und erlangte begrenzten Schreibzugriff auf den Quellcode. Entscheidend war, dass der Agent nicht auf Anhieb treffen musste — er probierte unterschiedliche Wege aus, lernte aus den gescheiterten und fügte daraus die Angriffskette zusammen, die am ehesten funktionierte.
Das eigentliche Risiko liege damit nicht im Abstrakten, also darin, was ein Modell schlussfolgern kann, argumentiert Maor. Es gehe um Berechtigungen: um die Systeme, Zugangsdaten, Werkzeuge und Netze, auf die ein Agent zugreifen darf. Der Vorfall habe entsprechend nicht eine einzelne versagende Kontrolle offengelegt, sondern drei konkrete Lücken.
Die erste betrifft die Identität. Viele Unternehmen erfassen KI-Agenten weiterhin wie Software — als Anwendung mit Lizenz und Bereitstellungsticket. Ein Agent, der private Daten lesen, Werkzeuge aufrufen und selbstständig Aufgaben starten kann, ist aber keine gewöhnliche Software. Einem neuen Mitarbeiter würde man solche Zugriffe nicht ohne benannten Verantwortlichen, klar abgegrenzten Umfang und eine definierte Möglichkeit zum Entzug einräumen.
Die zweite Lücke zeigte sich bei der Reaktion. Das Team von Hugging Face wollte die bei dem Einbruch entstandenen Befehle und den Datenverkehr analysieren und zog dafür kommerzielle KI-Modelle heran — die die Anfrage jedoch ablehnten. Die übermittelten Informationen ähnelten echter Schadsoftware so stark, dass die Modelle die Anfrage selbst für einen Angriff hielten. Das Team behalf sich mit einem selbst gehosteten Modell ohne diese Einschränkungen. Dieser Ausweg funktionierte nur, weil die Option zufällig bereitstand.
Am größten war die dritte Lücke, die Eskalation. Der Sicherheits-Stack von Hugging Face korrelierte mehrere mehrdeutige Signale korrekt zu einem Gesamtbild des Angriffs — doch die Eskalation verlief zu langsam, um das Ergebnis noch zu ändern. Das Muster wurde nicht als schwerwiegend genug eingestuft, um den Bereitschaftsdienst zu alarmieren. Es fehlte die vorab erteilte Befugnis zu handeln, bevor der Angreifer sein nächstes Ziel erreichte.
Als Konsequenz empfiehlt Maor, jeden Agenten wie ein privilegiertes Konto zu behandeln: mit fachlichem Eigentümer, auf die jeweilige Aufgabe zugeschnittenen Berechtigungen, kurzlebigen Zugangsdaten und einem Prüfpfad, den Sicherheitsteams tatsächlich abfragen können. Zugriffe müssen sich bei Verdacht sofort entziehen lassen. Dieselbe Disziplin solle für die umgebende Infrastruktur gelten — Cloud-Metadaten für Workloads unerreichbar halten, die sie nicht brauchen, und Dienstidentitäten nach Umgebungen trennen.
Die Reaktionsfähigkeit sei vor einem Vorfall zu testen, nicht danach: Kann das Team realistische Schadartefakte schnell und sicher untersuchen, und wo geschieht diese Analyse? Für den Fall, dass ein Modell eine legitime defensive Aufgabe verweigert, brauche es eine genehmigte Rückfalloption — ein selbst gehostetes Modell oder eines der Programme mit verifiziertem Zugang, die einige KI-Anbieter inzwischen für Verteidiger anbieten.
Bei der Handlungsbefugnis rät Maor, Belege aus Netz, Identitäten, Endpunkten, Anwendungen und Daten in einer korrelierten Ansicht zusammenzuführen, bestimmten Mustern eindeutige Eskalationsregeln zuzuordnen und jede davon mit einer vorab genehmigten Eindämmungsmaßnahme zu koppeln.