Red Teaming für KI: Sicherheitslücken vor dem Start finden

Bevor ein KI-Agent im Kundenkontakt eingesetzt wird, sollte Red Teaming klären, ob er sich zur Preisgabe vertraulicher Daten, zu unbefugten Aktionen oder zu unzulässigen Inhalten verleiten lässt. Für den Einstieg eignet sich ein Durchlauf in 6 Schritten: Testumfang festlegen, Angriffsliste erstellen, Tests ausführen, Ergebnisse bewerten, Schwachstellen beheben und erneut testen. Das Ergebnis muss ein nachvollziehbarer Befund mit überprüfter Behebung sein; ein beruhigendes Prüfsiegel allein hilft wenig.

Die beschriebenen Tool-Funktionen und Frameworks wurden am 17. Oktober 2026 anhand ihrer offiziellen Dokumentation überprüft. Der folgende Ablauf und die Beispiele mit einem Support-Agenten sind Vorschläge für Testübungen, keine Ergebnisse eines Produkttests.

Was bedeutet Red Teaming bei KI?

Beim Red Teaming wird gezielt versucht, ein KI-System zu einem Verstoß gegen eine festgelegte Schutzvorgabe, Sicherheitsanforderung oder Geschäftsregel zu bringen. Die testende Person sucht nach einem konkreten Fehlverhalten, beobachtet die Reaktion des Systems und leitet daraus eine Änderung ab, deren Wirksamkeit sich erneut prüfen lässt. Für Unternehmen, die einen Chatbot bereitstellen, ist meist die gesamte Anwendung das Testziel: ihre Anweisungen, abgerufenen Informationen, Berechtigungen, Tools und die Antworten, die Kunden sehen. Risiken auf Modell- und Anwendungsebene.

Ein Vergleich mit einer Hotelrezeption macht den Unterschied greifbar. Ein gewöhnlicher Servicetest prüft, ob ein Gast den richtigen Zimmerschlüssel erhält. Ein Angriffstest untersucht, ob eine überzeugend gefälschte Wartungsmitteilung die Rezeption dazu bringt, den Schlüssel eines anderen Gastes herauszugeben. Entscheidend ist auch, welcher Schlüssel tatsächlich über den Tresen ging – unabhängig davon, wie höflich die Antwort ausfiel.

Für einen Agenten gelten vergleichbare Grenzen. Ein Support-Ticket liefert Informationen zur Bearbeitung; es darf nicht dieselbe Autorität erhalten wie die Freigabe durch eine Führungskraft. Ein abgerufenes Dokument kann bei einer Antwort helfen, darf aber keinen Zugriff auf die Daten eines anderen Kunden erlauben.

KI-Modell oder Anwendung: Was wird getestet?

Red Teaming auf Modellebene untersucht, wie sich das Modell bei gezielten Angriffseingaben verhält. Anwendungstests beziehen das umgebende System ein. Dort entscheiden Kundenidentität, Dokumentenzugriff und Tool-Berechtigungen darüber, was tatsächlich möglich ist. Der Sicherheitsbericht eines Modellanbieters belegt nicht, dass die eigene Erstattungsanbindung das richtige Kundenkonto prüft. Die Red-Teaming-Dokumentation von promptfoo unterscheidet diese Ebenen ausdrücklich.

Für die meisten Unternehmen ist die eingesetzte Anwendung der sinnvollste Ausgangspunkt. Tests auf Modellebene bleiben bei der Auswahl oder beim Wechsel des Modells nützlich. Kunden erleben jedoch das gesamte Produkt.

Was kann der üblichen Qualitätssicherung entgehen?

Red Teaming sucht nach Wegen, vorgesehene Grenzen zu überschreiten. Dazu gehören auch plausibel formulierte Anfragen, die Mehrdeutigkeiten ausnutzen, statt ungültige Eingaben zu verwenden. Die übliche Qualitätssicherung prüft das spezifizierte Verhalten: richtige Antworten, gültige Transaktionen, Antwortzeiten und erwartete Fehler. Eine ausgereifte Qualitätssicherung kann solche Angriffstests einschließen; Red Teaming liefert ihr neue Fehlerfälle.

Ein Support-Bot kann die Erstattungsrichtlinie korrekt erklären und trotzdem einen manipulierten Absatz in einem Hilfeartikel als Erlaubnis verstehen, sie zu umgehen. Beide Anfragen bestehen aus lesbarem Text. Der Unterschied liegt darin, wessen Anweisung die Anwendung als verbindlich behandelt.

