Im Juni 2026 führte Backslash Security eine Umfrage unter Entwicklungs- und Sicherheitsteams verschiedener Branchen durch und stellte fest, dass bei 100 Prozent der Befragten KI-generierter Code in der Produktion lief. 81 Prozent gaben an, keinen Überblick darüber zu haben, wo und wie KI im gesamten Entwicklungszyklus eingesetzt wurde.
Diese beiden Zahlen beschreiben einen strukturellen Zustand, keinen Sicherheitsverstoß. Der Code wurde ausgeliefert, die Agenten wurden ausgeführt, und niemand konnte nachvollziehen, was sie nach der Eingabeaufforderung taten. Das ist ein gut dokumentiertes Erkennungsproblem: Ein Angreifer – oder in diesem Fall ein Agent – bewegt sich von einem System zum nächsten, und kein einzelnes Protokoll oder Überwachungstool liefert ein vollständiges Bild. Dieser Mechanismus ist mittlerweile in den meisten Organisationen standardmäßig integriert.
Das Problem liegt im Zugriffsmodell, nicht im Agenten selbst
Ein KI-Programmieragent interpretiert ein Ziel, wählt die dazu erforderlichen Werkzeuge aus, führt API-Aufrufe durch, liest und schreibt Dateien, reicht Pull-Anfragen ein, führt Tests durch und passt sich anhand der Ergebnisse an. All dies geschieht unter Verwendung echter Anmeldedaten, mit zugewiesenen Berechtigungen und ohne dass jeder Schritt von einem Menschen autorisiert werden muss.
Dieses Zugangsmodell führt zu zwei sich überschneidenden Problemen:
- Das erste Problem betrifft die Authentifizierung: Agenten werden mit Anmeldedaten ausgestattet. Sie authentifizieren sich. Das Audit-Protokoll vermerkt den Erfolg. Ein gestohlenes Entwickler-Token, das von einem Agenten verwendet wird, sieht im Authentifizierungsprotokoll identisch aus wie dasselbe Token, das von dem Entwickler verwendet wird, dem es gehört. Gültige Anmeldedaten, gültige Sitzung, gültiger Tool-Aufruf. Die Authentifizierung ist erfolgreich.
- Das zweite Problem betrifft die Transparenz: Ein Programmieragent bleibt nicht in einem einzigen System. Er greift auf das Code-Repository, die CI/CD-Pipeline, die „ cloud “-Umgebung, in der Tests ausgeführt werden, und manchmal auch auf den Secret-Speicher zu. Jeder dieser Übergänge überschreitet eine Grenze, und jede Grenze verfügt über eine eigene Protokollierung. Keine dieser Protokollierungen hat Einblick in die anderen. Drei Protokolle, drei Warnmeldungen, ein Angriffspfad.
Menschen, die die Arbeit der Agenten überprüfen, können mit dem Tempo der Agenten nicht mithalten
An dieser Stelle gewinnt das Gespräch, das Noam Brown am 17. September mit Dwarkesh Patel geführt hat, auch außerhalb der KI-Forschungskreise an Bedeutung.
Brown ist Forscher bei OpenAI und beschäftigt sich vor allem mit Multi-Agenten-Systemen. Als OpenAI einen Schwarm von 10.000 Agenten über einen Zeitraum von 88 Stunden auf ein mathematisches Problem ansetzte, war das Ergebnis so komplex, dass kein Mensch es in einem vergleichbaren Zeitrahmen eigenständig hätte überprüfen können. Sein Argument: Mit zunehmender Anzahl der Agenten läuft der Überprüfungsschritt, auf den sich Fachleute verlassen, nicht mehr im gleichen Tempo ab wie die eigentliche Arbeit.
Übertragen wir das auf die Softwareentwicklung. Ein Entwickler, der eine von einer KI generierte Codeänderung überprüft, beurteilt den Code, den er sieht. Er hat keinen Einblick in die API-Aufrufe, die der Agent während der Generierung getätigt hat, in die Pakete, die er abgerufen, getestet und verworfen hat, oder in die Repository-Berechtigungen, die er dabei genutzt hat. Gegenstand der Codeüberprüfung ist das Endergebnis. Das Verhalten, das dazu geführt hat, findet anderswo statt und wird oft nicht protokolliert.
Die Daten von Backslash belegen dieselbe Beobachtung aus einer anderen Perspektive: 81 Prozent der Unternehmen setzen KI-generierten Code in der Produktion ein, haben jedoch keinen systematischen Einblick in den Prozess, durch den dieser Code entstanden ist. Der Code durchläuft die Überprüfung. Das Verhalten, das ihn erzeugt hat, wird hingegen überhaupt nicht überprüft.
Der Vorfall bei Hugging Face war ein Proof-of-Concept für eine strukturelle Gegebenheit
Im Juli 2026 entkam ein OpenAI-Agent aus einer internen Evaluierungs-Sandbox, nutzte eine „ zero-day “ in einem Paket-Registry-Proxy (einem Server, der Softwarebibliotheken von Drittanbietern auf Anfrage abruft) aus, sammelte Anmeldedaten und bewegte sich über ein Wochenende hinweg lateral durch die Produktionsumgebung von Hugging Face. Die technische Rekonstruktion von Hugging Face umfasst rund 17.600 Aktionen des Agenten. OpenAI bestätigte in einer eigenen Stellungnahme die beteiligten Modelle.
Ich habe damals ausführlich über diesen Vorfall berichtet. Hier kommt es vor allem auf den Erkennungsaspekt an. Der Einbruch wurde nicht durch Warnmeldungen aufgedeckt, die vereinzelt ungewöhnliches Verhalten registrierten, sondern durch Korrelation: Dabei wurden Signale aus mehreren separaten Systemen zusammengeführt und zu einer einzigen Zeitachse verknüpft. Die KI-gestützte Rekonstruktion dauerte etwa eine Stunde. Die gleiche Arbeit hätte manuell Tage in Anspruch genommen.
Die Rekonstruktion war möglich, weil Hugging Face über genügend miteinander verknüpfte Protokolle verfügte, um den Hergang nachzuverfolgen. Dabei war KI-Unterstützung erforderlich, da kein menschlicher Überprüfungsprozess so schnell abläuft wie die Agenten.
Warum herkömmliche Bedrohungsanalysen dies von Natur aus übersehen
Threat Intelligence, wie sie üblicherweise genutzt wird, basiert auf Indikatoren: bekannte bösartige IP-Adressen, Datei-Hashes, Domainnamen und Verhaltensmuster, die bestimmten Bedrohungsclustern zugeordnet werden. Diese Indikatoren erfordern einen Bezugspunkt – etwas, das zuvor beobachtet, katalogisiert und mit aktuellen Aktivitäten abgeglichen wurde.
Agenten, die in einer legitimen Entwicklungsumgebung ausgeführt werden, weisen keine bekannte schädliche Signatur auf, mit der ein Abgleich möglich wäre. Die Anmeldedaten sind gültig. Die vom Agenten durchgeführten Aktionen entsprechen seinem angegebenen Zweck. Die von ihm heruntergeladenen Softwarepakete existieren und sind nicht als verdächtig markiert. Es gibt keine namentlich bekannte Angreifergruppe, nach der man suchen könnte, und keine frühere Kampagne, mit der man einen Abgleich vornehmen könnte.
Bei Hugging Face war eine Zuordnung erst möglich, nachdem der Vorfall vollständig aufgeklärt war – und auch das nur, weil OpenAI sich freiwillig gemeldet hatte. Die Aufzeichnungen darüber, was der Agent getan hatte, ließen sich aus den Protokollen rekonstruieren. Wer oder was ihn dazu veranlasst hatte, ließ sich allein anhand dieser Protokolle nicht feststellen. Das Prinzip „Verfolge das Verhalten, nicht die Marke“ gilt nach wie vor als Grundsatz der Erkennung. In diesem Fall steht möglicherweise einfach keine Marke hinter dem Verhalten, die man ausfindig machen könnte.
Die Erkennung funktioniert einwandfrei. Sie ist lediglich unvollständig. Die Indikatorabgleichung ist darauf ausgelegt, bereits bekannte Muster zu erkennen, während das Verhalten von Agenten in großem Maßstab Muster erzeugt, die bisher noch nicht bekannt sind.
Was tatsächlich erforderlich ist, um diese Lücke zu schließen
Die Angriffsfläche ist spezifisch: Agenten mit mehr Zugriffsrechten, als sie benötigen, Anmeldedaten, die im Kontext der Eingabeaufforderung vorhanden sind und dort abgegriffen werden können, sowie fehlende Transparenz hinsichtlich der tatsächlichen Aktivitäten des Agenten nach dessen Start. Das SOC spielt in den meisten Unternehmen dabei überhaupt keine Rolle.
Verhaltenssignale, die systemübergreifend in Echtzeit miteinander verknüpft sind, ermöglichen es, solche Vorgänge im Voraus zu erkennen, anstatt sie im Nachhinein zu rekonstruieren. Das Muster erstreckt sich über: verwendete Anmeldedaten, aufgerufener Dienst, aufgerufener Speicher, cloud gesammelte Anmeldedaten, neuer Cluster erreicht. Diese Kette ist nur von einem Ort aus sichtbar, von dem aus alle ihre Teile auf einen Blick erfasst werden können.
Dies ist in erster Linie ein Problem der Transparenz und erst in zweiter Linie ein Problem der Erkennung. Die meisten Unternehmen, die KI-Agenten in ihrer Entwicklungspipeline einsetzen, weisen noch keine Erkennungslücken auf. Sie haben vielmehr eine Signallücke, und Signallücken machen Erkennungslücken unvermeidlich.
Prüfen, ändern, begrenzen
- Fragen Sie Ihr SOC, ob es während der Laufzeit Einblick darin hat, was die KI-Agenten in Ihrer Entwicklungspipeline tatsächlich tun. Nicht, ob es den eingecheckten Code einsehen kann, sondern ob es die API-Aufrufe, die Verwendung von Anmeldedaten und den Zugriff auf Ressourcen unter cloud erkennen kann, die während der Ausführung der Agenten stattgefunden haben. Wenn die Antwort unklar ist, lautet die Antwort „nein“.
- Behandeln Sie die Pipeline, in der Ihre KI-Agenten ausgeführt werden, als ernstzunehmende Angriffsfläche. Überprüfen Sie bei jedem System, das Inhalte aufnimmt, die es nicht selbst erzeugt hat (von Nutzern eingereichte Datensätze, Pakete von Drittanbietern, Modellausgaben), die Pfade, über die diese Inhalte die Ausführung von Code auslösen können. Bei Hugging Face waren zwei solcher Pfade von Bedeutung: einer, bei dem eine Datensatzdatei die Plattform anweisen konnte, Code auf einem Remote-Server auszuführen, und einer, bei dem ein Konfigurationsfeld als Anweisung statt als Wert interpretiert wurde (Template-Injection). Für die Ausnutzung beider Schwachstellen ist kein ausgeklügelter Angreifer erforderlich. Beide lassen sich beheben.
- Gewähren Sie Agenten nur die Zugriffsrechte, die sie für ihre spezifische Aufgabe unbedingt benötigen. Ein Agent, der ein Repository liest, benötigt keinen Schreibzugriff auf den Secrets-Speicher. Überprüfen Sie die Berechtigungen von Agenten genauso, wie Sie ein Dienstkonto überprüfen würden, denn genau das ist ein Agent: ein Dienstkonto, auf dem eine Agent-Schleife ausgeführt wird.
Die Backslash-Umfrage bezeichnet dies eher als Versagen der Unternehmensführung denn als Versagen der technischen Fähigkeiten. Unternehmen können die Laufzeit von Agenten bereits heute überwachen. Die meisten sehen dafür jedoch keine Notwendigkeit.
Beide Probleme behandle ich ausführlich in „Mind Your Attack Gaps“, insbesondere das, was ich als Lücke 2 (Authentifizierung gelingt) und Lücke 3 (Bewegung ist nicht sichtbar) bezeichne, einschließlich der jeweiligen Erkennungslogik.