Intezer AI SOC-Warnungen stiegen sprunghaft an, doch fast alle waren Fehlalarme

Intezer AI SOC-Warnungen stiegen von Februar bis Juni 2026 um 685 %, obwohl sie in der Studie nur 0,43 % der Sicherheitswarnungen ausmachten. Der Konflikt zeichnet sich bereits deutlich ab. Unternehmens-KI hat nicht die Welle agentengesteuerter Sicherheitsverletzungen ausgelöst, die viele Sicherheitsteams befürchtet hatten. Stattdessen erzeugt sie einen schnell wachsenden Strom legitimer Aktivitäten, die häufig wie ein Eindringen wirken.

Intezer untersuchte rund 16,9 Millionen Warnungen in mehreren Unternehmensumgebungen. Etwa 73.000 betrafen KI-Tools oder -Agenten. Die Forschenden stuften 94,1 % als Fehlalarme, 5,8 % als echte Sicherheitsrisiken und nur 0,02 % als tatsächliche Angriffe ein.

Dieses Ungleichgewicht stellt etablierte Erkennungslogik der normalen KI-gestützten Arbeit gegenüber. Claude, Codex, Cursor, ChatGPT und ähnliche Tools können Prozesse starten, Dateien verarbeiten, Shells aufrufen und Verbindungen zu Diensten herstellen. Ohne Kenntnis der Nutzerabsicht ähneln diese Aktionen Angreiferverhalten.

Das Ergebnis bedeutet nicht einfach nur mehr Arbeit für ein Security Operations Center, kurz SOC. Es ist ein Kontextproblem. Teams müssen legitime Agentenaktivitäten von unsicherem Agentenverhalten unterscheiden, bevor Fehlalarme die wirklich relevanten Gefährdungen überdecken.

Intezer AI SOC-Warnungen stiegen schneller, als ihr Anteil vermuten lässt

Die wichtige Zahl ist nicht der aktuelle Anteil von KI am Warnungsvolumen. Entscheidend sind Tempo und Zusammensetzung dieses Wachstums.

Laut Intezer-Studie zu KI-Warnungen erzeugten KI-bezogene Aktivitäten rund 73.000 der 16,9 Millionen überprüften Warnungen. Damit bleibt die Kategorie klein gegenüber Endpunkt-, Identitäts-, E-Mail-, Cloud- und Netzwerk-Warnungen, die Unternehmens-SOCs bereits erreichen.

Das monatliche KI-bezogene Volumen nahm jedoch während des stabilen Berichtszeitraums kontinuierlich zu. Intezer maß zwischen Februar und Juni 2026 ein Wachstum von 685 %. Das Unternehmen bezeichnete das Muster als monoton, also als Anstieg in jedem vollständigen Monat gegenüber dem vorherigen.

Diese Entwicklung ist relevant, weil die Einführung im Unternehmen keine formelle unternehmensweite Bereitstellung erfordert. Mitarbeitende können einen Consumer-Chatbot über OAuth anbinden, wodurch eine Anwendung auf freigegebene Kontores­sourcen zugreifen kann. Entwickler können Coding-Agenten installieren, die sofort mit lokalen Systemen interagieren.

Jede dieser Aktionen schafft eine neue Quelle für Telemetriedaten. Sie kann zudem Regeln aktivieren, die Jahre vor dem Einsatz universell nutzbarer Agenten auf Arbeitsrechnern erstellt wurden.

Intezer teilte die daraus resultierenden Warnungen in drei Kategorien ein. Fehlalarme umfassten legitime Aktivitäten, die eine bestehende Erkennung auslösten. Sicherheitsrisiken umfassten unsicheres Verhalten oder Gefährdungen ohne bestätigte Kompromittierung. Echte Angriffe erforderten Belege für eine tatsächliche Angreiferoperation.

Fehlalarme dominierten mit 94,1 %. Sicherheitsrisiken machten 5,8 % aus, während bestätigte Angriffe rund 0,02 % darstellten. Diese Klassifizierungen stammen von Intezer und dessen Methodik; unabhängige Studien können daher andere Verhältnisse ergeben.

Die internen Bearbeitungsdaten zeigten eine weitere Ebene desselben Musters. Intezer zufolge erhielten 79,8 % der KI-bezogenen Warnungen eine Einstufung als unbedenklich. Das automatisierte System unterdrückte 81,7 % und schloss sie, ohne sie einem menschlichen Analysten vorzulegen.

