AI-Red-Teaming erklärt: Was ein Red Team testet – und was es hinterlässt

Die meisten KI-Red-Teaming-Engagements werden am falschen Artefakt gemessen. Eine Woche Arbeit erzeugt einen Foliensatz, der besagt, dass man den Assistenten dazu überreden kann, eine Phishing-E-Mail zu schreiben, und hinterher kann niemand sagen, ob das Verhalten reproduzierbar war, wie schwerwiegend es war oder welche Kontrollmaßnahme es verhindert hätte. Die Disziplin hat ein echtes Ergebnis, und das ist kein Foliensatz: Es ist eine Reihe von Befunden, die einem erneuten Durchlauf standhalten, jeder einzelne verknüpft mit einer überschrittenen Grenze und den Belegen, die sie überschritten haben. Das ist auch die Form des Verzeichnisses, welches das KI-Vorfallarchiv führt – 400 Einträge von Dezember 2024 bis Oktober 2026, aus 743 verschiedenen Quellen zusammengetragen, und zu jedem einzelnen ein Urteil darüber, ob tatsächlich jemand zu Schaden kam.

Die Verwirrung ist verständlich, denn „Red Teaming“ wird für zwei Aufgaben verwendet, die sich nur das Vokabular teilen und sonst kaum etwas. Dies ist ein Leitfaden zu beiden, zu den Belegen, die jeweils hervorgebracht werden sollten, und zu den vier Punkten, an denen KI-Red-Teaming wirklich von der Netzwerkvariante abweicht, die die meisten Sicherheitsteams bereits zu betreiben wissen.

Die Rahmenfrage: Wem gehört der Test?

Bevor es um den Umfang geht, stellt sich die Frage, wer die Übung durchführt und gegen was. Microsoft veröffentlicht dazu eine der vollständigeren öffentlichen Positionen, und es lohnt sich, sie als Landkarte statt als Produktseite zu lesen. Das AI Red Team Hub von Microsoft trennt das Konzept des AI Red Teaming von der praktischen Anleitung und ordnet die Praxis anschließend in einer Reihenfolge ein, die selbst ein Argument ist: Überblick, dann ein Leitfaden für den Aufbau eines LLM-Red-Teams, dann das Referenzmaterial – eine Bug-Bar für die Triage von Angriffen auf Machine-Learning-Systeme, eine Taxonomie für Machine-Learning-Fehler, ein Modell geteilter Verantwortung und Leitlinien zur Bedrohungsmodellierung für Entwickler.

Lies die Abfolge, und die Methodik ergibt sich von selbst. Eine Taxonomie legt fest, was als Fehler zählt. Eine Bug-Bar legt fest, welche dieser Fehler es wert sind, behoben zu werden. Ein Modell geteilter Verantwortung legt fest, wer dafür verantwortlich ist, sobald dieser gefunden wurde. Bedrohungsmodellierung entscheidet, wo als Nächstes zu suchen ist. Ohne diese vier erzeugt ein Red Team Anekdoten mit einer angeflanschten Schweregradspalte, und die Schweregradspalte ist das, was der Tester an jenem Nachmittag gerade empfand.

Microsofts offenes Automatisierungsframework PyRIT steht im selben Regal, und genau diese Einordnung ist der nützliche Teil. Ein Orchestrierungs-Kit ist keine Methodik; es ist das, worauf man auf ein Ziel richtet, sobald die Taxonomie und die Bug-Bar existieren. Teams, die mit dem Framework beginnen, enden tendenziell mit einem großen Korpus an Prompts und keiner Möglichkeit, die Ergebnisse zu bewerten.

Zwei Red Teams, zwei unterschiedliche Fragen

Die mit Abstand nützlichste Unterscheidung in diesem Feld ist diejenige, die fast niemand aufschreibt: Ein Red Team, das ein Modell testet, und ein Red Team, das ein System testet, beantworten unterschiedliche Fragen – mit unterschiedlichen Testeinheiten, unterschiedlichen Ergebnissen und unterschiedlichen Verantwortlichen. Sie zu vermischen führt dazu, dass ein Jailbreak als Sicherheitsbefund gemeldet wird und ein echter Privilegieneskalationsfehler als Beschwerde über die Modellqualität eingereicht wird.

Sicherheitsbewertung auf Modellebene ist ein Messproblem. Es geht um die Frage, ob ein Modell eine Inhaltskategorie erzeugt, und die ehrliche Antwort darauf ist eine Stichprobe, die groß genug ist, um etwas über eine Rate aussagen zu können. Die getestete Einheit ist das Modell hinter einer dünnen API, die Methode ist adversarisches Prompting – Jailbreaks, Persona-Angriffe, Druck über mehrere Turns – und heraus kommt ein Transkript plus eine Schadensbewertung. Wenn sich die Gewichte ändern oder sich die Sicherheitsschicht des Anbieters verschiebt, ist das gesamte Ergebnis veraltet. Deshalb wird diese Art von Test üblicherweise vom Modellentwickler oder von einer unabhängigen Prüfstelle durchgeführt, und deshalb lassen sich seine Ergebnisse selten auf eine konkrete Korrektur in Ihrer Anwendung abbilden.