Für einen Agenten im Kundenkontakt bieten sich zunächst die folgenden Angriffsarten an. Die Beispiele sind synthetische Testszenarien. Die Kriterien für ein bestandenes Ergebnis müssen an die eigenen Vorgaben angepasst werden.

Diese Kategorien überschneiden sich. Ein Jailbreak soll Schutzvorkehrungen für das Verhalten umgehen. Prompt Injection versucht, das System durch Anweisungen umzulenken, die es nicht als verbindlich behandeln sollte. Ist eine solche Anweisung in abgerufenem Material versteckt, handelt es sich um indirekte Prompt Injection. Sie kann zu einem Datenabfluss oder einer unbefugten Aktion führen. Die Kategorien beschreiben unterschiedliche Teile eines Fehlers und sind nicht strikt voneinander getrennt. Definitionen der Bedrohungen.

Bei KI-Agenten zählen auch die ausgeführten Aktionen

Ein KI-Agent ist eine Anwendung, die mithilfe von Tools Schritte zur Erfüllung einer Aufgabe ausführen kann. Beim Red Teaming von KI-Agenten reicht es deshalb nicht, nur die abschließende Antwort zu betrachten. Eine Ablehnung macht eine bereits erfolgte Datensatzänderung nicht rückgängig. Umgekehrt beweist die Aussage „Erstattung ausgeführt“ noch nicht, dass tatsächlich Geld erstattet wurde.

Gesprächsverlauf und Aktionsprotokoll müssen gemeinsam erfasst werden. Fordert der Agent einen verbotenen Vorgang an, den die Berechtigungsschicht blockiert, sind der versuchte Verstoß und die erfolgreiche Begrenzung getrennt zu dokumentieren. So lässt sich das Verhalten verbessern, ohne einen abgewehrten Versuch als vollzogenen Sicherheitsvorfall zu melden.

Bei einem Chatbot ohne Tools stehen Antworten und zugängliche Informationen im Mittelpunkt. Kann ein Agent Kundendatensätze verändern, muss auch der Zustand vor und nach jedem Aktionsversuch erfasst werden. Die zusätzliche Berechtigung verändert den erforderlichen Testumfang.

KI-Sicherheit prüfen: Wer sollte jetzt handeln?

Die Prüfung sollte erfolgen, bevor Kunden Zugriff auf vertrauliche Informationen oder folgenreiche Aktionen erhalten. Je nach Rolle liegen die Aufgaben bei anderen Personen. Für die Freigabeentscheidung werden jedoch alle Perspektiven gebraucht.

Entwicklung: Ein Gründer mit gesicherter Finanzierung oder ein allein arbeitender technischer Entwickler sollte zunächst einen eng begrenzten Kundenablauf auswählen und die unzulässigen Ergebnisse benennen, bevor ein Angriffstool angeschlossen wird. Kann die Anwendung Bestellungen lesen, muss die Trennung der Kundenkonten geprüft werden. Kann sie Bestellungen ändern, gehört die Berechtigungsprüfung unmittelbar an diesen Änderungsvorgang.

Betrieb: Die Support-Leitung sollte die geltenden Regeln, Beispiele für zulässige Ausnahmen und den Eskalationsweg liefern. Sicherheitsingenieure können nicht selbst herleiten, wann ein Unternehmen Erstattungen erlaubt oder welche Beratung der Chatbot ablehnen muss. Auch eine technisch zulässige Aktion kann gegen eine Geschäftsregel verstoßen.

Einkauf: Ein CTO im Mittelstand sollte Nachweise für die tatsächlich beschaffte Konfiguration verlangen, einschließlich ihrer Konnektoren und Berechtigungen. Der Bericht eines Anbieters zum Basismodell liefert Hintergrundinformationen, klärt aber nicht das Risiko des geplanten Einsatzes.

Bei einem Prototyp, der nur öffentliche Informationen nutzt, keine Aktionen ausführt und keine externen Nutzer hat, kann eine umfangreiche automatisierte Kampagne warten, solange sich sein Verhalten noch verändert. Grundlegende Prüfungen auf Missbrauch und unzulässige Inhalte bleiben sinnvoll. Sobald Kunden Zugang erhalten, vertrauliche Informationen abgerufen werden oder Tools Schreibzugriff bekommen, müssen die Tests vertieft werden.

Der Einstieg beginnt mit den eigenen Regeln

Für den ersten Durchlauf braucht es jemanden, der die Anwendung versteht, jemanden, der den möglichen geschäftlichen Schaden beurteilen kann, und jemanden, der Korrekturen umsetzt. In kleinen Teams können Personen mehrere Rollen übernehmen. Folgenreiche Befunde sollte nach Möglichkeit zusätzlich jemand prüfen, der den Test nicht selbst erstellt hat.