Nur 5,4 % wurden an einen Analysten eskaliert. Die übrigen Warnungen wurden zur Nachverfolgung markiert, statt sofort als Vorfälle behandelt zu werden.

Diese Ergebnisse sprechen für automatisierte Triage, legen aber auch eine Abhängigkeit offen. Die Automatisierung muss die Beziehung zwischen einem Agenten, seinem Nutzer und der ausgeführten Aufgabe verstehen. Ein Prozessname oder Befehl allein liefert diesen Kontext nur selten.

Ein Kunde erzeugte über eine einzige Erkennung 55 % aller im Datensatz als kritisch eingestuften KI-bezogenen Warnungen. Die Regel identifizierte die Windows-Binärdatei Expand.exe als mögliches Werkzeug für seitliche Übertragungen.

Eine genauere Untersuchung zeigte, dass ein Coding-Agent eine Shell-Umgebung vorbereitete. Die Aktivität war für diesen Workflow normal, auch wenn ihre einzelnen technischen Signale Angreiferverhalten ähnelten.

Eine herkömmliche Schweregradkennzeichnung hätte diese Warnungen weit oben in die Warteschlange eines Analysten gestellt. Kontext führte zu einem automatischen Abschluss. Dieser Unterschied wird kostspielig, wenn sich dasselbe Muster über Tausende von Endpunkten wiederholt.

Die Studie zeigt nicht, dass alle KI-Warnungen mit hohem Schweregrad harmlos sind. Sie zeigt, dass der Schweregrad an Bedeutung verliert, wenn die Erkennungslogik normales Agentenverhalten nicht erkennen kann.

Dies ist die erste operative Veränderung für SOC-Verantwortliche. KI-Aktivität benötigt eine eigene Baseline, einschließlich genehmigter Tools, erwarteter übergeordneter Prozesse, üblicher Ziele und erlaubter Aktionen. Ohne diese Baseline wird Wachstum bei der Einführung zu Wachstum bei falscher Dringlichkeit.

Unternehmensweite KI-Einführung verändert die Struktur des Warnungsstroms

Unternehmens-KI erzeugt gleichzeitig zwei Sicherheitsströme: auffällige Agentenausführung und die stille Bewegung von Unternehmensdaten.

Der auffällige Strom stammt vor allem von technischen Nutzern. Coding-Agenten können Skripte erstellen, Interpreter starten, Pakete installieren, Repositories untersuchen, Ports öffnen oder Entwicklungswerkzeuge ausführen. Jede Aktion kann einer Phase eines Eindringens ähneln.

Ein Entwickler könnte einen Agenten bitten, einen lokalen Testserver zu starten. Der Agent könnte PowerShell starten, einen ungenutzten Port finden, Python ausführen und Ausgaben in Projektprotokolle umleiten. Ein Endpunktprodukt sieht eine ungewöhnliche Prozesskette, bevor es ein harmloses Entwicklungsziel erkennt.

Intezer stellte fest, dass eine signierte OpenAI Codex-Sandbox-Binärdatei dieses Muster erzeugte. PowerShell startete anschließend cmd.exe, python.exe und conhost.exe, während eine lokale Projektumgebung vorbereitet wurde.

Eine herkömmliche Regel interpretierte die Abfolge als mögliche Reverse Shell. Der Befehlstext zeigte stattdessen lokale Orchestrierung auf 127.0.0.1, der Loopback-Adresse für den Zugriff auf denselben Computer.

Installer führen zu ähnlichen Kollisionen. Intezer berichtete, dass der legitime Claude Desktop-Installer Erkennungen auslöste, die mit Ransomware-Verhalten und codierter PowerShell-Ausführung verbunden sind. Die Codesignatur bestätigte die Identität des Pakets, doch Verhaltensregeln stuften die Installationsabfolge weiterhin als verdächtig ein.

Das macht verhaltensbasierte Erkennung nicht überflüssig. Signierte Software kann bösartig werden, und vertrauenswürdige Anwendungen können missbraucht werden. Es bedeutet, dass die Erkennung zusätzlichen Kontext benötigt, bevor ein Analyst eine Absicht zuordnen kann.

Der stille Strom entsteht durch nichttechnische Nutzung. Mitarbeitende können einem KI-Dienst Zugriff auf Unternehmensaccounts gewähren, Dokumente hochladen oder sensible Inhalte in Prompts einfügen. Diese Aktionen erzeugen möglicherweise nie einen ungewöhnlichen Endpunktprozess.

