Unternehmens-KI überschwemmt SOCs mit harmlosen Alarmen – und verbirgt echte Risiken

Zahl der KI-bezogenen Alarme steigt innerhalb von vier Monaten um 685 %

Der Einsatz generativer KI in Unternehmen schafft ein neues Problem für den Security-Betrieb: Legitime Tools verhalten sich zunehmend wie Software, auf die SOC-Erkennungsregeln eigentlich abzielen.

Eine aktuelle Auswertung von rund 16,9 Millionen SOC-Alarmen identifizierte etwa 73.000 Alarme im Zusammenhang mit KI-Aktivitäten – das entspricht 0,43 % der Gesamtzahl. Dieser Anteil ist weiterhin gering, doch das zugrunde liegende Volumen stieg in jedem untersuchten Monat.

Im stabilen Berichtszeitraum von Februar bis Juni 2026 nahm die Zahl der KI-bezogenen Alarme um 685 % zu. Besonders deutlich war die Beschleunigung im Mai 2026. Das deutet darauf hin, dass 0,43 % eher einen Ausgangswert als einen dauerhaft gültigen Anteil an der SOC-Arbeitslast darstellen.

Die Alarme verteilten sich auf drei deutlich unterschiedlich große Kategorien:

• 94,1 % waren Erkennungsrauschen, meist weil legitime Aktionen von KI-Agenten durch bestehende Sicherheitskontrollen falsch klassifiziert wurden.
• 5,8 % stellten ein echtes Sicherheitsrisiko dar, darunter unsichere Konfigurationen oder potenziell gefährliche Automatisierung ohne Hinweise auf eine Kompromittierung.
• 0,02 % waren bestätigte Angriffe, vor allem Phishing- und Betrugsversuche, die das Interesse an KI-Produkten ausnutzten.

Das unmittelbare Problem ist daher keine Epidemie, bei der Angreifer unternehmenseigene Coding-Agenten kompromittieren. Es ist vielmehr der Zusammenprall autonomer Software mit einer Erkennungslogik, die für eine Welt entwickelt wurde, in der jeder sensible Befehl von einem Menschen, einem Skript oder einem Malware-Prozess gestartet wurde.

Dieser Zusammenprall bindet Untersuchungskapazitäten. Gleichzeitig kann er die kleinere Gruppe von Ereignissen verschleiern, bei denen offengelegte Zugangsdaten, uneingeschränkte Ausführung, riskante OAuth-Berechtigungen und echtes Social Engineering eine Rolle spielen.

Coding-Agenten ähneln Eindringlingen verblüffend stark

Moderne Coding-Agenten erzeugen nicht nur Text. Je nach Konfiguration und zugewiesener Aufgabe können sie Befehlszeilen starten, Pakete installieren, Zugangsdaten untersuchen, Sicherheitswerkzeuge ausführen, Dateien manipulieren und Entwicklungsdienste für externe Netzwerke erreichbar machen.

Jede einzelne Aktion kann legitim sein. Zusammengenommen können sie jedoch den Phasen einer Infiltration ähneln: Aufklärung, Zugriff auf Zugangsdaten und Command-and-Control.

Ein Kunde erlebte dieses Problem im Zusammenhang mit der Windows-Binärdatei Expand.exe. Eine Erkennung für den lateralen Transfer von Werkzeugen, an dem die ausführbare Datei beteiligt war, erzeugte 55 % aller Alarme, die in der untersuchten Population als „kritisch“ eingestuft wurden. Die Untersuchung ergab, dass der Coding-Agent eines Entwicklers eine Shell-Umgebung einrichtete und keine Angreifer-Tools verschob.

Auch die Anwendungen der KI-Anbieter selbst lösten schwerwiegende Erkennungen aus. Ein echter, korrekt signierter Installer von Anthropic Claude Desktop aktivierte bei mehreren Unternehmen EDR-Regeln mit den Bezeichnungen „Ransomware Operations detected“ und „Encoded PowerShell Download and Run“.