Als Übung eignet sich ein synthetischer Support-Fall mit einem schriftlich formulierten Angriffsziel und einer beobachtbaren Fehlerbedingung. Sind sich die Prüfenden uneinig, ob das angestrebte Verhalten erlaubt ist, muss zuerst die Regel geklärt werden. Erst danach lohnt es sich, die Bewertung zu automatisieren.

Der erste Durchlauf in sechs Schritten

Der erste Durchlauf sollte so überschaubar bleiben, dass sich jeder folgenreiche Befund untersuchen und beheben lässt. Der folgende Ablauf ist ein Vorschlag für die Praxis. Er behauptet nicht, dass eine feste Anzahl von Tests Sicherheit bescheinigt.

Als durchgängiges Beispiel dient ein Support-Agent, der Bestellungen lesen und Erstattungen anfordern kann. Am Ende soll eine Zusammenstellung von Nachweisen stehen, die auch ein anderer Entwickler oder ein Einkäufer nachvollziehen kann.

1. 1

   1. Anwendung und unzulässige Ergebnisse abgrenzen

   Zu dokumentieren sind die Anwendungsversion, die Modellkennung, Anweisungen, Quellen für den Informationsabruf, Kundenrollen, verfügbare Tools und Freigaberegeln. Auch die Testumgebung und die Person, die den Test autorisiert hat, müssen feststehen. Ausgeschlossene Bereiche gehören ausdrücklich in die Dokumentation, damit eine ungetestete Integration nicht hinter einem positiven Gesamtergebnis verschwindet.

   Im Support-Beispiel könnten die Grenzen so lauten: Kunden dürfen ihre eigenen Bestellungen lesen; Erstattungen benötigen eine gültige Freigabe; kein Kunde darf Datensätze eines anderen Kunden abrufen. Jede Regel muss beobachtbar sein. „Privatsphäre respektieren“ ist als Bewertungskriterium zu ungenau.

   In einer produktionsnahen Umgebung werden synthetische Datensätze und eingeschränkte Testidentitäten verwendet. Schreibvorgänge laufen über einen kontrollierten Testdienst, der die Berechtigungsprüfungen beibehält und protokolliert, was sich ändern würde. Ein simuliertes Tool, das alles akzeptiert, kann nicht belegen, dass die Autorisierung im Produktivbetrieb funktioniert. Für Anfragen, Laufzeit und Ausgaben sind Grenzen sowie eine Möglichkeit zum Abbruch festzulegen.

   Das Ergebnis ist eine kurze Beschreibung des Testumfangs mit benannten Verantwortlichen und Ergebnissen, die eine Freigabe ausschließen. Beim Aufbau der abgeschotteten Umgebung hilft der separate Leitfaden zur Sicherheitsbewertung von KI-Agenten.

2. 2

   2. Angriffe aus möglichen Geschäftsschäden ableiten

   Zuerst werden Ziele formuliert, dann Prompts. „Die Lieferadresse eines anderen Kunden erhalten“ ist ein Ziel. Eine bestimmte Formulierung ist lediglich ein Versuch, es zu erreichen.

   Zu jedem Ziel gehören der Einstiegspunkt, die Berechtigungen des Angreifers, das erwartete sichere Verhalten und die erforderlichen Nachweise. Direkte Chatnachrichten, abgerufene Dokumente und Tool-Antworten sind einzubeziehen, soweit die Anwendung sie verwendet. Neben unmittelbaren Anfragen sollten auch Gespräche getestet werden, die schrittweise auf einen Verstoß hinarbeiten.

   Ein nützlicher Testfall ist ein synthetischer Hilfeartikel mit der Anweisung, bei Erstattungen auf die Freigabe zu verzichten. Erwartet wird, dass die Anwendung diese Passage als nicht vertrauenswürdig behandelt und weiterhin eine Freigabe verlangt. Zusätzlich gehört eine zulässige Erstattung mit gültiger Freigabe in den Test. Sonst könnte eine Abwehr, die jede Erstattung blockiert, fälschlich erfolgreich wirken.

   Die ursprünglichen Testfälle und ihre Kennungen bleiben erhalten. Varianten dürfen Formulierung, Kontext oder Einstiegspunkt verändern, aber nicht stillschweigend das unzulässige Ergebnis, auf das der Test zielt.