Intezer beobachtete OAuth-Einwilligungen für ChatGPT über mehrere Mandanten hinweg. Außerdem wurden erste Anmeldungen bei einer OpenAI-Anwendung sowie bei einem Kunden eine Gruppe von Datenschutzwarnungen im Zusammenhang mit Uploads generativer KI festgestellt.

Die meisten Ereignisse waren unbedenklich. Dennoch handelte es sich um Unternehmensinformationen, die in Dienste außerhalb der unmittelbaren Kontrolle des Endpunkts gelangten.

Diese Unterscheidung erklärt, warum das Blockieren einiger ausführbarer Dateien die Sicherheit von Unternehmens-KI nicht lösen kann. Ein Teil des Risikos liegt in Prozessen. Ein anderer Teil liegt in Browsersitzungen, Identitätsberechtigungen, Softwareintegrationen und Datenflüssen.

Ein nützliches Inventar benötigt daher mehr als eine Liste genehmigter Anwendungen. Es muss Nutzer, Identitäten, Agenten, Erweiterungen, OAuth-Freigaben, Datenziele und die Ressourcen verbinden, auf die jedes Tool zugreifen kann.

Diese Arbeit reicht über das SOC hinaus. Identitätsteams verwalten Einwilligungen und Zugriffe. Data-Governance-Teams definieren sensible Informationen. Engineering-Verantwortliche entscheiden, welche Agentenkonfigurationen akzeptabel sind.

Einkaufs- und Rechtsteams bewerten die Bedingungen für die Verarbeitung durch Dritte. Geschäftsverantwortliche entscheiden, ob Mitarbeitende praktikable genehmigte Alternativen haben.

Das SOC bleibt der Punkt, an dem diese Signale zusammenlaufen. Es erhält die Warnungen, wenn ein Tool einen verdächtigen Befehl startet, einen Tunnel öffnet oder geschützte Informationen berührt.

Die unternehmensweite Einführung verändert auch die Bedeutung der Attribution. Vor universell nutzbaren Agenten spiegelte ein unter einem Nutzerkonto ausgeführter Befehl in der Regel entweder den Nutzer selbst oder einen Angreifer wider, der dieses Konto kontrollierte.

Ein Agent führt einen dritten Akteur ein. Er arbeitet mit der Autorität des Nutzers, kann aber Befehle auswählen, die der Nutzer nie überprüft hat. Die Aktivität gehört zum Konto, ohne die direkte Handlung des Kontoinhabers vollständig widerzuspiegeln.

Diese Lücke ist besonders für Incident-Timelines wichtig. Analysten müssen wissen, ob ein Mensch einen Befehl eingetippt hat, ein genehmigter Agent ihn generierte oder bösartige Inhalte den Agenten manipulierten.

Sicherheitsteams benötigen zudem dauerhaften organisatorischen Kontext. Eine durchsuchbare Engineering-Wissensdatenbank kann genehmigte Workflows und lokale technische Entscheidungen festhalten. Die Dokumentation muss jedoch mit aktuellen Identitäts- und Endpunktbelegen verknüpft sein, um die Triage zu unterstützen.

Das operative Ziel ist nicht perfekte Sichtbarkeit in jeden Prompt. Es geht um genügend verifizierten Kontext, um genehmigte Arbeit, unsicheres Verhalten und gegnerische Aktivitäten zu unterscheiden, ohne Mitarbeitende umfassender als nötig zu überwachen.

Legacy-Erkennungslogik kollidiert mit normalem Agentenverhalten

Der zentrale Konflikt besteht zwischen Legacy-Erkennungslogik und dem Kontext von KI-Agenten, nicht zwischen menschlichen Analysten und Automatisierung.

Sicherheitsprodukte erkennen häufig Techniken statt Absichten. Zugriff auf Zugangsdaten, Befehlsausführung, Persistenz, Tunneling und Datensammlung bleiben gefährlich, unabhängig davon, welche Anwendung sie initiiert.

KI-Agenten verkomplizieren dieses Modell, weil legitime Tools inzwischen Kombinationen von Aktionen ausführen, die früher vor allem mit Administratoren, Penetrationstestern und Angreifern verbunden waren. Die Überschneidung ist strukturell, nicht zufällig.

Intezer fand bei den lautesten KI-bezogenen Erkennungsgruppen Unbedenklichkeitsraten zwischen 77 % und 99 %. Mehrere Regeln lagen bei KI-generiertem Verhalten in mehr als vier von fünf Fällen falsch.

