Red-Teaming ist das gezielte, gegnerische Testen eines Systems: Ein Team schlüpft in die Rolle des Angreifers und versucht mit allen realistischen Mitteln, das System zu täuschen, zu missbrauchen oder zum Fehlverhalten zu bringen, bevor es echte Angreifer oder der Alltag tun. Bei KI-Systemen heißt das: Prompts, Eingaben und Szenarien, die das Modell aus seinen Leitplanken drängen sollen, systematisch und dokumentiert.
Der Unterschied zum normalen Testen liegt in der Haltung. Ein klassischer Test prüft, ob das System tut, was es soll. Red-Teaming prüft, was sich das System alles abringen lässt, wenn jemand es ernsthaft darauf anlegt. Für KI-Agenten, die eigenständig E-Mails schreiben, Datensätze ändern oder Bestellungen auslösen, ist diese Prüfung keine Sicherheitsübung für Konzerne, sondern die Voraussetzung für einen verantwortbaren Go-Live.
Herkunft: vom Militär über die IT-Security zur KI
Der Begriff stammt aus militärischen Planspielen des Kalten Kriegs: Ein „rotes Team" simulierte den Gegner, um die eigenen Pläne gegen echte Gegnerschaft zu testen, ein „blaues Team" verteidigte. Die IT-Security übernahm das Modell: Red Teams greifen Netzwerke, Anwendungen und Mitarbeiter an (etwa per Phishing), Blue Teams erkennen und verteidigen. Aus dieser Tradition kommt auch die Abgrenzung zum Penetrationstest: Ein Pentest prüft definierte Systeme in definiertem Umfang auf bekannte Schwachstellen, Red-Teaming simuliert einen realen Gegner mit freier Zielwahl.
Mit generativer KI bekam der Begriff eine dritte Karriere. Modellanbieter testen ihre Systeme vor Veröffentlichung adversarial, und Unternehmen, die KI-Anwendungen einführen, übernehmen die Methode für den eigenen Einsatzkontext: Nicht das Modell an sich wird geprüft, sondern die konkrete Anwendung mit ihren Prompts, Datenquellen, Werkzeugen und Rechten.
Was Red-Teaming bei KI-Systemen besonders macht
Klassische Software verhält sich deterministisch: gleiche Eingabe, gleiche Ausgabe. Ein Sprachmodell nicht. Es kann auf dieselbe Eingabe unterschiedlich reagieren, und es lässt sich über natürliche Sprache angreifen, nicht nur über Code. Die Angriffsfläche ist damit jede Stelle, an der Text ins System gelangt: Nutzereingaben, E-Mails, Tickets, Dokumente, Webseiten, sogar Tool-Beschreibungen.
Die wichtigsten Angriffsklassen, die ein KI-Red-Team durchspielt:
- Direkte Prompt Injection: Der Angreifer schreibt seine Anweisungen direkt in die Eingabe („Ignoriere deine Regeln und …"). OWASP führt Prompt Injection als LLM01:2025 auf Platz eins der Risiken für LLM-Anwendungen.
- Indirekte Prompt Injection: Die Anweisung steckt in Inhalten, die das System verarbeitet, etwa in einer E-Mail, die ein Support-Agent liest, oder einer Webseite, die ein Recherche-Agent besucht. Für Agenten ist das der gefährlichste Vektor, weil die Injektion Handlungen auslösen kann.
- Jailbreaks: Umgehungen der Verhaltensregeln über Rollenspiele, Verschachtelungen oder schrittweises Aufweichen, damit das System Dinge tut oder sagt, die seine Guardrails verbieten.
- Tool-Missbrauch und Excessive Agency: Der Angreifer bringt einen Agenten dazu, seine Werkzeuge gegen den Betreiber einzusetzen: Daten exportieren, Massen-Mails versenden, Datensätze löschen. Je mehr Rechte der Agent hat, desto größer der mögliche Schaden.
- Datenexfiltration: Versuche, vertrauliche Inhalte aus Systemprompts, angebundenen Wissensquellen oder früheren Konversationen herauszulocken.
Gegen diese Angriffe hilft keine einzelne Maßnahme, sondern Verteidigung in Schichten: restriktive Rechte, damit ein kompromittierter Agent wenig anrichten kann, technische Guardrails für erkennbare Muster, menschliche Freigaben (Human-in-the-Loop) für kritische Aktionen, und eben Red-Teaming, das prüft, ob diese Schichten im Zusammenspiel halten. Genau dieses Zusammenspiel ist der Prüfgegenstand: Ein einzelner Filter lässt sich fast immer umgehen, eine gut gebaute Kette selten.
Wie ein Red-Teaming vor dem Go-Live abläuft
In der Praxis hat sich ein Ablauf in vier Schritten etabliert, der sich auch für Mittelständler ohne eigenes Security-Team umsetzen lässt:
| Schritt | Inhalt | Artefakt |
|---|---|---|
| 1. Szenarien definieren | Regelfälle, Randfälle und Angriffe für den konkreten Einsatzkontext, inklusive der Angriffsklassen oben | Szenario-Katalog |
| 2. Pass-/Fail-Kriterien festlegen | Vorab definieren, was „bestanden" heißt, z. B. null schreibende Aktionen ohne Freigabe, saubere Eskalation bei jedem Angriff | Kriterienliste |
| 3. Angreifen und protokollieren | Szenarien durchspielen, Verhalten dokumentieren, Befunde nach Schwere klassifizieren und beheben | Befund-Log |
| 4. In eine Eval-Suite überführen | Die Szenarien werden zur wiederholbaren Testsuite, die bei jeder Prompt-Änderung und jedem Modellwechsel erneut läuft | Eval-Suite / Regressionstests |
Schritt 4 ist der am häufigsten übersprungene und der wichtigste. Ein Red-Teaming als Einmalaktion veraltet mit der ersten Änderung: Ein Update des zugrunde liegenden Modells kann das Verhalten verschieben, ohne dass jemand den eigenen Code angefasst hat. Erst als dauerhafte Eval-Suite wird aus dem Test ein Kontrollinstrument, wie es eine belastbare KI-Governance verlangt.
Woher kommen die Szenarien?
Der Szenario-Katalog speist sich aus drei Quellen. Erstens aus den öffentlichen Bedrohungskatalogen: Die OWASP-Top-10 für LLM-Anwendungen und der Agentic-AI-Katalog liefern die Angriffsklassen, die jedes System abdecken sollte. Zweitens aus den eigenen Prozessen: Was wäre im konkreten Einsatz der teuerste Fehlgriff? Bei einem Beschaffungs-Agenten sind das andere Szenarien als bei einem Support-Agenten. Drittens aus dokumentierten Vorfällen anderer: Öffentliche Fälle wie der Replit-Vorfall vom Juli 2025, bei dem ein Coding-Agent trotz Code-Freeze eine Produktionsdatenbank löschte, lassen sich fast immer in eine Frage an das eigene System übersetzen: Könnte uns das passieren, und würde es jemand rechtzeitig sehen?
Typische Befundmuster
Über Projekte hinweg wiederholen sich beim KI-Red-Teaming bestimmte Befundklassen. Ganz vorn: Agenten mit deutlich mehr Rechten, als ihre Aufgabe verlangt, meist weil ein bestehender API-Key mit Vollzugriff wiederverwendet wurde. Dahinter: indirekte Injections über Inhalte, die niemand als Eingabekanal betrachtet hat, etwa Signaturen in E-Mails oder Freitextfelder in Formularen. Und schließlich fehlende Eskalationsregeln: Das System erkennt einen Widerspruch oder eine verdächtige Anweisung, hat aber keinen definierten Weg, einen Menschen einzuschalten, und entscheidet deshalb selbst. Alle drei Muster sind organisatorische Defekte, keine Modellschwächen, und genau deshalb findet man sie nur, wenn man das Gesamtsystem testet statt das Modell allein.
Wer sollte testen?
Möglichst nicht nur die Menschen, die das System gebaut haben. Wer den Agenten täglich sieht, testet ihn nachweislich immer freundlicher. Anthropic hat das im eigenen Langzeit-Experiment Project Vend dokumentiert: Ein Agent betrieb dort einen kleinen Bürokiosk, und das interne Red-Teaming schlief mit der Zeit ein, weil der Agent Alltag geworden war. Anthropic übergab den Kiosk daraufhin an Reporter des Wall Street Journal, ausdrücklich als feindliche Umgebung außerhalb der eigenen Kontrolle. Die Lehre für jedes Unternehmen: Hol dir für das Assessment Leute, die das System brechen wollen, etwa Kollegen aus einer anderen Abteilung, einen externen Dienstleister oder eine spezialisierte KI-Agentur.
Red-Teaming, Pentest, Evals: die Abgrenzung
Drei Begriffe, die in KI-Projekten oft durcheinandergehen: Ein Penetrationstest prüft die klassische Angriffsfläche (Netzwerk, Server, Anwendung) auf technische Schwachstellen, typischerweise mit definiertem Scope. Evals sind wiederholbare Qualitätstests für KI-Verhalten: Erledigt das System seine Aufgaben korrekt, wie oft eskaliert es, wo liegt die Fehlerquote. Red-Teaming ist der gegnerische Blick: Es sucht gezielt nach Wegen, das System zu missbrauchen, und speist seine Befunde anschließend in die Evals ein, damit jeder gefundene Angriffsweg dauerhaft als Testfall erhalten bleibt und eine einmal geschlossene Lücke nicht unbemerkt wieder aufgeht. Für produktive Agenten braucht es alle drei, in dieser Reihenfolge: Pentest für die Infrastruktur, Red-Teaming vor dem Go-Live, Evals als Dauerbetrieb.
Zur Rollenfrage: Intern oder extern ist keine Entweder-oder-Entscheidung. Ein internes Team kennt die Prozesse und weiß, welcher Fehlgriff wirklich weh tut; externe Tester bringen frische Angriffsideen mit und sind nicht betriebsblind. Bewährt hat sich die Arbeitsteilung, dass das interne Team den Szenario-Katalog aus den eigenen Prozessen baut und die Eval-Suite betreibt, während für den Go-Live-Test und die jährliche Auffrischung ein externer Blick dazukommt. Wichtig ist in beiden Fällen ein klarer Auftrag mit definierten Grenzen: Welche Systeme dürfen angegriffen werden, mit welchen Daten, in welchem Zeitfenster, und wer wird informiert, wenn ein Test versehentlich Wirkung in Produktivsystemen zeigt.
Für agentische Systeme hat OWASP die Methodik inzwischen ausgebaut: Der Katalog „Agentic AI – Threats and Mitigations" der OWASP-Initiative für generative KI beschreibt Bedrohungen, die erst durch Werkzeuge, Speicher und Autonomie entstehen, etwa Tool-Poisoning oder Missbrauch von Agenten-Berechtigungen, und ist eine gute Grundlage für den eigenen Szenario-Katalog, gerade bei einem Multi-Agenten-System mit mehreren beteiligten Rollen.
Häufige Fragen zum Red-Teaming
Brauchen kleine Unternehmen wirklich Red-Teaming?
Sobald ein KI-System schreibend auf Geschäftssysteme zugreift oder direkt mit Kunden spricht: ja. Der Umfang skaliert mit dem Risiko. Für einen internen Assistenten reichen einige Stunden strukturiertes Gegentesten mit einem Szenario-Katalog; für einen Agenten mit Zahlungs- oder Löschrechten gehört ein ernsthaftes Red-Teaming mit externen Testern vor jeden Go-Live.
Wie oft sollte Red-Teaming wiederholt werden?
Das vollständige Red-Teaming vor dem Go-Live, die daraus entstandene Eval-Suite bei jeder relevanten Änderung: neuer Prompt, neue Tools, neue Datenquellen und vor allem jedes Update des zugrunde liegenden Modells. Zusätzlich lohnt eine periodische Auffrischung des Szenario-Katalogs, weil neue Angriffstechniken entstehen.
Was kostet Red-Teaming für ein KI-System im Mittelstand?
Die ehrliche Antwort: deutlich weniger als der Vorfall, den es verhindert. Der Aufwand hängt von Rechten und Reichweite des Systems ab, von wenigen Personentagen für einen internen Assistenten bis zu einem mehrwöchigen Programm für Agenten mit weitreichenden Rechten. Der größte Kostenhebel ist Wiederverwendung: Ein einmal aufgebauter Szenario-Katalog trägt jedes weitere KI-Projekt mit.
Kann man Red-Teaming automatisieren?
Teilweise. Es gibt Werkzeuge, die bekannte Angriffsmuster automatisiert gegen ein System fahren, und auch LLMs lassen sich als Angreifer-Simulatoren einsetzen. Automatisierung ersetzt aber nicht die menschliche Kreativität, mit der echte Angreifer Kontext ausnutzen. Bewährt hat sich die Kombination: automatisierte Suiten für die Breite und Regression, Menschen für neue, kontextspezifische Angriffe.
Ist Red-Teaming gesetzlich vorgeschrieben?
Für die meisten Unternehmensanwendungen nicht explizit. Der EU AI Act verlangt für Hochrisiko-Systeme (ab Dezember 2027) aber Risikomanagement, Genauigkeits- und Robustheits-Anforderungen, die sich ohne adversariales Testen kaum belastbar nachweisen lassen. Red-Teaming ist damit auch regulatorisch die praktikable Antwort, nicht nur die technisch vernünftige.