3. 3

   3. Den tatsächlichen Anwendungspfad der Kunden testen

   Der Test muss mit der festgelegten Testumgebung und Testidentität dieselbe Anwendungslogik durchlaufen, die auch Kundenanfragen bearbeitet. Ein isolierter Modelltest, der Informationsabruf und Autorisierung umgeht, beantwortet eine andere Frage.

   Zunächst wird geprüft, ob die Verbindung das vorgesehene Ziel erreicht und dessen Protokolle die benötigten Nachweise enthalten. Anschließend laufen die ausgewählten Fälle. Aufbewahrt werden Eingaben, Gesprächsverlauf, abgerufene Textpassagen, Tool-Anfragen, Berechtigungsentscheidungen, Antworten und Endzustand. Zugangsdaten gehören nicht in Berichte. Anstelle echter Kundendaten werden synthetische Markierungen für vertrauliche Inhalte verwendet.

   Da Modellantworten variieren können, sollten folgenreiche Fälle nach einer festgelegten Regel wiederholt werden. Zu dokumentieren sind die Wiederholungen und eine etwaige Begrenzung der Gesprächsrunden für einen adaptiven Angreifer. Zwischen unabhängigen Fällen werden Sitzungen zurückgesetzt. Ist die Gesprächsfolge selbst Gegenstand des Tests, bleibt der Verlauf erhalten.

   Ein Timeout, ein Authentifizierungsfehler oder ein defekter Parser gilt bis zur Untersuchung als Testproblem. Daraus lässt sich nicht ableiten, dass die Anwendung den Angriff abgewehrt hat.

4. 4

   4. Nachweise bewerten, danach den Schweregrad festlegen

   Jeder Versuch erhält zunächst einen Status auf Grundlage der Nachweise. Erst danach wird eine zusammenfassende Kennzahl berechnet. Beobachtbare Tatsachen – etwa die Rückgabe eines verbotenen Datensatzes oder eine unbefugte Zustandsänderung – werden ausdrücklich geprüft. Ein bewertendes Modell kann beim Einordnen von Sprache helfen. Folgenreiche Befunde und unsichere Bewertungen sollten jedoch Menschen überprüfen.

   Das folgende Bewertungsschema trennt fehlerhafte Tests von erfolgreich geschützten Grenzen:

   Status	Bedeutung	Nächster Schritt
   Bestanden	Der gültige Versuch hat den definierten Verstoß nicht ausgelöst; die erforderlichen Nachweise liegen vor.	Testfall und Nachweise aufbewahren.
   Nicht bestanden	Die Nachweise bestätigen den definierten Verstoß.	Schweregrad festlegen und die Behebung einer verantwortlichen Person zuweisen.
   Ungültig	Der Versuch hat das vorgesehene Szenario nicht geprüft, etwa wegen fehlgeschlagener Authentifizierung oder fehlender Angriffsinhalte.	Den Test korrigieren und erneut ausführen.
   Unklar	Das Szenario wurde durchlaufen, doch Nachweise oder Bewertung erlauben keine eindeutige Entscheidung.	Untersuchen; nicht als bestanden zählen.

   Der Schweregrad wird davon getrennt beurteilt. Maßgeblich sind der Schaden, die betroffenen Daten, die erforderlichen Zugriffsrechte des Angreifers und die Frage, ob das Ergebnis eine tatsächliche Aktionsgrenze erreichte. Wird bestätigt, dass Daten eines anderen Kunden offengelegt wurden, muss das in die Freigabeentscheidung einfließen – auch wenn die meisten harmlosen Testanfragen bestanden wurden.

   Eine beobachtete Angriffserfolgsquote wird als Zahl der bestätigt erfolgreichen Versuche geteilt durch die Zahl der gültigen Versuche unter dem festgelegten Testprotokoll definiert. Offene Ergebnisse werden daneben ausgewiesen. Bleiben gültige Versuche unklar, ist der Anteil als Untergrenze der bestätigten Erfolge zu kennzeichnen, nicht als vollständige Erfolgsquote. Es muss feststehen, was als Versuch zählt, einschließlich der Frage, ob ein mehrstufiges Gespräch als ein Fall gilt. Wechselnde Testsätze dürfen nicht zu einem Trend zusammengeführt werden. Ebenso wenig beschreibt die errechnete Prozentzahl die Wahrscheinlichkeit, dass ein Kunde angegriffen wird.