Für Claude Desktop, Cursor und die anderen beobachteten KI-Anwendungen wurden keine Produktversionen genannt. Die Ergebnisse sollten daher nicht als Hinweis auf eine Schwachstelle interpretiert werden, die auf eine bestimmte Version beschränkt ist. Sie betreffen das Anwendungsverhalten, die Konfiguration durch Nutzer und die Sicherheitskontrollen rund um die KI-Ausführung.

Der Schweregrad war kein verlässlicher Ersatz für eine Bewertung der Absicht. Eine kritische Einstufung kann auf einen technisch gefährlichen Befehl hinweisen, sagt aber nicht aus, wer den Befehl angefordert hat, warum er ausgeführt wurde oder ob ein Angreifer beteiligt war.

SOC-Ermittler benötigen jetzt Ausführungskontext, der herkömmlichen Endpoint-Erkennungen häufig fehlt. Dazu gehören der übergeordnete Prozess des Agenten, die Aufgabe des Nutzers, das betroffene Repository, die Befehlshistorie, der Berechtigungsmodus und alle nicht vertrauenswürdigen Inhalte, die vor Beginn der Aktivität verarbeitet wurden.

Unsichere Automatisierung schafft Risiken ohne Sicherheitsverletzung

Die 5,8 % mit echtem Risiko sind vermutlich die operativ wichtigste Gruppe. Bei diesen Ereignissen handelte es sich nicht um bestätigte Kompromittierungen. Sie schufen jedoch Bedingungen, unter denen Systeme oder Zugangsdaten offengelegt werden konnten.

Die größte Quelle waren Coding-Agenten, die mit umgangenen Berechtigungsschutzmechanismen gestartet wurden. In diesem Modus kann der Agent Befehle ausführen, ohne dass der Nutzer jede sensible Aktion einzeln genehmigen muss.

Jede untersuchte Ausführung mit umgangener Berechtigungsprüfung stand im Zusammenhang mit legitimer Entwicklungsarbeit. Das macht die Konfiguration jedoch nicht sicher. Es bedeutet, dass Unternehmen routinemäßig eine Kontrolle entfernen, die andernfalls schädliche oder auf den Diebstahl von Zugangsdaten ausgerichtete Befehle unterbrechen könnte.

Ein Agent, der ohne Rückfragen arbeitet, kann bei vertrauenswürdigem Code harmlos bleiben. Das Risiko verändert sich, sobald er ein manipuliertes Repository, vergiftete Anweisungen, von Angreifern kontrollierte Dokumentation oder andere nicht vertrauenswürdige Eingaben verarbeitet. Ein öffentlich dokumentierter Supply-Chain-Vorfall hatte bereits gezeigt, wie unter dieser Voraussetzung schädlicher Code uneingeschränkt ausgeführt werden konnte.

Wenn eine unbeaufsichtigte Ausführung erforderlich ist, sollten Unternehmen programmgesteuerte Schutzmechanismen ergänzen – häufig als Harnesses bezeichnet –, die Richtlinien unabhängig vom Modell durchsetzen. Diese Kontrollen können das Auslesen von Zugangsdaten blockieren, ausgehende Tunnel beschränken, beschreibbare Pfade begrenzen und für risikoreiche Befehle eine Genehmigung verlangen.

Mehrere beobachtete Verhaltensweisen zeigen, warum das wichtig ist.

In einer Umgebung startete ein KI-Codeeditor PowerShell. Diese startete wiederum ngrok und erstellte mithilfe des Authentifizierungstokens des Entwicklers einen benannten Reverse-Tunnel. Die Absicht war offenbar harmlos, das Ergebnis jedoch eine von außen erreichbare Verbindung zu einem Entwicklungssystem.

In einem anderen Fall versuchte ein Agent, seinen eigenen Token und Cloud-Zugangsdaten abzurufen, indem er folgenden Befehl ausführte:

security dump-keychain > /tmp/

