Konzerne ab 1000 Mitarbeitern betreiben 2026 im Schnitt mehr als ein Dutzend LLM-Anwendungen und Agenten in produktionsnahen Umgebungen. Was unter dem Begriff Generative AI auf Strategiefolien erscheint, bedeutet operativ produktive Systeme mit Zugriff auf interne Wissensbasen, Kundendaten und ausführende Tools. Die Sicherheitsabteilung prüft diese Systeme mit den gleichen Methoden, die für klassische Webanwendungen funktioniert haben. Das Ergebnis ist eine Lücke, die im aktuellen Risikoprofil sichtbar werden muss. Wer Verantwortung trägt, sollte verstehen, warum diese Lücke entstanden ist, warum sie wächst und wie sich der Vorstand strukturell absichert, ohne den Geschäftsbetrieb zu blockieren. Dieser Beitrag ordnet die Angriffsfläche entlang der drei relevanten Schichten ein, erklärt, warum klassische Werkzeuge versagen, und beschreibt die Governance-Kadenz, mit der sich das Risiko in den nächsten 90 Tagen sichtbar, steuerbar und vor Aufsicht und Prüfungsausschuss verteidigungsfähig machen lässt.
Drei Schichten, drei Risikoklassen
LLM-Systeme bestehen aus drei Schichten mit jeweils eigenem Angriffsprofil. Auf der Modellschicht greifen Jailbreaks, adversariale Eingaben und Bypässe der Safety-Filter. Auf der Systemschicht entstehen Risiken durch Context-Vergiftung in RAG-Pipelines, durch Leakage interner Prompts und durch Datenabfluss über angebundene Werkzeuge. Auf der Agentenschicht geht es um Goal-Hijacking, Tool-Confusion und Memory-Poisoning. Jede Schicht erzeugt eigene Schadensszenarien: regulatorische Verstöße, Reputationsschäden, Datenabfluss, fehlerhafte Geschäftsentscheidungen. Wer nur eine Schicht betrachtet, übersieht zwei Drittel der relevanten Angriffsfläche und verfehlt damit den Auftrag der Sorgfaltspflicht.
Diese Dreiteilung ist kein technisches Detail, sondern eine Governance-Frage. Sie bestimmt, wer im Unternehmen für welche Klasse von Befunden zuständig ist, wie Eskalationspfade aussehen und welche Versicherungs- und Compliance-Implikationen sich ergeben. In regulierten Branchen wie Finanz, Versicherung und Pharma fordern Aufsichtsbehörden zunehmend einen dokumentierten Nachweis, dass alle drei Ebenen geprüft wurden. Wer den Nachweis nicht erbringen kann, riskiert nicht nur den Sicherheitsvorfall, sondern auch die Beanstandung im Audit. Damit wird Red Teaming aus einer technischen Aufgabe zu einer Anforderung an die Lieferfähigkeit der gesamten KI-Organisation.
Warum klassische AppSec-Tools versagen
SAST-Werkzeuge analysieren Quellcode. Der wirklich relevante Code einer LLM-Anwendung ist jedoch der Prompt, und der ist keine Programmiersprache, sondern natürliche Sprache. DAST-Werkzeuge prüfen HTTP-Endpunkte. Eine Prompt-Injection über ein harmlos wirkendes Freitextfeld produziert einen vollkommen gültigen HTTP-Request, der erst innerhalb der Modellantwort zur Sicherheitslücke wird. Pentest-Provider ohne LLM-Expertise melden in solchen Tests typischerweise einen sauberen Befund. Der Vorstand erhält ein grünes Audit, während die eigentliche Schwachstelle unentdeckt produktiv bleibt. Diese systematische Blindheit ist der Hauptgrund, warum spezialisierte adversariale Verfahren keine Option mehr sind, sondern Pflicht.
Red Teaming für LLMs verlangt einen anderen Werkzeugkasten und ein anderes Personalprofil. Statt Pattern-Matching auf bekannte CVE-Klassen arbeiten die Tester mit strukturierten Playbooks, die modell- und systemspezifisch erweitert werden. Sie kombinieren Angreifer-Kreativität mit Automatisierung über adversariale Frameworks und dokumentieren jeden Befund reproduzierbar. Der Aufwand pro Engagement ist höher als bei einem klassischen Pentest, der Erkenntnisgewinn ist es ebenfalls. Wer dieses Budget verweigert, spart an der falschen Stelle: Die Kosten eines erfolgreichen Angriffs auf einen produktiven Kunden-Agenten übersteigen die Kosten eines vollständigen Red Teaming Engagements regelmäßig um zwei Größenordnungen.
Ein reales Szenario aus der Beratungspraxis
In einem aktuellen Engagement haben wir einen Kunden-Support-Agenten getestet, der Zugriff auf eine interne Wissensbasis und ein Ticketsystem besaß. Auf der Modellschicht hielt der Agent alle gängigen Jailbreaks ab. Auf der Systemschicht gelang ein Angriff über ein manipuliertes Dokument in der Wissensbasis: Der Agent übernahm aus dem Dokument Anweisungen in sein nächstes Antwort-Template. Diese Anweisungen wurden anschließend auf der Agentenebene gegen das Ticketsystem ausgespielt und veränderten dort reale Tickets. Ohne die geschichtete Prüfung wäre dieser Pfad unsichtbar geblieben. Der Schaden hätte sich erst nach mehreren Wochen in Kundenbeschwerden und Compliance-Findings materialisiert.
Mit dem Red Teaming wurde der Befund vollständig dokumentiert, über Guardrails entschärft und im Retest verifiziert. Entscheidend war nicht der einzelne Befund, sondern die strukturierte Methodik, die solche Pfade reproduzierbar findet, statt sie dem Zufall zu überlassen. Diese Reproduzierbarkeit ist es, die einen Befund vor Wirtschaftsprüfer und Aufsicht verteidigungsfähig macht. Sie liefert dem Vorstand den Nachweis, dass das System nicht nur einmal geprüft wurde, sondern in einer Methodik geprüft ist, die sich mit jedem Modellupdate erneut anwenden lässt. Genau diese Wiederholbarkeit unterscheidet Red Teaming von einem punktuellen Sicherheitstest und macht aus einem technischen Befund einen verteidigungsfähigen Steuerungsnachweis. In der Folge konnte der Kunde nicht nur die unmittelbare Schwachstelle schließen, sondern auch ein Reporting-Format aufbauen, das identische Tests vor jedem produktiven Release automatisiert wiederholt und ihre Ergebnisse direkt in das Risikoreporting an den Vorstand überführt. Damit verändert sich der Charakter der Sicherheitsarbeit: Aus einer reaktiven Kette von Einzelmaßnahmen wird eine planbare Steuerungsaufgabe mit klarem Adressat im Vorstand.
Governance und Steuerung im Konzern
Red Teaming ist keine einmalige Aktivität, sondern ein Bestandteil des KI-Lebenszyklus. Vor Go-Live jeder Anwendung erfolgt ein vollständiges Assessment auf allen drei Schichten. Nach jedem signifikanten Modell- oder Tooling-Wechsel ein gezielter Retest. Quartalsweise ein Stichproben-Audit auf produktiven Systemen. Diese Kadenz lässt sich operativ in ein bestehendes ISMS einbetten und liefert dem CISO eine belastbare Datenbasis für sein Risikoreporting an Vorstand und Aufsichtsrat. Unternehmen, die diesen Rhythmus etablieren, reduzieren ihre Vorfallswahrscheinlichkeit deutlich und verbessern gleichzeitig ihre Verhandlungsposition mit Cyber-Versicherern.
Die Steuerung verlangt klare Rollen. Der CISO verantwortet das Rahmenwerk und die Kadenz. Die KI-Verantwortlichen liefern Systemdokumentation und Zugang zu Test-Umgebungen. Eine externe oder hybride Red Teaming Funktion bringt das spezialisierte Angreiferwissen ein, das intern selten in der nötigen Tiefe vorhanden ist. Die Befunde landen in einem zentralen Register mit Eigentümer, Schweregrad und Behebungsfrist. Wer diese Steuerung nicht baut, verliert den Überblick spätestens beim fünften produktiven Agenten. Wer sie früh aufbaut, schafft die Voraussetzung dafür, KI im Konzern skaliert und gleichzeitig auditfähig zu betreiben. In regulierten Branchen wird diese Aufstellung zunehmend zum Ausschlusskriterium in der Auswahl von Beratungs- und Plattformpartnern, weil Aufsichtsbehörden den Nachweis verlangen, dass die Organisation nicht nur einzelne Systeme prüft, sondern eine durchgängige Steuerung über alle produktiven LLM- und Agentenanwendungen verankert hat. Wer in diesem Punkt unscharf bleibt, verliert Mandate und verlängert Beschaffungsprozesse, weil interne Compliance-Funktionen Argumente nachfordern, die schon im Angebot hätten geliefert sein müssen.
Fazit und Empfehlung
LLM- und Agent-Sicherheit ist keine Spezialdisziplin der IT, sondern ein Vorstandsthema. Die Angriffsfläche entsteht aus Modell-, System- und Agentenschicht gleichzeitig, klassische AppSec-Werkzeuge erfassen sie nicht, und der Schaden eines erfolgreichen Angriffs trifft Marke, Bilanz und regulatorischen Status gleichermaßen. Empfehlung für die nächsten 90 Tage: Drei produktive oder produktionsnahe LLM-Anwendungen identifizieren, ein geschichtetes Red Teaming auf allen drei Ebenen beauftragen, die Befunde mit Eigentümer und Behebungsfrist in das bestehende Risikoregister überführen und parallel eine Kadenz aus Pre-Go-Live-Test, Retest und Stichproben-Audit in der KI-Governance verankern. Damit wird das Risiko sichtbar, steuerbar und im Aufsichtsrat verteidigungsfähig.
ECODYNAMICS führt LLM- und Agent-Red-Teaming-Engagements in der beschriebenen Methodik durch, von der Erstbewertung bis zur Etablierung einer dauerhaften Steuerungsfunktion in Ihrer Organisation. Unsere Teams kombinieren Senior-Profile aus offensiver Sicherheit mit Erfahrung aus mehr als 65 produktiven KI-Projekten. Sie erhalten ein priorisiertes Findings-Register, konkrete Guardrails und ein Reporting-Format, das ohne weitere Übersetzung in Vorstand und Prüfungsausschuss eingebracht werden kann. Auf Wunsch beginnen wir mit einem zweiwöchigen Kompakt-Assessment einer einzelnen Anwendung, dessen Ergebnis als Entscheidungsgrundlage für ein vollständiges Programm dient. Sprechen Sie uns an.