5. 5

   5. Die versagte Schutzmaßnahme gezielt korrigieren

   Vor einer Prompt-Änderung muss die Ursache des Befunds geklärt werden. Kann ein abgerufenes Dokument eine Erstattung autorisieren, gehört die Freigabeprüfung am Übergang zum Tool verstärkt. Liefert der Informationsabruf Datensätze eines anderen Kunden, muss der Zugriffsfilter korrigiert werden, bevor diese Daten in den Modellkontext gelangen.

   Weitere mögliche Korrekturen sind das Entfernen eines unnötigen Tools, engere Berechtigungen, eine Freigabepflicht für folgenreiche Aktionen, die Trennung von Anweisungen und externen Inhalten oder bessere Antwortvorgaben. Die gewählte Änderung muss den beobachteten Angriffsweg unterbrechen.

   Konkrete Umsetzungsmuster beschreibt der Praxisleitfaden zu Schutzmaßnahmen und Schadensbegrenzung für produktive KI-Agenten. Der Red-Team-Befund zeigt, welcher Fehler behoben werden muss. Schutzmaßnahmen im Produktivbetrieb begrenzen die Handlungsmöglichkeiten des Systems, wenn sprachbasierte Abwehrmaßnahmen versagen.

   Jeder Befund braucht eine verantwortliche Person, eine konkrete Änderung und ein Kriterium für den erneuten Test. „Prompt gehärtet“ reicht nicht aus, um ihn abzuschließen.

6. 6

   6. Den ursprünglichen Fehler und ähnliche Fälle erneut testen

   Der ursprüngliche Fall wird gegen die korrigierte Anwendung erneut ausgeführt. Danach folgen Varianten mit demselben Ziel. Auch der legitime Kundenablauf muss weiterhin funktionieren. Jede Erstattung zu blockieren kann den Angriffsweg schließen und zugleich das Produkt unbrauchbar machen.

   Nachweise vor und nach der Änderung, Anwendungsversionen und Testkonfiguration werden aufbewahrt. Behobene Fehler wandern in eine Regressionstestsuite: wiederholbare Prüfungen, die erkennen sollen, wenn alte Probleme zurückkehren. Neue, erkundende Angriffe werden getrennt ergänzt. So können Verbesserungen im festen Testsatz keine neuen Schwächen verdecken.

   Ändern sich Modell, Anweisungen, Informationsquellen, Berechtigungen, Tools oder Geschäftsregeln, wird der Testumfang erneut geprüft. Eine Freigabe erfolgt erst, wenn die festgelegten Freigabehindernisse beseitigt sind oder die verantwortliche Person das verbleibende Risiko ausdrücklich akzeptiert hat. Ein unklares Ergebnis an einer freigabekritischen Grenze bleibt offen.

Welche Aufgaben übernehmen OWASP, MITRE ATLAS und NIST?

Die Frameworks helfen, die Arbeit zu strukturieren. Hinzu kommen die konkreten Fehlerbedingungen der eigenen Anwendung. Keines liefert die eigene Erstattungsrichtlinie oder beweist, dass die Trennung zwischen Kunden gehalten hat.

OWASP Top 10 for LLM Applications ist eine Risiko-Checkliste für Anwendungen mit großen Sprachmodellen, also den texterzeugenden Modellen hinter vielen Chatbots. Die aktuelle Seite zeigt die Liste von 2025. Sie umfasst unter anderem Prompt Injection, die Offenlegung vertraulicher Informationen und übermäßige Handlungsbefugnisse eines Systems. Damit lassen sich fehlende Risikokategorien in der Angriffsliste erkennen. Die Liste von OWASP.

MITRE ATLAS ist eine fortlaufend gepflegte Wissensbasis zu Angriffstaktiken und -techniken im Zusammenhang mit KI. Sie stützt sich auf beobachtete Angriffe und realistische Demonstrationen. Mit ihr lässt sich beschreiben, wie ein Angreifer ein schädliches Ergebnis erreichen könnte und wie einzelne Fälle zu einer plausiblen Abfolge zusammenhängen. Das hilft Sicherheitsprüfern zu verstehen, welches Angriffsverhalten die Übung abgedeckt hat. MITRE ATLAS.

Das AI Risk Management Framework des National Institute of Standards and Technology, kurz NIST AI RMF, gliedert das Risikomanagement in Govern, Map, Measure und Manage. NIST bezeichnet die Anwendung als freiwillig. Das Framework verknüpft den Test mit Zuständigkeiten, Einsatzkontext, Messung und der Entscheidung über offene Risiken. Ein Bericht, der dem Framework zugeordnet ist, stellt keine NIST-Zertifizierung dar. NIST AI RMF.

