KI-Adoption im Unternehmen besteht laut der Analyse aus zwei sehr unterschiedlichen Verhaltensweisen, die gleichzeitig eintreffen. Die laute Hälfte ist technisch: Entwickler installieren Coding-Agenten, die Shells starten, Zugangsdaten-Speicher lesen, Netzwerktunnel öffnen, Pakete herunterladen und Security-Werkzeuge ausführen – alles legitime Arbeit, für eine Erkennungs-Engine aber ununterscheidbar von den Frühphasen eines Einbruchs. Die leise Hälfte entsteht, wenn Beschäftigte Drittanbieter-KI-Anwendungen per OAuth-Zustimmung Zugriff gewähren und Dokumente in generative Werkzeuge einfügen. Das löst selten eine Endpunkterkennung aus, ist aber der Weg, auf dem Daten das Haus verlassen.
In der Produktion wurden nur 5,4 Prozent der KI-bezogenen Alarme überhaupt an einen menschlichen Analysten eskaliert, der Rest wurde zur Nachverfolgung markiert. Dass ein hoher Schweregrad wenig über die tatsächliche Gefahr sagt, zeigt ein Beispiel: Eine einzige Erkennung bei einem einzigen Kunden machte 55 Prozent aller Alarme mit dem Verdikt „kritisch“ aus, die die Windows-Binärdatei Expand.exe als Lateral Tool Transfer meldeten. Bei der Prüfung stellte sich heraus, dass der Coding-Agent eines Entwicklers eine Shell-Umgebung einrichtete – normales Verhalten für diese Art von Arbeit.
Echte Angriffe machen rund 0,02 Prozent der KI-bezogenen Alarme aus. Keiner davon war eine Kompromittierung, die durch den eigenen KI-Agenten einer Organisation verursacht wurde. Jeder Alarm mit Titeln wie „KI-Agent führt Mimikatz aus“, „Reverse Shell aus einem Coding-Werkzeug“ oder „Diebstahl von Zugangsdaten“ löste sich bei der Untersuchung in legitime Entwicklerarbeit oder eine fehlfeuernde Erkennung auf. Real war dagegen ein Angriff, der auf der KI-Welle reitet statt durch sie hindurch: eine laufende Phishing-Kampagne, die bekannte KI-Markennamen als Köder verwendet. Über mehrere Kunden hinweg beobachtete Intezer bösartige E-Mails mit KI-Betreffzeilen – der Köder funktioniert, weil Benachrichtigungen dieser Produkte für Beschäftigte inzwischen Routine sind.
Die 5,8 Prozent echter Risiken verdienen nach Einschätzung der Forscher die meiste Aufmerksamkeit. Hauptproblem sind Agenten, die mit einem Flag zur Umgehung der Berechtigungsabfragen laufen und damit vor dem Handeln nicht mehr nachfragen. In allen untersuchten Fällen war der Aufruf legitime Entwicklerarbeit – genau das macht ihn gefährlich. Dieselbe Voraussetzung wurde bereits in einem öffentlich dokumentierten Supply-Chain-Angriff missbraucht, bei dem der Schadcode eines Angreifers ungehindert lief, weil ein Coding-Agent ohne Berechtigungsabfragen gestartet worden war. Empfohlen werden zusätzliche Konfigurationen, sogenannte Harnesses, die riskante Befehle programmatisch unterbinden.
Das Rauschen ist diagnostizierbar: Erkennungsregeln, die vor der Existenz von KI-Agenten geschrieben wurden, feuern mit hohem Schweregrad auf Routinearbeit. Der deutlichste Fall ist die Software der KI-Anbieter selbst – der per Codesignatur verifizierte, echte Installer von Anthropic Claude Desktop löste bei mehreren Kunden EDR-Regeln wie „Ransomware-Operationen erkannt“ und „kodierter PowerShell-Download und -Ausführung“ aus. Bei den lautesten KI-Erkennungen liegt der Anteil gutartiger Fälle zwischen 77 und 99 Prozent. Ausnahme ist die ClickFix-Erkennung mit nur 37 Prozent gutartigen Fällen – sie feuert auf Coding-Agenten, die mit –yolo gestartet wurden. Auf ähnliche Fehlalarm-Tendenzen im SOC hatte zuvor bereits Sophos hingewiesen.
Als erste Maßnahme empfiehlt Intezer, die lautesten Altdetektionen zu justieren, Richtlinien für die Weitergabe von Informationen an Drittanbieter-KI-Plattformen zu definieren und aktiv nach Berechtigungs-Bypass-Flags, nicht autorisierten Tunneln und riskanten OAuth-Freigaben zu suchen. Schwieriger ist der zweite Schritt: Da KI-Werkzeuge Befehle mit den Anmeldedaten des Nutzers ausführen, werden Alarme dem Nutzer zugerechnet, der von der Aktion oft nichts weiß. Triage muss daher zuerst klären, ob ein Agent oder ein Mensch gehandelt hat. Um Kontexte zu trennen und den Agenten von Zugangsdaten fernzuhalten, rät Intezer zum Betrieb in isolierten Umgebungen wie Docker-Containern oder virtuellen Maschinen.