Ein Beispiel betraf OpenAI Codex, das über Node.js mit Flags wie --yolo oder --dangerously-skip-permissions gestartet wurde. Die resultierenden Aktivitäten lösten Erkennungen aus, die mit ClickFix, deaktivierten Tools und DLL-Injection zusammenhängen.

Flags zum Umgehen von Berechtigungen entfernen Bestätigungsaufforderungen, bevor ein Agent Aktionen ausführt. Entwickler nutzen sie, um Unterbrechungen zu reduzieren, doch derselbe Komfort schwächt eine wichtige Kontrollgrenze.

Der ClickFix-Cluster stellte innerhalb von Intezers Erkenntnissen zu Fehlalarmen eine Ausnahme dar. Nur 37 % dieser Warnungen waren unbedenklich. Das macht nicht jede Warnung zu einem Angriff, verleiht dem Cluster jedoch einen höheren Untersuchungswert.

Hier scheitert simples Allowlisting. Codex, Claude oder Cursor pauschal als vertrauenswürdig zu erklären, würde Fehlalarme reduzieren, könnte aber auch unsichere Aktionen verbergen, die über diese Tools gestartet werden.

Der sicherere Ansatz bewertet die gesamte Kette. Das SOC sollte die signierte Anwendung, den initiierenden Nutzer, die Agentenkonfiguration, die angeforderte Aufgabe, untergeordnete Prozesse, aufgerufene Ressourcen, Netzwerkziele und die daraus resultierende Datenbewegung berücksichtigen.

MITREs AI Threat Matrix spiegelt diese umfassendere Sicht wider. Sie umfasst Agenten-Tool-Aufrufe, das Abgreifen von Zugangsdaten, Prompt Injection, Reverse Shells und Exfiltration über KI-bezogene Mechanismen.

Diese Techniken zeigen, warum ein genehmigter Agent kein dauerhaftes pauschales Vertrauen erhalten kann. Das Tool kann legitim sein, während ein bestimmter Aufruf weiterhin unsicher bleibt.

Detection Engineering muss daher stärker bedingungsabhängig werden. Ein lokaler Server, der innerhalb eines bekannten Entwicklungs-Repositorys gestartet wird, kann Routine sein. Derselbe Interpreter, der von einem Finanzarbeitsplatz aus einen externen Tunnel erstellt, verdient eine andere Behandlung.

Dass ein Coding-Agent sein eigenes Konfigurationstoken liest, kann erwartbar sein. Das vollständige macOS-Schlüsselbund in eine temporäre Datei zu schreiben, steht dagegen in keinem angemessenen Verhältnis zu dieser Aufgabe.

Intezer beobachtete genau dieses Muster. Ein Agent verwendete security dump-keychain und leitete die Ausgabe beim Versuch, gespeicherte Zugangsdaten abzurufen, an einen temporären Speicherort weiter.

Die beabsichtigte Aufgabe erforderte keine böswillige Absicht. Die gewählte Methode legte dennoch mehr Informationen offen als nötig und schuf ein wertvolles Ziel auf dem Datenträger.

Ein weiterer Fall betraf einen KI-Code-Editor, der PowerShell und anschließend ngrok startete, einen Dienst, der über das Internet erreichbare Tunnel erstellt. Er öffnete einen benannten Reverse-Tunnel unter Verwendung des Authentifizierungstokens des Mitarbeiters.

Der Zweck des Nutzers könnte legitime Fehlerbehebung oder Entwicklung gewesen sein. Dennoch schuf die Aktion einen realen Weg vom öffentlichen Internet in eine Unternehmensumgebung.

Ein drittes Beispiel betraf Cursor, das eine Prozesskette initiierte, die eine bekannte Methode zum Auslesen von Arbeitsspeicher verwendete. Cursor startete PowerShell, das rundll32.exe und die MiniDump-Funktionalität in comsvcs.dll aufrief.

Diese Technik kann Geheimnisse aus dem Arbeitsspeicher von Prozessen extrahieren. Selbst wenn ein Agent sie zur Fehlerbehebung auswählt, schafft dieses Verhalten ein Risiko für den Zugriff auf Zugangsdaten, das untersucht werden sollte.

Diese Beispiele sprechen für eine Richtlinie, die auf Aktionen und Grenzen basiert, nicht nur auf Produktnamen. Auch zugelassene Agents sollten Beschränkungen beim Zugriff auf Credential Stores, Produktionssysteme, öffentliche Tunnel und sensible Repositories unterliegen.

Isolation kann helfen. Intezer empfiehlt, KI-Tools, sofern der Workflow dies zulässt, in eingeschränkten Umgebungen auszuführen, darunter Container oder virtuelle Maschinen.