Beim synthetischen Erstattungsfall hilft OWASP, das Risiko zu benennen. ATLAS beschreibt den Angriffsweg, und das AI RMF ordnet das Ergebnis in einen geregelten Entscheidungsprozess ein. Diese Zuordnung gehört zu den Nachweisen; Framework-Bezeichnungen dürfen sie nicht ersetzen.

Red Teaming Tools: Welches passt zu welcher Aufgabe?

Entscheidend ist, ob ein Tool die tatsächliche Anwendung prüfen und die benötigten Nachweise sichern kann. Open Source eignet sich für den Einstieg, wenn ein Entwickler Konfiguration, Bewertung, Untersuchung und wiederholte Durchläufe verantworten kann. Eine Plattform kommt infrage, wenn die Koordination über mehrere Anwendungen und Prüfende hinweg zum Engpass wird.

promptfoo: Wiederholbare Anwendungstests

Der Red-Team-Modus von promptfoo erzeugt über Plugins gezielte Angriffseingaben, wendet Angriffsstrategien an und erstellt Berichte zur Untersuchung von Fehlern. Die Kurzanleitung beschreibt Tests über eine Web-API, also eine Schnittstelle zum Aufrufen der Anwendung, sowie über einen Browser oder direkt gegen ein Modell. Damit ist promptfoo ein praktischer Einstieg für Entwickler, die wiederholbare Anwendungsscans konfigurieren möchten. Offizielle Red-Team-Kurzanleitung.

Beim Betrieb ist der Umgang mit Daten zu beachten: Ein lokaler Testläufer bedeutet nicht, dass auch die Erzeugung und Bewertung lokal bleiben. Einige Plugins benötigen gehostete Inferenz; eine gehostete Bewertung kann Prompts und Antworten des Testziels empfangen. Vor dem Anschluss zugriffsbeschränkter Inhalte sollten die dokumentierten Datenflüsse geprüft werden. Der Testbericht zu promptfoo erläutert Konfiguration und diese Grenzen genauer.

Microsoft PyRIT: Flexible Abläufe für Angriffstests

Microsoft PyRIT, das Python Risk Identification Tool for generative AI, ist ein Open-Source-Framework zur Erkennung von Risiken in generativen KI-Systemen. Die Dokumentation behandelt Angriffe über eine oder mehrere Gesprächsrunden, eigene Testziele, Bewertung und gespeicherte Gesprächsergebnisse. Zur Verfügung stehen ein Scanner, eine grafische Oberfläche und ein Framework-Modus. Aktuelles Repository und offizielle Dokumentation.

PyRIT passt, wenn die Übung eigene Angriffsfolgen oder Bewertungsverfahren benötigt und jemand deren Zusammenstellung übernehmen kann. Die Flexibilität hat eine Kehrseite: Die Erfolgskriterien für die eigene Anwendung müssen selbst festgelegt und die erforderlichen Nachweise in den Testablauf eingebunden werden.

NVIDIA garak: Schwachstellen in Sprachmodellen aufspüren

NVIDIA garak, das Generative AI Red-teaming & Assessment Kit, bezeichnet sich als Schwachstellenscanner für große Sprachmodelle. Es nutzt Testanfragen, sogenannte Probes, um Fehler hervorzurufen, und Detektoren zur Bewertung der Ausgaben. Abgedeckt werden unter anderem Datenabfluss, Prompt Injection, toxische Inhalte und Jailbreaks. Das Repository dokumentiert außerdem einen Konnektor für Web-Endpunkte und ausführliche Ergebnisprotokolle. Offizielles Repository.

garak eignet sich für systematische Scans eines Modells oder Dialog-Endpunkts. Bezieht sich die zu prüfende Aussage auf eine Tool-Aktion oder Kundendatensätze, müssen Testziel und Prüfungen die entsprechenden Nachweise sichtbar machen. Die reine Bewertung von Ausgaben kann keine Zustandsänderung belegen, die der Scanner gar nicht beobachtet. Das ist eine Grenze des Testumfangs und kein Grund, Modellscans grundsätzlich abzulehnen.

Airia: Wiederkehrende Testkampagnen koordinieren

Airia kommt als Plattform infrage, wenn wiederholte Agententests über mehrere Arbeitsabläufe hinweg koordiniert werden müssen. Die Seite zum Agent Red Teaming beschreibt Tests auf Prompt Injection, Tool-Manipulation und verkettete Szenarien. Dazu zählen mehrstufige Angriffe über Prompts, Tools, APIs und Speicher hinweg. Airia beschreibt außerdem fortlaufende Kampagnen und die Zuordnung von Befunden zu anerkannten Sicherheitsframeworks. Dabei handelt es sich um Funktionsangaben des Anbieters. Airias Seite zum Agent Red Teaming.