Statt ein einzelnes benötigtes Geheimnis auszulesen, schrieb der Befehl den Inhalt des macOS-Schlüsselbunds an einen temporären Speicherort. Damit wurde aus einer eng begrenzten Authentifizierungsaufgabe eine umfassende Offenlegung von Zugangsdaten.

Auch Cursor wurde beim Starten einer kritischeren Prozesskette beobachtet:

Cursor.exe → powershell.exe → rundll32.exe

Die Sequenz nutzte die MiniDump-Funktionalität von comsvcs.dll, temporäre PowerShell-Skripte und Befehle zum Auslesen des Arbeitsspeichers. Möglicherweise wurde sie beim Debugging erzeugt. Die Technik kann jedoch Zugangsdaten und andere in Prozessen gespeicherte Geheimnisse offenlegen.

Diese Fälle lassen sich nicht sicher als Fehlalarme abtun. Es handelt sich um legitime Aktivitäten mit Konsequenzen, die denen eines Angreifers ähneln.

Datenoffenlegung ist unauffälliger als die Ausführung auf Endgeräten

Nicht jedes Risiko durch Unternehmens-KI erzeugt einen verdächtigen Prozessbaum. Beschäftigte verbinden außerdem Drittanbieter-KI-Anwendungen über OAuth, authentifizieren sich mit Unternehmensidentitäten und laden Geschäftsinformationen zu Diensten für generative KI hoch.

Die untersuchten Aktivitäten umfassten erteilte OAuth-Einwilligungen für ChatGPT in mehreren Mandanten sowie Ereignisse mit dem Titel „First sign-in to a new application: OpenAI“. Ein Kunde erzeugte außerdem eine beträchtliche Zahl von Datenschutzalarmen im Zusammenhang mit Uploads auf Plattformen für generative KI.

Die meisten Ereignisse waren harmlos, doch eine Autorisierung schließt eine Offenlegung nicht aus. OAuth-Berechtigungen können einem externen Anbieter das Lesen von Unternehmensdaten ermöglichen. Ein kompromittiertes KI-Konto oder ein Pfad über Prompt Injection könnte vorhandene Berechtigungen missbrauchen.

Uploads stellen ein anderes Problem bei der Sichtbarkeit dar. Eine EDR-Plattform kann beobachten, wie ein Coding-Agent rundll32.exe startet. Möglicherweise erkennt sie jedoch nicht, dass sensible Texte in einen browserbasierten KI-Dienst eingefügt wurden. Unternehmen benötigen daher neben der Überwachung von Endgeräten auch Telemetriedaten aus den Bereichen Identität, SaaS und Datenschutz.

SOC-Teams sollten den Umfang KI-bezogener OAuth-Berechtigungen überprüfen, erstmalige Nutzungen identifizieren und feststellen, ob es für den Beschäftigten einen geschäftlichen Grund gab, die Anwendung zu autorisieren. Richtlinien für die Datenverwaltung sollten außerdem festlegen, welche Informationen an externe Modelle übermittelt werden dürfen und wie Verstöße erkannt werden.

Echte Angriffe nutzten KI als Köder, nicht als Exploit

Bestätigte bösartige Aktivitäten machten etwa 0,02 % der KI-bezogenen Alarme aus. Keiner der erkannten Angriffe wurde dem unternehmenseigenen KI-Agenten zugeschrieben.

Alarme, die zunächst darauf hinzudeuten schienen, dass ein Agent Mimikatz ausführt, eine Reverse-Shell öffnet oder Zugangsdaten stiehlt, standen letztlich mit legitimer Entwicklungsarbeit oder harmlosen Aktivitäten in Verbindung, die von den Erkennungsregeln falsch klassifiziert worden waren.

Echte Angreifer nutzten stattdessen die Glaubwürdigkeit bekannter KI-Marken aus.

Eine E-Mail zu Zahlungsbetrug verwendete den Betreff „RE: Anthropic Engagement approval & payment“, um eine erfundene Vertrags- oder Rechnungsgeschichte zu stützen. Anthropic lieferte den Vorwand, war jedoch weder Absender noch Quelle des Angriffs.

