In Teil 1 habe ich gezeigt, was KI im SOC nachweisbar leistet: rund 22 Prozent Geschwindigkeits-Plus in eng definierten Aufgaben. Was Marketing-Folien gerne weglassen, sind die Grenzen, gegen die jede ehrliche Implementation läuft. Die meisten technisch, eine aus der Human-Factors-Forschung. Keine ist eine Tuning-Frage. Keine verschwindet durch das nächste Modell-Release. Wer das anders sieht, muss erklären, wie die Architektur, die Augmentation produziert, plötzlich keine Adversarial-Angreifbarkeit mehr produziert. Ich warte auf das Argument.
TL;DR: KI im SOC hat vier strukturelle Grenzen. LLM-Triage-Agenten sind selbst angreifbar (Prompt-Injection durch Logs, IOC-Feeds, Mail-Bodies), ML-Detektoren brechen bei novel TTPs systematisch ein, generic LLMs haben kein Mandanten-Gedächtnis, und Automation Bias kommt vom Menschen, nicht vom Tool. Keine davon ist eine Tuning-Frage. Keine verschwindet durch das nächste Modell-Release.
Dein LLM-Triage-Agent ist selbst angreifbar
Das Problem ist alt, der Vektor neu. Wenn ein LLM-basierter Triage-Agent Daten ingestiert, die ein Angreifer beeinflussen kann, und das tut er per Definition (Log-Files, IOC-Feeds, Mail-Bodies, Threat-Feeds, alles was über die Sensoren reinkommt), dann hat der Angreifer einen Prompt-Injection-Pfad. Greshake et al. haben das Konzept 2023 als „Indirect Prompt Injection" formalisiert (arXiv:2302.12173). USENIX Security 2024 lieferte das systematische Benchmark mit fünf Angriffen gegen zehn Defenses gegen zehn LLMs in sieben Tasks. Selbst kombinierte State-of-the-Art-Defenses lassen substanzielle Restrisiken offen (Liu et al. 2024).
Das ist kein Lab-Problem. Im November 2025 wurde unter CVE-2025-32711 die EchoLeak-Schwachstelle bekannt. Eine „poisoned email" exfiltriert Daten aus einem LLM-Mail-Assistenten ohne User-Interaktion. Eine Studie von Carlini et al. zum Magika-Klassifier von Google zeigt, dass 13 Bytes Änderung in einer Datei das Routing in 90 Prozent der Fälle umgehen, und auch nach Defense-Hardening reichen 50 Bytes für 20 Prozent Erfolg (arXiv:2510.01676). NIST hat in AI 100-2 die Klassen Evasion, Poisoning und Privacy-Angriffe gegen ML und LLMs systematisch katalogisiert. Das Fazit: keine Silver-Bullet-Mitigation (NIST 2023/2025).
Mich frustriert daran am meisten, wie selten Threat-Models das aufgreifen. Die Hoffnung, das Problem durch Prompt-Hardening, Output-Filtering oder Defense-in-Depth zu lösen, ist verständlich. Sie funktioniert in eng begrenzten Settings. Aber die strukturelle Eigenschaft bleibt. LLMs verarbeiten Text als Anweisung, der Angreifer kontrolliert einen Teil des Texts. Wer einen LLM-Triage-Agent in Produktion stellt, betreibt einen Service, der strukturell angreifbar ist. Gehört explizit ins Threat-Model. Nicht in den Caveat-Anhang einer Slide-Präsentation. Und nein, die nächste Modell-Generation löst das nicht. Die Architektur, die Prompt-Injection ermöglicht, ist die gleiche, die Augmentation überhaupt erst macht. Wer’s anders sieht, soll mir die Mitigation zeigen, die NIST nicht gefunden hat.
Novel TTPs brechen ML-Detektoren systematisch
ML-basierte Klassifizierer brechen ein, wenn die Telemetrie der Angreifer nicht der Telemetrie der Trainings-Daten entspricht. Keine Anekdote. Gemessen. Catania und Garcia haben die Inter-Dataset-Generalisierung von ML-NIDS systematisch untersucht. Für netzwerkzentrische Klassen wie Brute-Force, DoS und DDoS bleiben die Verluste unter fünf Prozent. Bei Botnet-Erkennung fällt der Recall um 35 Prozent. Bei Web-Attack und Infiltration bricht die Precision teilweise vollständig ein (PMC9960990).
Die Forschung bestätigt das aus mehreren Richtungen. Corsini und Yang zeigen, dass etablierte Out-of-Distribution-Techniken aus Computer Vision und NLP nicht direkt auf NIDS übertragbar sind (arXiv:2308.14376). Wilkie et al. dokumentieren, dass Zero-Day-NIDS auch mit modernsten Contrastive-Learning-Ansätzen messbar hinter den Werten für bekannte Klassen zurückbleibt (arXiv:2601.09902).
Wer behauptet, ein ML-Detektor erkennt zuverlässig, was er nie gesehen hat, behauptet etwas, das die Forschung methodisch ausschliesst. Nicht polemisch. Studienlage. Augmentation für bekannte Klassen funktioniert. Detection für genuinely-novel TTPs bleibt eine offene Frage. Die ehrliche Antwort ist seit zwanzig Jahren dieselbe: hypothesengeführtes Hunting durch einen Senior-Analysten, der Threat-Intel auf eigene Telemetrie übersetzt. KI kann darin Subtasks beschleunigen. Sie ist nicht die Antwort.
LLMs haben kein Mandanten-Gedächtnis
Die strukturelle Eigenschaft mit dem geringsten Forschungs-Volumen, aber dem grössten Praxis-Effekt: LLMs haben kein langfristiges, mandanten-spezifisches Gedächtnis. Das Asset-Inventar der Mandanten-Umgebung, die Detection-History, die Business-Logik einzelner Applikationen, die organisatorischen Quirks („wir whitelisten dieses Tool, weil das Engineering-Team es einmal die Woche braucht"). Nichts davon kennt der LLM, ausser es wird im Prompt-Kontext mitgegeben.
Genau hier setzt Sales-Material an: „Mandanten-Aware Detection". In der Praxis steht dahinter eine RAG-Pipeline, die Mandanten-Daten zur Laufzeit ins Prompt-Window injiziert, mit Compute-Kosten, die der Anbieter vorab nicht beziffert, und einem zusätzlichen Prompt-Injection-Vektor obendrauf. Nicht falsch, aber Engineering. Nicht der „Out-of-the-box-Mandanten-Aware-Agent", den die Folie verspricht. Mich ärgert die Kluft zwischen Etikett und Realität, weil sie den Investment-Case verzerrt: was als Plug-and-Play verkauft wird, ist in Wahrheit ein Engineering-Projekt mit eigenem Budget. Ohne diese Klarstellung kauft der Kunde ein Versprechen, das er später selbst bauen muss.
Sworna et al. haben die Realität in einer empirischen Single-SOC-Studie aufgefangen. LLMs werden vor allem in Mikrotasks genutzt. Log-Summarization, Skript-Erklärung, Notiz-Drafts. Investigative Aufgaben bleiben Analyst-autonom, weil sie genau diesen Mandanten-Kontext brauchen (arXiv:2508.18947). Die ENISA-Bewertung in den AI-Threat-Landscape-Reports ergänzt: Mandanten-Kontext und Threat-Intel-Korrelation sind nicht durch generisches GPT-Wissen ersetzbar.
„End-to-End-KI-Triage ohne Kontext-Engineering" gibt es als Marketing-Versprechen. In der Praxis sehe ich es nicht funktionieren. Was funktioniert, ist KI in eng begrenzten Mikrotasks plus einem expliziten Mandanten-Kontext-Layer, gebaut, dokumentiert und compute-budgetiert von einem Engineer, der die Limits kennt.
Automation Bias ist menschlich, nicht technisch
Die letzte Grenze kommt nicht aus der Cyber-Forschung, sondern aus der Aviation- und ICU-Forschung. Stanton und Plant haben in einer 2025-MDPI-Aerospace-Arbeit dokumentiert, dass Automation Bias und Complacency, also der „looking-but-not-seeing"-Effekt, bei dem trainierte Operatoren eine Fehl-Empfehlung des Systems übernehmen, ohne sie zu prüfen, in der Cockpit-Forschung prävalent und durch Training nicht zuverlässig adressierbar sind (MDPI Aerospace 5/2/42). Eine Critical-Care-Studie mit 80 Stakeholdern kommt zur selben Position für ICU-Settings (PMC11301121).
Was mich an dieser Forschung am meisten beunruhigt, ist nicht die Existenz des Effekts. Es ist die Tatsache, dass Aviation seit fünf Jahrzehnten mit Cockpit-Resource-Management-Curricula daran arbeitet, und ihn trotzdem nicht eliminieren konnte. Cybersecurity wird’s nicht in fünf Jahren schaffen, was Aviation in fünfzig nicht geschafft hat. Die Übertragung auf SOC-Operationen ist unbequem. Wenn ein Triage-Agent Empfehlungen ausspielt, übernimmt der Analyst sie unter Zeitdruck häufiger, als er sie prüft. Aviation schafft Reduktion. Keine Eliminierung.
Wer KI-Augmentation in einem SOC einsetzt, kauft also nicht nur ein Detection-Plus. Er kauft auch ein Aufmerksamkeits-Risiko des Teams. Wer das Risiko nicht im Assessment dokumentiert, kauft es trotzdem. Er weiss nur nicht, was er hat.
Was das in der Praxis heisst
Diese Grenzen verschwinden nicht durch das nächste Modell-Release. Die Architektur, die Adversarial-Angreifbarkeit produziert, ist dieselbe, die Productivity-Augmentation produziert. Wer KI-Augmentation in einem SOC einsetzen will, baut um diese Grenzen herum. Wer sie ignoriert, baut auf Hoffnung. Hoffnung skaliert in der Defensive nicht. In der Offensive übrigens auch nicht. Nur dort merkt’s der Angreifer später.
In Teil 3 geht es um die organisatorischen Konsequenzen. Was diese Grenzen für Hiring, Training und Architektur in einem Defensiv-Team bedeuten. Und warum „weniger Personal" als Antwort auf KI-Augmentation regelmässig zurückgenommen werden muss.
Teil 2 von 5 dieser Reihe zu KI im defensiven Cyber, Augmentation, nicht Ablösung:
- Teil 1, Was die Daten tragen
- Teil 2, Wo Augmentation aufhört (aktuell)
- Teil 3, Was es für SOC-Teams heisst
- Teil 4, KI gegen KI
- Teil 5, Was wie doch gehen könnte