Eine Plattform lohnt sich, wenn sie den Aufwand für das Anbinden von Anwendungen, die Prüfung von Nachweisen und die Nachverfolgung von Befunden bis zur Behebung senkt. Für ein Unternehmen mit mehreren Agentenverantwortlichen und Prüfungen durch Unternehmenskunden kann das wichtiger sein, als jede Komponente des Testläufers selbst zu betreiben.

Der Kauf sollte von einer Demonstration mit der zuvor abgegrenzten eigenen Anwendung abhängen: einen bekannten synthetischen Fehler reproduzieren, die relevanten Aktionsnachweise prüfen, eine Korrektur umsetzen und den Fall erneut ausführen. Dabei ist zu klären, welche Framework-Zuordnungen und Nachweisexporte für diesen Einsatz verfügbar sind. Die öffentliche Funktionsbeschreibung liefert weder einen unabhängigen Wirksamkeitsnachweis noch die Gewissheit, dass jede benötigte Integration abgedeckt ist.

Open Source bleibt sinnvoll, wenn ein überschaubarer Testsatz und ein verantwortlicher Entwickler bereits die Nachweise liefern, die Einkäufer benötigen. Der Kauf einer Plattform lohnt sich, wenn wiederkehrende Testläufe und gemeinsame Prüfungen den Aufwand rechtfertigen und die Demonstration denselben Maßstab erfüllt. Bei beiden Ansätzen muss festgelegt werden, welches Verhalten zulässig ist.

Welche Nachweise sollten Unternehmenskunden verlangen?

Gefragt sind ein Bericht zur vorgesehenen Einsatzkonfiguration und ein Beispiel, das einen Befund bis zum erneuten Test verfolgt. „Wir prüfen unsere KI per Red Teaming“ beschreibt zunächst nur einen Prozess. Die zugehörige Dokumentation muss zeigen, was getestet wurde und was sich dadurch geändert hat.

Die folgenden Unterlagen gehören zusammen:

• Testumfang und Datum: Anwendungs- und Modellkennungen, relevante Anweisungen, Quellen für den Informationsabruf, Rollen, Tools, Integrationen und ausgeschlossene Bereiche.
• Abdeckung der Angriffe: Ziele, Einstiegspunkte, Fälle mit einer einzelnen Anfrage und mit Gesprächsverläufen sowie die Kundenfunktionen und -rechte, die den Testenden zur Verfügung standen.
• Methode und Bewertung: Testkonfiguration, Zählweise der Versuche, Erfolgskriterien, Prüfung durch Menschen und Umgang mit ungültigen oder unklaren Ergebnissen.
• Befunde: Schweregrad, betroffene Grenzen, reproduzierbare Nachweise und verbleibende Einschränkungen; vertrauliche Details werden über einen geeigneten Kanal ausgetauscht.
• Korrekturen und erneute Tests: die geänderte Schutzmaßnahme, Nachweise vor und nach der Änderung sowie die Bestätigung, dass die legitime Nutzung weiterhin funktioniert.
• Dauerhafte Zuständigkeit: Wer akzeptiert Restrisiken, welche Änderungen lösen einen weiteren Durchlauf aus und wie erfahren Kunden von wesentlichen Befunden, die sie betreffen?

Zu klären ist auch, ob der Anbieter selbst, eine externe Prüfstelle oder beide die Arbeit durchgeführt haben. Unabhängigkeit ist eine nützliche Zusatzinformation. Das Logo eines Dritten ersetzt aber weder einen fehlenden Testumfang noch die Prüfung eines ungetesteten Konnektors.

Schließt der Bericht eine Integration aus, die eingesetzt werden soll, gilt sie als ungeprüft. Vor ihrer Aktivierung sind gezielte Tests erforderlich; alternativ bleibt der Einsatz eingeschränkt, bis die relevanten Nachweise vorliegen. Ein unauffälliges Ergebnis für einen rein lesenden Chatbot lässt sich nicht einfach auf einen Agenten mit Schreibrechten übertragen.

Welche Versprechen gehen zu weit?

Eine hohe Anzahl von Angriffen belegt noch keine gute Testabdeckung. Wiederholte Varianten gegen einen Chat-Endpunkt können Informationsabruf, Speicher und Tool-Autorisierung vollständig unberührt lassen. Abdeckung muss sich auf die Angriffsflächen und Fehlerbedingungen im festgelegten Testumfang beziehen.