Gegneremulation auf Systemebene ist ein Ingenieursproblem. Sie fragen, ob ein Angreifer das eingesetzte System zum Handeln bringen kann – eine Datei lesen, die es nicht lesen sollte, ein Tool aufrufen, das es nicht aufrufen sollte, Geld ausgeben, das es nicht ausgeben sollte. Das Prüfobjekt ist der Agent mit seinen angebundenen Tools, Retrieval und Zugangsdaten. Die Methoden sind die bekannten, nur neu ausgerichtet: Injection über abgerufene Inhalte statt über den Nutzer-Turn, Tool-Missbrauch, Privilegienketten, die aus einzeln betrachtet angemessenen Berechtigungen zusammengesetzt sind, Datenpfade, die über eine Mandantengrenze hinweg lecken. Das Ergebnis ist ein Finding mit einer Reproduktion, einer überschrittenen Grenze und einem Owner, der die Konfiguration morgen ändern kann.

Die beiden erzeugen inkompatible Artefakte, und diese Inkompatibilität ist diagnostisch und nicht lästig. Ein Ergebnis auf Modellebene kann von Ihrem Team nicht „behoben“ werden, außer durch einen Modellwechsel. Ein Ergebnis auf Systemebene kann vom Anbieter überhaupt nicht behoben werden. Wenn ein Bericht nicht angibt, um welches der beiden es sich handelt, können Sie keines seiner Elemente zuordnen.

Was aus der Angriffsfläche wird, sobald das Modell über Tools verfügt

Die Oberfläche, die die meisten Teams noch testen, ist der Prompt. Sie ist zugleich die am wenigsten interessante, denn sie ist diejenige, in deren Härtung der Modellanbieter den meisten Aufwand gesteckt hat, und diejenige, über die ein Angreifer den geringsten Hebel hat. Die Oberflächen, die tatsächlich etwas bringen, sind diejenigen, die die Anwendung hinzugefügt hat: die Tools, die der Agent aufrufen kann, der Retrieval-Index, den er liest, das Gedächtnis, das er zwischen den Turns trägt, und der Ausgabekanal selbst.

Tools sind der Ort, an dem ein Sprachmodell zum Akteur wird, und die interessante Frage ist nie „Kann es das Tool aufrufen“, sondern „Welche geringstmögliche Berechtigung hätte dieses Tool haben können“. Ein Ticket-Lookup-Tool, das eine Freitextabfrage akzeptiert, lässt sich in der Regel dazu überreden, die Kennung eines anderen Kunden zu akzeptieren. Retrieval ist ein Inhaltskanal in den Kontext des Modells, was bedeutet: Jeder, der in das Korpus schreiben kann – ein gemeinsames Laufwerk, ein Support-Makro, eine Webseite, die der Fetcher erreicht –, schreibt in den Prompt. Memory verwandelt einen einzelnen Turn in Persistenz: Eine in Turn zwei platzierte Anweisung steht auch in Turn vierzig noch da. Output ist der Ort, an dem der Text des Modells irgendwo landet, wo er interpretiert wird, und Rendering, Markdown, Link-Vorschauen und shell-nahe Pipelines interpretieren sämtlich Text.

Ein Engagement, das nur den Prompt testet, wird ein sauberes Ergebnis melden und bei der falschen Sache richtig liegen.

Warum ein Transkript kein Befund ist

Ein Finding erfordert drei Eigenschaften, die ein Screenshot eines Chatfensters nicht besitzt. Die erste ist Reproduzierbarkeit: Führe es erneut aus einem sauberen Zustand aus, und es tritt wieder auf. Modelle sind nicht deterministisch, daher ist Reproduzierbarkeit eine Rate und kein boolescher Wert – „neun von zehn Versuchen“ ist ein Finding, „es ist einmal passiert“ ist ein Gerücht. Die zweite ist eine Grenzüberschreitung: Benenne das, was nach den Begriffen der Anwendung nicht hätte passieren dürfen, nicht nach denen des Modells. Nicht „das Modell war unhöflich“, sondern „der Agent hat ein Dokument gelesen, das Mandant B gehört“. Die dritte ist ein Schweregrad, der sich auf die Auswirkung zurückführen lässt und nicht auf die Intuition des Testers, wofür eine Bug-Bar da ist.

Alles andere – das Transkript, der Prompt, die Argumentation des Modells – sind Belege, die diese drei stützen. Es ist nicht der Befund selbst, und deshalb ist ein Korpus von zweitausend Jailbreak-Prompts weniger wert als fünf reproduzierbare Systembefunde mit benannten Kontrollen.

Vier Bereiche, in denen AI-Red-Teaming von Netzwerk-Red-Teaming abweicht

Teams, die aus dem Bereich Netzwerk- oder Anwendungssicherheit kommen, bringen gute Instinkte und vier falsche Annahmen mit.