Ein Container kapselt einen Prozess mit definierten Ressourcen und Zugriffsgrenzen. Eine virtuelle Maschine bietet eine getrennte Betriebsumgebung mit in vielen Konfigurationen stärkerer Isolation.

Keine der beiden Maßnahmen ist absolut. Container können falsch konfiguriert sein, während virtuelle Maschinen weiterhin Kontrollen für Identität, Netzwerk, Speicher und Updates benötigen. Beide können die Anzahl der Ressourcen verringern, die ein Agent standardmäßig erreicht.

Sie verbessern außerdem die Zuordnung. Aktivitäten, die aus einer zugewiesenen Agent-Umgebung stammen, lassen sich leichter von der gewöhnlichen Desktop-Aktivität eines Nutzers unterscheiden.

Die Umstellung erfordert sorgfältige Messung. Teams sollten False-Positive-Raten nach Erkennung, Agent, Konfiguration und Geschäftseinheit verfolgen. Sie sollten außerdem dokumentieren, welche Unterdrückungen später korrigiert werden mussten.

Eine pauschale Verringerung des Alert-Volumens ist kein Erfolg. Entscheidend ist, ob das Tuning vorhersehbares Rauschen entfernt, ohne Credential-Zugriffe, externe Exponierung oder die Bewegung sensibler Daten zu verbergen.

Die stillen KI-Sicherheitsrisiken sind wichtiger als die lauten Alerts

Die folgenreichsten KI-Risiken in Intezers Daten waren häufig Exponierungen, keine bestätigten Kompromittierungen oder Alerts mit maximalem Schweregrad.

Intezer stufte 5,8 % der KI-bezogenen Population als echte Sicherheitsrisiken ein. Diese Ereignisse bewiesen nicht, dass ein Angreifer Zugriff erlangt hatte. Sie zeigten Bedingungen, die eine spätere Kompromittierung folgenreicher machen könnten.

Das Umgehen von Berechtigungen war ein zentrales Beispiel. Ein Agent, der ohne Bestätigungsaufforderungen arbeitet, kann eine lange Sequenz ausführen, bevor ein Nutzer die Details sieht.

Dieses Design wird gefährlicher, wenn der Agent nicht vertrauenswürdigen Code, Websites, Tickets, E-Mails oder Dokumente liest. In diesen Quellen verborgene böswillige Anweisungen können die Entscheidungen eines Agents beeinflussen.

Prompt Injection ist der Versuch, ein Modell dazu zu bringen, feindliche Anweisungen zu befolgen, die in seiner Eingabe eingebettet sind. Sie wird schwerwiegender, wenn ein Agent Tools nutzen oder Geschäftsdaten erreichen kann.

Eine indirekte Injection kann über Inhalte eintreffen, die der Nutzer niemals als Anweisung betrachtet. Eine Webseite oder Repository-Datei kann Text enthalten, der für den Agent statt für den menschlichen Leser bestimmt ist.

Das Profil für generative KI von NIST empfiehlt, KI-Risiken während des gesamten Systemlebenszyklus zu steuern, zu erfassen, zu messen und zu managen. Dieses Modell passt zu Unternehmens-Agents, weil Risiken Technologie- und Organisationsgrenzen überschreiten.

Ein Endpoint-Alert kann den finalen Befehl offenlegen, aber den Inhalt übersehen, der das Modell beeinflusst hat. Ein Identitätsprotokoll kann eine OAuth-Freigabe zeigen, ohne offenzulegen, welche Dokumente später in den Dienst gelangten.

Ein Produkt zur Verhinderung von Datenverlust kann einen Upload erkennen, aber den geschäftlichen Zweck nicht kennen. Jedes Tool beobachtet nur ein Fragment des Ereignisses.

Das SOC benötigt Korrelation über diese Fragmente hinweg. Es sollte Nutzer, Agent, Prompt-Quelle, Berechtigungen, Prozessaktivität, Ziel und Datenklassifizierung verbinden, wenn die verfügbare Telemetrie dies zulässt.

Das erfordert nicht, jedes Mitarbeitergespräch zu sammeln. Datenschutz und Verhältnismäßigkeit bleiben wichtig. Organisationen sollten die Mindestmenge an Belegen erfassen, die erforderlich ist, um etablierte Richtlinien durchzusetzen und relevante Risiken zu untersuchen.