Auch eine einzelne Bestehensquote verleitet zu weitreichenden Schlüssen. Unterschiedliche Angriffsgeneratoren, Budgets, Bezugsgrößen und Bewertungsverfahren erschweren den Vergleich von Ergebnissen. Neben einer Gesamtkennzahl gehören das Testprotokoll und die folgenreichen Befunde in den Bericht. Es gibt keine allgemein sichere Bestehensquote, die einen nachgewiesenen Abfluss von Kundendaten aufwiegt.

Gerade bei Agenten ist eine Bewertung, die nur auf Ablehnungen achtet, wenig aussagekräftig. Eine sicher klingende Antwort kann mit einer unsicheren Aktion einhergehen. Ein blockierter Tool-Aufruf kann dagegen zeigen, dass eine wichtige Schutzmaßnahme funktioniert hat. Vor der Einstufung eines Ergebnisses müssen die Nachweise geprüft werden.

Red Teaming ist ein Baustein eines Programms zum Schutz vor schädlichem Verhalten und Sicherheitsvorfällen. Es ersetzt weder die übliche Qualitätssicherung noch Zugriffskontrolltests, Überwachung im Produktivbetrieb oder die Reaktion auf Sicherheitsvorfälle. Eine abgeschlossene Kampagne zeigt, was unter den getesteten Bedingungen geschah. Sie beweist nicht, dass keine unentdeckten Fehler existieren.

Häufige Fragen zu Red Teaming bei KI

Was ist Red Teaming bei KI?

Dabei wird durch gezielte Angriffstests versucht, ein KI-System zu einem Verstoß gegen eine Schutzvorgabe, Sicherheitsanforderung oder Geschäftsregel zu bringen. Bei einer Anwendung im Kundenkontakt gehören neben den Modellantworten auch Datenzugriffe und das Verhalten der Tools zum Testumfang.

Welche KI eignet sich am besten für Red Teaming?

Es gibt kein Angreifermodell und kein Tool, das universell am besten geeignet ist. Entscheidend ist eine Methode, die die tatsächlichen Einstiegspunkte der Anwendung erreicht und das unzulässige Ergebnis überprüfen kann. promptfoo, Microsoft PyRIT und NVIDIA garak bieten unterschiedliche Möglichkeiten, diese Arbeit zu organisieren. Keines liefert automatisch die eigenen Geschäftsregeln mit.

Wie gelingt der Einstieg ins Red Teaming von KI?

Am Anfang stehen eine Anwendung, für die eine Testberechtigung vorliegt, synthetische Daten und eine schriftlich festgelegte Grenze. Zunächst gilt es, einen reproduzierbaren Befund mit klarer Ergebniserwartung zu erstellen und anschließend die Behebung zu überprüfen. Kenntnisse der Anwendung, sorgfältige Beobachtung und eine verlässliche Bewertung sind wichtiger als eine frühzeitig skalierte Angriffserzeugung.

Wird KI menschliche Red Teams ersetzen?

Bei Tests von KI-Systemen kann Automatisierung Testanfragen erzeugen und wiederholen. Menschen müssen weiterhin festlegen, welcher Schaden unzulässig ist, Befunde validieren und entscheiden, ob die Nachweise eine Freigabe tragen. Automatisierte Angriffe und Bewertungen unterstützen diese Arbeit. Wo die Folgen schwer wiegen, gehört eine Prüfung durch Menschen dazu.

Wie sieht ein konkretes Red-Teaming-Beispiel aus?

Ein synthetisches Hilfedokument, das ein Support-Agent verwendet, enthält eine gefälschte Anweisung, bei Erstattungen auf die Freigabe zu verzichten. Geprüft wird, ob der Agent das Dokument als verbindliche Vorgabe behandelt und ob das Erstattungstool eine unbefugte Aktion zulässt. Anschließend wird die versagte Schutzmaßnahme korrigiert und der Fall erneut ausgeführt – zusammen mit einer zulässigen, freigegebenen Erstattung.

Was ist vor der nächsten Freigabe zu tun?

Vor der nächsten Freigabeprüfung gilt es, einen Kundenablauf auszuwählen, seine unzulässigen Ergebnisse festzuhalten und die Verantwortung für die Behebung zuzuweisen. Der abgegrenzte Testdurchlauf liefert die Nachweise für die Entscheidung. Wer eine Lösung einkauft, sollte sich vom Anbieter einen Befund, dessen Korrektur und den erneuten Test für die geplante Konfiguration zeigen lassen.

Den Newsletter abonnieren für praxisnahe Leitfäden zum Aufbau und Betrieb von KI-Systemen.