• Es gibt keinen Perimeter, den es zu halten gilt. Ein Netzwerk-Engagement hat eine Zielliste; ein Agent-Engagement hat ein Kontextfenster, das zur Anfragezeit aus Quellen zusammengestellt wird, die Sie möglicherweise nicht inventarisiert haben. Der Scope muss als Datenquellen und Tool-Berechtigungen, nicht als Hostnamen.

• Das Ziel ist nicht deterministisch. Dieselbe Eingabe kann am Dienstag erfolgreich sein und am Mittwoch fehlschlagen. Dies untergräbt den Evidenzstandard der „einen sauberen Reproduktion“ und zwingt Sie, Raten zu melden.

• Der Exploit ist die Sprache, und Sprache hat keinen Patch. Sie können eine fehlende Autorisierungsprüfung beheben. Sie können nicht „das Modell kann überzeugt werden“ patchen. Die Gegenmaßnahme bei einer Schwäche auf Sprachebene ist eine Kontrolle an anderer Stelle – ein Filter, eine Bereichsgrenze, eine Berechtigungsgrenze –, weshalb Befunde die Kontrolle benennen müssen und nicht nur das Verhalten.

• Der Anbieter ist in den Ablauf eingebunden. Ihr Ziel ändert sich, wenn jemand anderes eine Version veröffentlicht. Ein Ergebnis auf Modellebene gilt nur für den Build, den Sie getestet haben, und wenn Sie die Version und das Datum nicht aufgezeichnet haben, haben Sie kein Ergebnis.

Wie man den Umfang einer ersten Zusammenarbeit festlegt

Die Aufträge, die schlecht laufen, sind fast immer als „die KI testen“ abgesteckt. Ein Umfang, der den Kontakt mit einem Zeitplan übersteht, sieht eher so aus: ein Agent, in einer Staging-Umgebung, mit produktionsähnlichen Daten und produktionsähnlichen Berechtigungen; eine Liste der fünf Grenzen, auf die es ankommt (Mandantentrennung, Zugriff auf Anmeldedaten, Ausgaben, Datenabfluss, Werkzeugumfang); Regeln für die Durchführung, die benennen, was außerhalb der Grenzen liegt; Abbruchbedingungen, die festlegen, wer den Lauf anhalten kann; und ein definiertes Evidenzformat, das vor dem ersten Versuch vereinbart wird, sodass der Bericht aus Artefakten zusammengesetzt und nicht aus dem Gedächtnis rekonstruiert wird.

Autorisierung verdient einen eigenen Satz, weil sie der eine Punkt ist, den Teams auslassen, wenn das Ziel ihr eigenes Produkt und die Werkzeuge die von jemand anderem sind. Ein Modell zu testen, das man nicht betreibt, auf einer Infrastruktur, die man nicht besitzt, mit Prompts, die darauf ausgelegt sind, eine Sicherheitsschicht zu umgehen, ist eine andere Tätigkeit als das Testen der eigenen Bereitstellung – und der schriftlich festgelegte Umfang ist das, was beide trennt. Das Verifikationsgate, auf dem unsere eigene Cyber-Stufe läuft, existiert aus demselben Grund: Autorisierte Sicherheitsarbeit auf Modellebene braucht auf beiden Seiten eine benannte, rechenschaftspflichtige Stelle.

Was der Vorfallsbericht ergänzt

Ein Red-Team-Lauf sagt Ihnen, was Ihr Zielsystem tut. Er kann Ihnen nicht sagen, was im Feld passiert, und im Feld wird tatsächlich die Begründung für eine Kontrolle geliefert. Genau diese Lücke füllt ein Incident-Ledger – und die Disziplin, die er erzwingt, ist der nützliche Teil: Ein Eintrag ohne mindestens eine Quelle existiert nicht, und ein Eintrag ohne Schadensbewertung ist kein Vorfall.

Liest man die beiden Artefakte zusammen, schließt sich der Kreis. Das Red Team erzeugt einen reproduzierbaren Befund und benennt die Kontrolle, die ihn blockiert hätte. Der Datensatz sagt Ihnen, ob jemand in der Praxis diese Grenze bereits erreicht hat, worin der Schaden bestand und ob die Kontrolle anderswo gegriffen hat. Ein Befund ohne Präzedenzfall aus der Praxis ist eine Hypothese, die es wert ist, behoben zu werden; ein Vorfall aus der Praxis ohne reproduzierbaren Befund ist ein Fehler, den Sie noch nicht schließen können. Teams, die das richtig machen, behandeln „wir haben das Modell einem Red-Team-Test unterzogen“ nicht mehr als Liefergegenstand, sondern als eine Eingabe in ein eigenes Register.

Damit bleibt die ehrliche Schlussbemerkung. AI-Red-Teaming liefert keine Sicherheitsgarantie, und jeder Auftrag, der als eine solche verkauft wird, verkauft das Falsche. Es liefert eine Reihe von Grenzen, von denen Sie jetzt wissen, dass sie überschritten werden, mit Beweisen, die Sie erneut durchführen können, geordnet danach, was passiert, wenn sie überschritten werden. Das reicht, um Entscheidungen darauf zu stützen – und ist deutlich mehr als eine Präsentation.