Klare Richtlinien sind auch wichtig, weil dieselbe Aktion je nach Abteilung unterschiedliche Folgen haben kann. Das Hochladen öffentlicher Marketingtexte unterscheidet sich vom Hochladen von Kundendaten, unveröffentlichten Finanzinformationen oder Quellcode mit Geheimnissen.

Zugelassene Tools beseitigen diesen Unterschied nicht. Unternehmenslizenzen können administrative Kontrollen verbessern, aber sie können nicht entscheiden, ob jedes Datenstück in jeden Prompt gehört.

OAuth-Einwilligungen verdienen ähnliche Aufmerksamkeit. OAuth ermöglicht einem Nutzer, eine Anwendung zu autorisieren, ohne ein Passwort preiszugeben. Der daraus resultierende Token kann dennoch umfangreichen Zugriff auf E-Mails, Dateien, Kalender oder andere Dienste gewähren.

Die angeforderten Scopes einer legitimen KI-Anwendung können die unmittelbare Aufgabe übersteigen. Ein kompromittiertes Konto oder manipulierter Agent kann diese Berechtigungen dann auf eine Weise nutzen, die der Mitarbeiter nie beabsichtigt hat.

SOC-Teams sollten Einwilligungen mit hohem Risiko, ungewöhnliche erstmals verwendete Anwendungen und Berechtigungen prüfen, die sensible Systeme überschreiten. Sie sollten Nutzern zudem einen schnellen Weg bieten, zugelassene Integrationen anzufordern.

Wenn Governance zu langsam vorankommt, werden Mitarbeitende sie umgehen. Dadurch entsteht Shadow AI, also Tools oder Nutzungen, die außerhalb etablierter organisatorischer Genehmigung und Aufsicht betrieben werden.

Die Antwort ist kein wahlloses Verbot. Ein Verbot kann sichtbare Aktivitäten verringern, während es nützliche Arbeit in private Konten und nicht verwaltete Browsersitzungen drängt.

Sicherheitsteams benötigen einen praktikablen, genehmigten Weg mit angemessenen Kontrollen. Mitarbeitende sollten verstehen, welche Tools sie nutzen dürfen, welche Informationen sie teilen können und wann ein Agent eine isolierte Umgebung benötigt.

CISA und internationale Partner betonten in ihren KI-Sicherheitsrichtlinien in ähnlicher Weise Verantwortlichkeit, Transparenz und sicheres Design. Diese Prinzipien gelten für Anbieter, aber auch Unternehmenskäufer müssen sie bewerten.

Beschaffungsfragen sollten Protokollierung, Aufbewahrung, Modelltraining, Zugriffsscopes, administrative Kontrollen, Benachrichtigung bei Sicherheitsvorfällen und Datenlöschung abdecken. Technische Tests sollten wichtige Behauptungen, wo immer möglich, überprüfen.

SOC-Playbooks müssen Richtlinien dann in Untersuchungsschritte übersetzen. Ein Analyst, der einen unbekannten Tunnel sieht, sollte den verantwortlichen Agent, Nutzer, die Aufgabe und das Ziel schnell identifizieren können.

Das Playbook sollte das Ereignis nicht automatisch schließen, nur weil ein zugelassenes Tool es gestartet hat. Es sollte feststellen, ob die Aktion innerhalb einer genehmigten Grenze blieb.

Dasselbe Prinzip gilt für den Zugriff auf Zugangsdaten. Ein Agent, der ein begrenztes Secret über einen zugelassenen Broker liest, unterscheidet sich vom Export eines vollständigen Credential Stores.

Dieses handlungsorientierte Modell erhält nützliche Erkennungen und reduziert zugleich vermeidbares Rauschen. Es richtet Alerts außerdem an den Risiken aus, die die Organisation tatsächlich zu managen beschlossen hat.

Was Intezers Daten noch nicht belegen

Die Ergebnisse von Intezer sind eine nützliche operative Momentaufnahme, aber keine universelle Messung des KI-Risikos in Unternehmen.

Die Studie umfasst Alerts, die in Umgebungen sichtbar waren, die mit Intezers Plattform verbunden sind. Sie repräsentiert nicht jedes Unternehmen, jeden Security Stack, jede Branche, jede Region oder jeden Stil der KI-Bereitstellung.

Intezer veröffentlichte im Artikel weder eine vollständige Kundenzahl noch eine detaillierte Aufschlüsselung nach Sektoren. Das Unternehmen anonymisierte außerdem Informationen zu Kunden, Hosts, Nutzern und Identifikatoren.