Eine andere Kampagne imitierte eine Einladung zu einem Google-/Gemini-Ads-Arbeitsbereich. Die Infrastruktur von Absender und Antwortadresse hatte keinen Bezug zu Google. Die Nachricht verwies die Empfänger auf die verdächtige Domain:

gemini-advertisers[.]com

Das Branding von OpenAI erschien in einer betrügerischen Einladung zum „OpenAI Partner Summit 2026“, die von [email protected] versendet wurde. Die legitime Infrastruktur von Zoom verlieh dem Anmeldeprozess zusätzliche Glaubwürdigkeit. Das Branding von OpenAI wurde außerdem in einem Phishing-Szenario mit Gerätecode verwendet.

Für diese Vorfälle ist eine klare analytische Unterscheidung erforderlich. Ein Alarm, in dem ein KI-Produkt erwähnt wird, kann die Ausführung eines Agenten, unsichere Automatisierung, eine externe Anwendung, die Daten empfängt, oder einen unabhängigen Angreifer beschreiben, der eine bekannte Marke missbraucht.

SOCs benötigen kontextbezogene Unterdrückung statt pauschaler Ausnahmen

Die Automatisierung verarbeitete bereits den größten Teil des beobachteten Volumens. Die Triage-Plattform stufte 79,8 % der KI-bezogenen Alarme als harmlos ein und unterdrückte 81,7 % automatisch. Nur 5,4 % erreichten einen menschlichen Analysten, während die übrigen zur weiteren Bearbeitung zurückgehalten wurden.

Diese Zahlen zeigen, dass eine automatisierte Triage notwendig ist. Eine weitreichende Zulassungsliste wäre jedoch gefährlich. Derselbe Shell-, Tunnel- oder Befehl zum Zugriff auf Zugangsdaten kann routinemäßige Entwicklungsarbeit, unsicheres Verhalten eines Agenten oder eine aktive Kompromittierung darstellen.

Sicherheitsteams sollten ihre Kontrollen stattdessen auf einen konkreten Kontext abstimmen:

1. Zugelassene KI-Tools und erwartete Prozessbäume als Baseline erfassen. Signierte Installer und bekannte Agenten-Workflows können eine niedrigere Priorität erhalten, ohne jeden untergeordneten Prozess pauschal auszunehmen.
2. Ausführungen mit umgangener Berechtigungsprüfung erkennen. Unbeschränkte Agenten-Sitzungen sollten separat inventarisiert, eingeschränkt und überwacht werden.
3. Sichtbarkeit für risikoreiche Befehle erhalten. Speicherabbilder, Exporte aus Schlüsselbunden, Reverse-Tunnel und Zugriffe auf Credential Stores müssen weiterhin überprüft werden – auch wenn ein KI-Agent sie initiiert hat.
4. Endpoint- und Identitätstelemetrie korrelieren. OAuth-Einwilligungen, erstmalige Anmeldungen bei KI-Anwendungen und ungewöhnliche Daten-Uploads können Risiken aufdecken, die eine EDR-Lösung nicht erkennt.
5. Mitarbeitende für Betrug mit KI-Thematik sensibilisieren. Zahlungsaufforderungen, Einladungen zu Arbeitsbereichen, Konferenzanmeldungen und Gerätecode-Abfragen sollten außerhalb der erhaltenen Nachricht verifiziert werden.
6. Das Wachstum statt des aktuellen Anteils messen. Eine Kategorie, die zwischen Februar und Juni 2026 um 685 % gewachsen ist, kann nicht auf Grundlage ihres früheren Volumens personell ausgestattet werden.

Die zentrale Aufgabe besteht nicht darin festzustellen, ob KI beteiligt war. SOCs müssen ermitteln, ob die Aktivität erwartet, gefährlich überberechtigt oder bösartig war – und zwar bevor harmlose Automatisierung das entscheidende Signal überdeckt.