Versuche zuerst, es zu brechen
Bedrohungen, Controls und Governance sind die Behauptung, dass ein System sicher ist. Red Teaming ist die Disziplin, die diese Behauptung zu widerlegen versucht, bevor es ein Angreifer tut — die offensive Perspektive auf dieselbe Bedrohungsfläche.
Strukturiertes, gegnerisches Testen eines GenAI-Systems, erweitert für autonome Agenten. Es ist der empirische Nachweis, den die VALID-Kontrollfunktion verlangt. Die primäre Quelle ist der OWASP GenAI Red Teaming Guide (v1.0, 2025), für Agenten erweitert durch den CSA + OWASP Agentic AI Red Teaming Guide (2025).
Was Red Teaming ist — und was nicht
GenAI Red Teaming verbindet menschliche Expertise mit Automatisierung, um Lücken in Safety (der Nutzer), Security (des Betreibers), Trust (durch Nutzer und Partner) und Performance über den gesamten Stack aufzudecken — nicht nur am Modell. Es behält den klassischen Bogen Bedrohungsmodell → Recon → Exploit → Report bei, ergänzt ihn aber um vier Eigenschaften, die ein gewöhnlicher Penetrationstest nicht abdeckt:
- Breiterer Betrachtungsraum
Sozio-technische Risiken — Bias, schädliche Inhalte, übermäßiges Vertrauen — nicht nur technische Kompromittierung.
- Datenkomplexität
Das Kuratieren und Erzeugen großer, oft multimodaler gegnerischer Datensätze.
- Stochastische Auswertung
Ein nicht-deterministisches Ziel bedeutet, dass Befunde statistisch sind, über viele Versuche hinweg — kein einzelnes Bestanden/Durchgefallen.
- Schwellenwertbasierte Kriterien
Der Fokus verschiebt sich von einem einmaligen Einbruch hin zu statistischen Schwellenwerten und kontinuierlichem Monitoring.
Eine Eval-Suite ist ein Input für Red Teaming, niemals ein Ersatz: Eine Batterie automatisierter Tests zu bestehen macht ein System nicht sicher, und einen davon nicht zu bestehen macht es nicht unsicher. Benchmarks messen die aggregierte Fähigkeit gegen eine feste Menge; Red Teaming jagt den gegnerischen Grenzfall und das emergente, mehrstufige Versagen, das ein Benchmark niemals skriptet.
Die vier Pillars eines Engagements
Die Angriffsfläche ist in vier Pillars gegliedert, die vom Modell nach außen zu den Menschen und Agenten führen, die es nutzen. Wähle einen aus, um zu lesen, was er prüft.
Intrinsische Modellschwächen — Toxizität, Bias, Alignment-Fehler — sowie die Herkunft des Modells, das Einschleusen von Modell-Malware und die Vergiftung der Trainingsdaten-Pipeline (der Model Development Lifecycle).
Einen Agenten red-teamen: zwölf gegnerische Kategorien
Wenn das Ziel ein autonomes, Tool-nutzendes Multi-Agent-System ist, kann ein Angreifer Angriffe über Dienste und Gesprächsrunden hinweg verketten, die Entscheidungsfindung des Agenten manipulieren und die Zugriffskontrolle über Agenten-Interaktionen umgehen, statt direkt gegen das Modell vorzugehen. Der CSA + OWASP Guide katalogisiert zwölf Testkategorien — jede das offensive Gegenstück zu einer Bedrohung, die diese Referenz bereits dokumentiert.
- 01
Agent Authorization & Control Hijacking
Die Autorität oder den Kontrollpfad eines Agenten an sich reißen, um mit seinen Privilegien zu handeln.
- 02
Checker-Out-of-the-Loop
Den menschlichen/automatisierten Genehmiger aushebeln oder ermüden, sodass die Aufsicht aussetzt.
- 03
Agent Critical System Interaction
Den Agenten dazu treiben, zerstörerische oder folgenschwere Tools und Aktionen aufzurufen.
AngriffeT2Tool Misuse - 04
Goal & Instruction Manipulation
Das Ziel oder den Plan des Agenten über eingeschleuste Inhalte umschreiben.
- 05
Agent Hallucination Exploitation
Ein selbstbewusst falsches Output als Auslöser einer Aktion instrumentalisieren.
- 06
Agent Impact Chain & Blast Radius
Messen, wie weit sich eine einzelne Kompromittierung durch das System fortpflanzt.
- 07
Agent Knowledge Base Poisoning
Den Retrieval-/Wissensspeicher verfälschen, auf den sich der Agent gründet.
AngriffeT1Memory Poisoning - 08
Agent Memory & Context Manipulation
Persistenten Zustand einpflanzen, der spätere, unabhängige Sitzungen steuert.
AngriffeT1Memory Poisoning - 09
Multi-Agent Exploitation
Nachrichten zwischen zusammenarbeitenden Agenten fälschen, verändern oder wiedereinspielen.
- 10
Resource & Service Exhaustion
Compute, Rate-Limits oder Budget erschöpfen — bis hin zur denial of wallet.
AngriffeT4Resource Overload - 11
Supply Chain & Dependency Attacks
Ein Tool, Plugin, einen MCP-Server oder ein Paket kompromittieren, dem der Agent vertraut.
AngriffeT17Supply Chain Compromise - 12
Agent Untraceability
Handeln, ohne einen zuordenbaren, rekonstruierbaren Audit-Trail zu hinterlassen.
AngriffeT8Repudiation & Untraceability
Kontinuierliche gegnerische Assurance
Einen Agenten zu red-teamen ist ausdrücklich kein einmaliges Ereignis: Der Guide verlangt erneutes Testen nach jeder Korrektur sowie periodische, in den KI-Lebenszyklus integrierte Prüfungen, weil ein nicht-deterministisches System, das Verhalten zur Laufzeit zusammensetzt, von jedem punktuellen Ergebnis abdriftet. Die OWASP-Landschaft 2026 fasst koordiniertes gegnerisches Testen, defensive Validierung und kontinuierliches Feedback zu einer einzigen, lebenszyklusweiten Schleife zusammen.
Red Teaming ist die Art, wie die mit VALID getaggten AIUC-1-Anforderungen tatsächlich erfüllt werden — B001 (Drittanbieter-Tests der gegnerischen Robustheit), D002 (Tests auf Halluzinationen), D004 (Tests von Tool-Calls), C010/C011 (Tests auf schädliche und themenfremde Outputs) — teils in festem Takt, etwa die Bewertung schädlicher Outputs mindestens alle drei Monate. Zunehmend ist es auch eine regulatorische Erwartung: die Red-Team-Evaluierungen für systemische Risiken des EU AI Act und das bedrohungsgeleitete Penetration Testing der DORA, ausgeweitet auf die Entscheidungsfindung von Agenten und Muster des Tool-Aufrufs.
Ein Befund ist nicht das Ende der Schleife — er wird ins Risikomanagement überführt, behoben und erneut getestet, sodass „all gates green“ kontinuierlich neu verdient statt einmal zertifiziert wird.
Sicherheit