Das schützt Organisationen, begrenzt jedoch die unabhängige Reproduktion. Leser können nicht feststellen, wie stark eine große Umgebung jede Kategorie beeinflusste, abgesehen von den Beispielen, die Intezer offenlegte.

Die Forschung misst außerdem Alerts, nicht sämtliche KI-Aktivitäten. Eine Aktion, die nie eine verbundene Kontrolle auslöst, kann im Datensatz fehlen.

Das ist besonders relevant für browserbasierte Tools, private Konten, nicht genehmigte Erweiterungen und Datenaustausche, die Endpoint-Produkte nicht beobachten können. Unauffällige Nutzung kann gegenüber ausführbarer Agent-Aktivität unterrepräsentiert sein.

Die Rauschquote von 94,1 % sollte daher die Optimierung von Erkennungen leiten, nicht zu einer universellen False-Positive-Rate werden. Eine andere Organisation kann andere Agents, Richtlinien, Nutzer oder Telemetrie haben.

Auch der Angriffsanteil von 0,02 % erfordert eine sorgfältige Interpretation. Er zeigt nicht, dass KI-Agents grundsätzlich sicher sind oder dass agentenunterstützte Angriffe überall vernachlässigbar sind.

Er zeigt, dass bestätigte Angriffe innerhalb dieser spezifischen KI-bezogenen Alert-Population äußerst selten waren. Intezer erklärte, dass keiner dieser bestätigten Angriffe aus einem eigenen Agent einer Organisation resultierte, der eine Kompromittierung verursachte.

Die tatsächlich identifizierten Angriffe nutzten bekannte KI-Marken als Phishing-Köder. Angreifer imitierten Namen wie Anthropic, Gemini und OpenAI, weil Mitarbeitende sie zunehmend kennen und ihnen vertrauen.

Eine E-Mail verwies auf eine angebliche Zusammenarbeit mit Anthropic und eine Zahlungsanforderung. Eine andere nutzte eine gefälschte Gemini-Werbeeinladung mit Infrastruktur, die nicht zu Google gehörte.

Eine dritte imitierte eine OpenAI-Partnerveranstaltung und nutzte legitime Zoom-Infrastruktur, um die Einladung glaubwürdig erscheinen zu lassen. In jedem Fall verstärkte die KI-Einführung den Vorwand, statt eine neue Angriffstechnik bereitzustellen.

Diese Unterscheidung ist nützlich, kann sich aber ändern. Breitere Agent-Berechtigungen, stärkere autonome Fähigkeiten und tiefere Geschäftsintegrationen erhöhen die Folgen von Manipulation.

Das Fehlen vieler bestätigter, von Agents verursachter Kompromittierungen in diesem Datensatz ist kein Beleg dafür, dass künftige Bereitstellungen sicher bleiben werden. Es ist eine Ausgangsbasis, um den Übergang zu beobachten.

Auch Anreize von Anbietern verdienen Aufmerksamkeit. Intezer verkauft eine KI-SOC-Plattform und automatisierte Triage-Dienste. Seine Forschung hebt naturgemäß Probleme hervor, die kontextbezogene Untersuchungen und Automatisierung adressieren können.

Das entwertet die Daten nicht. Es bedeutet, dass Käufer die Ergebnisse mit ihrer eigenen Telemetrie, Red-Team-Erkenntnissen und Vorfallhistorie vergleichen sollten, bevor sie Kontrollen ändern.

Sicherheitsteams sollten prüfen, ob automatisierte Bewertungen in ihrer Umgebung präzise bleiben. Sie sollten unterdrückte Alerts stichprobenartig prüfen, unsichere Klassifizierungen überprüfen und spätere Belege überwachen, die einer früheren Entscheidung widersprechen.

Sie sollten außerdem den Unterschied zwischen verifizierten Ergebnissen und Anbieterbehauptungen dokumentieren. Intezer sagt beispielsweise, dass seine breitere Plattform Alerts in großem Umfang untersuchen kann, doch diese Studie validiert nicht unabhängig jede Leistungsbehauptung.

Die schwierigere Frage betrifft fehlende Signale. Ein SOC kann sichtbares Rauschen wegoptimieren und dennoch keine Abdeckung für nicht autorisierte Browser-Tools oder riskante Datenweitergabe haben.

Deshalb kann die Verringerung von Alerts nicht als einzige Erfolgskennzahl dienen. Teams benötigen außerdem eine Abdeckung des Agent-Inventars, die Anzahl riskanter Berechtigungen, Trends bei sensiblen Uploads und die Zeit, die erforderlich ist, um eine Aktion bis zu ihrer Quelle zurückzuverfolgen.

Eine Organisation mit weniger Alerts, aber ohne Sichtbarkeit in OAuth- oder Browser-Aktivitäten, hat ihre Sicherheit nicht unbedingt verbessert. Sie hat das Risiko möglicherweise außerhalb des gemessenen Kanals verlagert.

Drei Signale werden zeigen, ob sich SOCs anpassen

Der nächste Test lautet, ob Sicherheitsteams den Kontext schneller verbessern können, als die KI-Aktivität wächst.

Das erste Signal ist die False-Positive-Performance bei agentenbezogenen Erkennungen. SOC-Verantwortliche sollten die Raten harmloser Ereignisse vor und nach der Optimierung der rauschintensivsten Regeln messen.

Eine erfolgreiche Änderung wird wiederholte Warnmeldungen von bekannten Installern, lokalen Entwicklungsservern und genehmigten Prozessketten reduzieren. Die Überprüfung von Berechtigungsumgehungen, Credential Dumping, externen Tunneln und ungewöhnlichen Datenbewegungen bleibt dabei erhalten.

Wenn die Rate gutartiger Ereignisse sinkt, ohne dass mehr Vorfälle übersehen werden, lernt das SOC das normale Verhalten von KI kennen. Wenn Analysten dieselben Muster weiterhin manuell schließen, überholt die Einführung die Detection Engineering weiterhin.

Das zweite Signal ist die unternehmensweite Abdeckung von Identitäts-, Browser-, Endpoint-, Cloud- und Datenkontrollen. Eine Liste installierter Coding Agents ist kein vollständiges KI-Inventar.

Teams sollten auf neue OAuth-Freigaben, erstmalige Anmeldungen bei KI-Anwendungen, nicht verwaltete Erweiterungen, die Nutzung persönlicher Konten und Verbindungen zwischen Agents und sensiblen Repositories achten.

Eine bessere Abdeckung wird zunächst mehr unauffällige Risiken sichtbar machen. Dieser vorübergehende Anstieg sollte nicht mit einer Verschlechterung der Sicherheit verwechselt werden. Bessere Messung macht bestehende Risiken häufig sichtbar, bevor Kontrollen sie verringern.

Das dritte Signal ist, ob Agent-Bereitstellungen standardmäßig eine eingeschränkte Ausführung verwenden. Berechtigungsabfragen, eingeschränkte Zugangsdaten, isolierte Umgebungen und begrenzter Netzwerkzugriff schaffen messbare Grenzen.

Unternehmen sollten den Anteil der mit Umgehungs-Flags gestarteten Agents beobachten. Sie sollten außerdem überwachen, wie häufig Agents verbotene Befehle versuchen auszuführen – selbst wenn eine Kontrolle die Ausführung blockiert.

Eine sinkende Umgehungsrate würde dafür sprechen, dass Governance operativ wird. Anhaltendes Wachstum würde zeigen, dass Bequemlichkeit weiterhin Vorrang vor Eindämmung hat.

Sicherheitstests sollten realistische Agent-Workflows umfassen, nicht nur Modell-Prompts. Bei einer Bewertung können nicht vertrauenswürdige Anweisungen in Code, Dokumenten, Tickets oder Webinhalten platziert und die Reaktion des Agents beobachtet werden.

Ziel ist es, das gesamte System zu testen. Dazu gehören Identitätsberechtigungen, Tools, Memory, externe Inhalte, Ausführungskontrollen, Logging und menschliche Freigabe.

Intezer AI SOC alerts bieten einen frühen Einblick in diesen Wandel. Das zentrale Ergebnis ist nur auf den ersten Blick beruhigend. Bestätigte Angriffe waren selten, doch Exposition und operatives Rauschen nahmen bereits schnell zu.

Für SOC-Teams ist die unmittelbare Frage konkret: Können sie normales Agent-Verhalten identifizieren, ohne Agents pauschal zu vertrauen?

Beginnen Sie mit den Erkennungen, die die meisten wiederholten gutartigen Warnmeldungen erzeugen. Vergleichen Sie diese Optimierung anschließend mit Berechtigungsumgehungen, Credential-Zugriffen, Tunneln, OAuth-Freigaben und sensiblen Uploads. Wenn diese höherwertigen Signale leichter zu erkennen sind, passt sich das SOC an. Wenn die Anzahl der Warnmeldungen sinkt, während die Transparenz fragmentiert bleibt, ist die scheinbare Verbesserung lediglich leisere Unsicherheit.