Offensive Red-Team-Frameworks für KI-Agenten: Garak, PyRIT und Promptfoo im Labor

Wer KI-Agenten in Produktion bringt, verlagert Sicherheitsrisiken vom Prompt in die Lieferkette: Ein Agent ruft Werkzeuge auf, liest fremde Dokumente, schreibt in Datenbanken und trifft Entscheidungen ohne menschliche Zwischenkontrolle. Genau deshalb reicht ein manueller Jailbreak-Test längst nicht mehr aus. Sie brauchen reproduzierbares, automatisiertes Red-Teaming. Die drei meistgenutzten Open-Source-Frameworks dafür sind Garak (NVIDIA), PyRIT (Microsoft) und Promptfoo. Dieser Beitrag erklärt, was jedes Werkzeug tatsächlich prüft, worin sich die Ansätze grundlegend unterscheiden und wann Sie zu welchem greifen sollten.

Welches Red-Team-Tool für KI-Agenten ist das richtige für mich?

Die kurze, zitierbare Antwort vorweg: Garak ist der schnelle Schwachstellen-Scanner für ein Sprachmodell, PyRIT ist das forschungsnahe Framework für tiefe, mehrstufige Angriffe, und Promptfoo ist das entwicklernahe Werkzeug, das Red-Teaming in Ihre CI/CD-Pipeline einbettet. Wer ein Modell schnell auf bekannte Schwachstellen abklopfen will, nimmt Garak. Wer ein eigenes Sicherheitsforschungsprogramm aufbaut und neuartige, eskalierende Angriffe untersuchen will, nimmt PyRIT. Wer eine Agenten-Anwendung baut und bei jedem Commit gegen Regressionen absichern will, nimmt Promptfoo. In reifen Programmen schließen sich die drei nicht aus, sondern ergänzen sich entlang des Entwicklungszyklus.

Diese Einordnung ist der rote Faden des Beitrags. Alle drei Werkzeuge sind quelloffen, kostenlos im Kern und werden aktiv weiterentwickelt. Sie lösen jedoch unterschiedliche Probleme, und genau diese Unterschiede entscheiden darüber, ob Ihr Sicherheitstest aussagekräftig ist oder nur ein grünes Häkchen ohne Substanz produziert.

Warum braucht ein KI-Agent überhaupt Red-Teaming?

Ein klassischer Penetrationstest prüft Code, Netzwerke und Konfigurationen. Ein KI-Agent fügt eine neue Angriffsfläche hinzu, die mit herkömmlichen Mitteln nicht greifbar ist: die natürliche Sprache als Steuerungsschnittstelle. Der Agent unterscheidet nicht zuverlässig zwischen einer legitimen Anweisung seines Betreibers und einer feindlichen Anweisung, die in einem verarbeiteten Dokument, einer Webseite oder einer Werkzeug-Antwort versteckt ist. Das ist die Kernschwäche, aus der die meisten Agenten-Risiken entstehen.

Red-Teaming für KI-Systeme bedeutet, ein System mit der Haltung eines Angreifers systematisch herauszufordern, bevor es ein echter Angreifer tut. Während ein gewöhnlicher Funktionstest prüft, ob der Agent das tut, was er soll, prüft Red-Teaming, ob er sich dazu bringen lässt, das zu tun, was er gerade nicht soll: Daten preisgeben, unzulässige Werkzeuge aufrufen, Sicherheitsrichtlinien umgehen oder schädliche Inhalte erzeugen.

Bei Agenten verschärft sich das Problem durch drei Eigenschaften. Erstens Werkzeugzugriff: Ein kompromittierter Agent kann reale Aktionen auslösen, nicht nur Text ausgeben. Zweitens Autonomie: Mehrstufige Abläufe laufen ohne menschliche Bestätigung, sodass ein Fehler sich fortpflanzt. Drittens fremde Eingaben: Über Retrieval, Werkzeug-Ausgaben und Multi-Agenten-Kommunikation gelangen unkontrollierte Inhalte in den Kontext. Genau hier setzt die indirekte Prompt Injection an, die das OWASP-Projekt seit Jahren als Top-Risiko für LLM-Anwendungen führt — der Angriffsweg, den ein Prompt-Injection-Red-Team-Labor systematisch nachstellt.

Daraus folgt eine schlichte Konsequenz: Sicherheitstests für Agenten müssen automatisiert, wiederholbar und in den Entwicklungsprozess integriert sein. Ein einmaliger manueller Test vor dem Launch veraltet, sobald sich das Modell, der Prompt oder ein Werkzeug ändert. Genau diese Reproduzierbarkeit liefern die drei vorgestellten Frameworks — auf jeweils sehr unterschiedliche Weise.

Was prüft Garak und wofür ist es gemacht?

Garak ist der LLM-Schwachstellen-Scanner von NVIDIA. Der Name steht für „Generative AI Red-teaming and Assessment Kit“. Das mentale Modell ist denkbar einfach: Garak verhält sich zu einem Sprachmodell wie ein klassischer Schwachstellen-Scanner zu einem Server. Sie richten es auf ein Modell, lassen eine Batterie bekannter Tests laufen und erhalten einen Bericht, welche Probes durchgeschlagen sind.

Die Architektur folgt vier Bausteinen, die zusammenspielen. Generators stellen die Verbindung zum Zielmodell her — Garak unterstützt unter anderem OpenAI, Hugging Face und lokal über Ollama betriebene Modelle. Probes erzeugen die Angriffseingaben: Jede Probe ist darauf ausgelegt, genau eine Art von Schwachstelle hervorzurufen, und sendet teils tausende adversariale Prompts pro Lauf. Detectors bewerten anschließend, ob die Modellantwort die Schwachstelle bestätigt. Ein Harness orchestriert den Ablauf, ein Evaluator fasst die Ergebnisse zusammen.

Inhaltlich deckt Garak ein breites Spektrum bekannter Angriffsklassen ab: Prompt Injection, Anfälligkeit für Jailbreaks, Extraktion von Trainingsdaten, Halluzination nicht existierender Software-Pakete (ein realer Lieferkettenvektor), Erzeugung toxischer Inhalte, kodierungsbasierte Umgehungen sowie Versuche, Schadcode oder Cross-Site-Scripting über Modellausgaben zu erzeugen. Die Stärke liegt in der Breite und in der Geschwindigkeit: Ein einziger Befehl auf der Kommandozeile genügt, um eine fundierte Erstbewertung zu erhalten.

Der bewusste Verzicht auf Komplexität ist gleichzeitig die Grenze. Garak prüft in erster Linie ein Modell oder eine Modellschnittstelle, nicht eine vollständige Agenten-Anwendung mit ihrer Werkzeug-Logik, ihren Retrieval-Quellen und ihren mehrstufigen Abläufen. Wer wissen will, ob das Basismodell hinter seinem Agenten gegen einen Katalog bekannter Angriffe robust ist, erhält mit Garak schnell und ohne großen Einrichtungsaufwand eine belastbare Aussage. Wer das gesamte Agenten-Verhalten unter realistischen, eskalierenden Bedingungen untersuchen will, stößt an die Grenzen des Scanner-Ansatzes.

Was prüft PyRIT und worin liegt sein eigener Ansatz?

PyRIT — das „Python Risk Identification Tool“ — stammt aus dem AI Red Team von Microsoft und begann 2022 als Sammlung interner Skripte. Heute ist es ein offenes Framework, das automatisiertes und menschengeführtes Red-Teaming für generative KI-Systeme kombiniert. Der entscheidende Unterschied zu Garak: PyRIT ist kein fertiger Scanner, sondern ein erweiterbares Baukastensystem für Sicherheitsforschung. Es liefert Ihnen die Bausteine, aus denen Sie eigene Angriffsabläufe konstruieren.

Drei Komponenten prägen den Ansatz. Erstens die Prompt Converters: über 70 Wandler, die einen Ausgangs-Prompt verändern — etwa Base64, ROT13, Leetspeak, Unicode-Verwechslungszeichen, LLM-gestützte Umformulierung, Übersetzung oder multimodale Injektion. Damit lässt sich systematisch prüfen, ob ein Sicherheitsfilter umgangen werden kann, indem dieselbe Absicht anders verpackt wird. Zweitens die Attack Strategies: von der einfachen Einzelanfrage über den CrescendoAttack, der ein Modell schrittweise zur Grenzüberschreitung führt, bis hin zu „Tree of Attacks with Pruning“ und mehrstufigen Dialogangriffen. Drittens kuratierte Datasets mit adversarialen Prompts zu Inhaltsschäden, Jailbreaks, Datenexfiltration und sozialer Verzerrung.

Der eigene Charakter von PyRIT liegt in der Mehrstufigkeit und Adaptivität. Ein CrescendoAttack imitiert das Vorgehen eines geduldigen menschlichen Angreifers: Er beginnt harmlos und steigert den Druck über mehrere Gesprächsrunden, bis das Modell seine eigene Richtlinie verletzt. Genau diese eskalierenden, dialogischen Angriffe sind für Agenten relevant, weil ein Agent über viele Schritte hinweg interagiert und sein Kontext sich dabei verschiebt. Microsoft beschreibt, dass PyRIT in einem Red-Teaming-Einsatz auf einem Copilot-System erlaubte, mehrere tausend bösartige Prompts zu erzeugen und Ausgaben in Stunden statt Wochen zu bewerten.

Der Preis für diese Mächtigkeit ist die Einstiegshürde. PyRIT ist eine Python-Bibliothek, die Sie programmieren — kein Werkzeug für die schnelle Kommandozeilen-Prüfung. Es richtet sich an Sicherheitsforscherinnen und -ingenieure, die neuartige Risiken untersuchen, eigene Angriffsketten bauen und Ergebnisse in größerem Maßstab orchestrieren wollen. Für die schnelle Erstbewertung eines Modells ist es überdimensioniert; für ein ernsthaftes, fortlaufendes Red-Team-Programm ist es das ausdrucksstärkste der drei Werkzeuge.

Was prüft Promptfoo und warum ist es entwicklernah?

Promptfoo nähert sich dem Thema aus der Perspektive der Anwendungsentwicklung. Sein Ausgangspunkt war das Testen und Evaluieren von Prompts; daraus ist ein vollwertiges Red-Team-Modul gewachsen, das gezielt LLM-Anwendungen und -Agenten ins Visier nimmt — nicht nur das nackte Modell. Damit füllt es eine Lücke, die ein reiner Modell-Scanner offen lässt: die Sicherheit des Gesamtsystems aus Prompt, Werkzeugen, Retrieval-Quellen und Geschäftslogik.

Technisch arbeitet Promptfoo mit einem Plugin-System. Jedes Plugin zielt auf eine bestimmte Schwachstellenklasse und erzeugt passende bösartige Eingaben. Die Bibliothek umfasst über 150 Plugins in mehreren Kategorien — von Sicherheits- und Zugriffskontrolle über Vertrauen und Sicherheit bis zu Compliance, Marken- und Datensatzrisiken. Abgedeckt werden mehr als 50 Schwachstellentypen, von Injection bis Jailbreak. Ein eingebauter Scanner versucht systematisch, das Modell zu jailbreaken, und richtet sich dabei ausdrücklich an den OWASP Top 10 für LLM-Anwendungen aus — dem De-facto-Referenzkatalog für Risiken in diesem Feld.

Das eigentliche Unterscheidungsmerkmal ist die Integration in CI/CD. Promptfoo lässt sich so konfigurieren, dass es bei jedem Build läuft und den Build automatisch scheitern lässt, wenn eine KI-Komponente eine Regression zeigt oder neu verwundbar wird. Damit verschiebt sich Red-Teaming von einer punktuellen Aktivität vor dem Launch zu einer kontinuierlichen Kontrolle bei jeder Änderung. Für Teams, die Agenten in schnellen Zyklen ausliefern, ist das der entscheidende Hebel: Eine neue Prompt-Version oder ein zusätzliches Werkzeug wird automatisch gegen den definierten Angriffskatalog geprüft.

Ein praktischer Hinweis aus der Promptfoo-Dokumentation lohnt sich: Red-Teaming sollte idealerweise nach dem Einbau von Schutzmechanismen erfolgen, weil es dann zeigt, welche Schwachstellen trotz vorhandener Abwehr noch bestehen. Ein Test gegen ein völlig ungeschütztes System bestätigt nur das Offensichtliche.

Worin unterscheiden sich Garak, PyRIT und Promptfoo konkret?

Die drei Werkzeuge lassen sich am klarsten entlang von vier Achsen unterscheiden: Was sie als Zielobjekt verstehen, wie viel Programmierung sie verlangen, welche Tiefe an Angriffen sie ermöglichen und wo im Entwicklungszyklus sie ihren Platz haben. Die folgende Tabelle fasst die Unterschiede zusammen.

Kriterium	Garak (NVIDIA)	PyRIT (Microsoft)	Promptfoo
Grundtyp	Schwachstellen-Scanner	Forschungs-Framework / Baukasten	Entwickler- und Test-Werkzeug
Primäres Ziel	Sprachmodell / Modellschnittstelle	Modelle und Systeme, forschungsnah	LLM-Anwendungen und Agenten
Bedienung	Kommandozeile, kaum Setup	Python-Bibliothek, programmiert	Konfiguration (YAML) + CLI/Web-UI
Angriffstiefe	breiter Katalog bekannter Probes	mehrstufig, eskalierend, adaptiv	Plugin-basiert, OWASP-orientiert
CI/CD-Integration	weniger im Fokus	über eigenen Code möglich	Kernfunktion, Build-Gate
Idealer Nutzer	schnelle Modellbewertung	Sicherheitsforschung, Red Teams	Anwendungs- und Plattformteams
Lizenz	Open Source (NVIDIA + Community)	MIT, offen	Open Source

Der wichtigste konzeptionelle Unterschied steckt in der Zeile „primäres Ziel“. Garak prüft das Modell, Promptfoo prüft die Anwendung, und PyRIT prüft, was Sie ihm beibringen — vom Modell bis zum komplexen, mehrstufigen Szenario. Wer diesen Unterschied übergeht, läuft Gefahr, das falsche Werkzeug für die falsche Ebene einzusetzen und sich in falscher Sicherheit zu wiegen. Ein sauberer Garak-Bericht über das Basismodell sagt wenig darüber aus, ob Ihre Retrieval-Pipeline gegen indirekte Prompt Injection gewappnet ist.

Die zweite entscheidende Achse ist der Bedienaufwand. Garak und Promptfoo sind in Minuten startklar — Garak über die Kommandozeile, Promptfoo über eine Konfigurationsdatei. PyRIT verlangt, dass Sie Angriffe in Python zusammensetzen. Diese Hürde ist kein Mangel, sondern Ausdruck des Zwecks: PyRIT ist für Menschen gebaut, die neue Angriffe erfinden, nicht nur bekannte abspielen.

Wann sollten Sie welches Werkzeug einsetzen?

Statt sich für ein einziges Werkzeug zu entscheiden, ordnen reife Teams die drei entlang des Lebenszyklus an. Die folgenden Szenarien zeigen, welches Werkzeug wann den größten Nutzen stiftet.

Szenario 1 — Modellauswahl und schnelle Erstbewertung. Sie evaluieren mehrere Basismodelle für einen geplanten Agenten und wollen wissen, welches am robustesten gegen bekannte Angriffe ist. Hier ist Garak die richtige Wahl: ein Befehl pro Modell, ein vergleichbarer Bericht, geringer Aufwand. Das Ergebnis ist eine sachliche Entscheidungsgrundlage, kein vollständiger Sicherheitsnachweis.

Szenario 2 — Kontinuierliche Absicherung einer Agenten-Anwendung. Sie haben einen Agenten gebaut, der Werkzeuge aufruft und Dokumente verarbeitet, und liefern in kurzen Zyklen aus. Hier gehört Promptfoo in die CI/CD-Pipeline. Jeder Commit, der den System-Prompt, ein Werkzeug oder eine Retrieval-Quelle ändert, wird automatisch gegen den OWASP-orientierten Angriffskatalog geprüft. So fangen Sie Regressionen ab, bevor sie in Produktion gelangen.

Szenario 3 — Eigenes Red-Team-Programm und Forschung an neuartigen Angriffen. Sie betreiben ein Sicherheitsteam, das nicht nur bekannte, sondern neuartige Risiken untersuchen soll — etwa eskalierende Mehrrunden-Angriffe auf einen autonom handelnden Agenten. Hier ist PyRIT das Mittel der Wahl, weil es Ihnen die Bausteine gibt, um adaptive Angriffsketten zu konstruieren und in großem Maßstab auszuwerten.

Szenario 4 — Kombination über den gesamten Zyklus. In einem reifen Programm schließen sich die Werkzeuge nicht aus. Eine bewährte Staffelung lautet: Garak für die initiale Modellbewertung, Promptfoo als ständiges Build-Gate während der Entwicklung, PyRIT für gezielte Tiefenuntersuchungen vor wichtigen Releases oder bei der Erforschung neuer Bedrohungen. Diese drei greifen an unterschiedlichen Stellen und liefern zusammen ein deutlich vollständigeres Bild als jedes einzelne Werkzeug.

Die Auswahl sollte sich also nicht an Popularität orientieren, sondern an der Frage, welche Ebene Sie absichern und an welchem Punkt des Lebenszyklus Sie stehen. Ein Werkzeug, das gut zur Modellauswahl passt, ist für die kontinuierliche Anwendungssicherheit ungeeignet — und umgekehrt.

Was prüfen diese Werkzeuge bei Agenten nicht automatisch ab?

So nützlich die drei Frameworks sind, eine ehrliche Einordnung gehört dazu: Sie sind primär auf die sprachliche und modellbezogene Angriffsfläche ausgerichtet. Mehrere für Agenten kritische Risiken liegen ganz oder teilweise außerhalb ihres Standardumfangs und verlangen zusätzliche Maßnahmen.

Erstens die Werkzeug- und Berechtigungsebene. Ob ein Agent ein Werkzeug aufrufen darf, das er nicht hätte aufrufen dürfen, ob seine Rechte zu weit gefasst sind oder ob ein kompromittierter Agent Aktionen mit realen Nebenwirkungen auslöst — das deckt gezielt das Tool-Call-Fuzzing auf und ist zu einem guten Teil eine Frage von Architektur, Zugriffskontrolle und Sandboxing. Red-Teaming kann solche Schwächen aufdecken, beheben muss sie das System-Design.

Zweitens die mehrstufige indirekte Prompt Injection über reale Datenquellen. Wenn ein Agent ein manipuliertes Dokument aus einer echten Wissensdatenbank lädt, hängt das Ergebnis vom Zusammenspiel aus Retrieval, Kontextfenster und Werkzeug-Logik ab — genau diese Kette stellt ein Memory-Poisoning-Test im RAG-Labor kontrolliert nach. Generische Probes treffen dieses Zusammenspiel nur, wenn der Testaufbau die reale Pipeline einbezieht — was Konfigurationsarbeit erfordert.

Drittens organisatorische und regulatorische Anforderungen. Im DACH-Raum kommen Pflichten aus der DSGVO und zunehmend aus der KI-Verordnung (EU AI Act) hinzu. Kein Scanner ersetzt eine Datenschutz-Folgenabschätzung oder die Dokumentation von Risikomanagement-Prozessen. Die Werkzeuge liefern technische Belege, die in ein solches Programm einfließen, ersetzen es aber nicht.

Die nüchterne Schlussfolgerung: Automatisiertes Red-Teaming ist eine notwendige, aber keine hinreichende Bedingung für sichere Agenten. Es gehört in ein umfassenderes Sicherheitskonzept aus minimalen Berechtigungen, Sandboxing, menschlicher Kontrolle bei kritischen Aktionen und kontinuierlicher Überwachung im Betrieb.

Wie fügen sich diese Tools in einen sicheren Entwicklungsprozess ein?

Aus der Praxis lässt sich ein pragmatischer Ablauf ableiten, der die Werkzeuge sinnvoll verbindet, ohne ein eigenes Forschungslabor vorauszusetzen.

Beginnen Sie bei der Modellauswahl mit einem Garak-Lauf gegen die Kandidatenmodelle und dokumentieren Sie die Ergebnisse als Entscheidungsgrundlage. Bauen Sie die Anwendung anschließend mit Schutzmechanismen — System-Prompt-Härtung, Eingabe- und Ausgabefilter, restriktive Werkzeugrechte. Erst danach verankern Sie Promptfoo in der Pipeline, damit jede Änderung gegen den OWASP-orientierten Katalog läuft und ein Build bei einer Regression scheitert. Vor bedeutenden Releases oder bei Hinweisen auf neue Bedrohungsklassen ergänzen Sie gezielte PyRIT-Untersuchungen, um eskalierende und neuartige Angriffe zu prüfen, die ein Standardkatalog nicht abdeckt.

Wichtig ist, die Ergebnisse nicht als binäres „sicher/unsicher“ zu lesen, sondern als Risikolandkarte, die sich mit jeder Modell- und Prompt-Änderung verschiebt. Ein Agent, der gestern robust war, kann nach einem Modell-Update oder einer neuen Werkzeug-Anbindung neue Schwächen zeigen. Genau deshalb ist die Wiederholbarkeit das eigentliche Wertversprechen aller drei Werkzeuge — und der Grund, warum manueller Einzeltest sie nicht ersetzt.

Wer diesen Ablauf etabliert, gewinnt zweierlei: technische Belege für die Robustheit seiner Agenten und einen reproduzierbaren Prozess, der mit dem System mitwächst. Das ist die Grundlage, auf der sich Sicherheit für KI-Agenten von einer einmaligen Prüfung zu einer dauerhaften Eigenschaft des Entwicklungsprozesses wandelt.

Fazit

Garak, PyRIT und Promptfoo lösen drei verschiedene Probleme im Red-Teaming für KI-Agenten. Garak liefert die schnelle, breite Modellbewertung. PyRIT ermöglicht tiefe, mehrstufige und adaptive Angriffe für ernsthafte Sicherheitsforschung. Promptfoo verankert kontinuierliche Sicherheitstests für Anwendungen und Agenten in der CI/CD-Pipeline. Die richtige Wahl hängt davon ab, ob Sie ein Modell, eine Anwendung oder ein Forschungsprogramm absichern — und an welchem Punkt des Lebenszyklus Sie stehen. In reifen Teams ist es selten ein Entweder-oder: Die Werkzeuge ergänzen sich entlang der Wertschöpfungskette und ergeben zusammen ein Sicherheitsbild, das keines von ihnen allein liefern kann. Eines bleibt jedoch konstant: Automatisiertes Red-Teaming ist ein Baustein, kein Ersatz für ein durchdachtes Sicherheitskonzept aus minimalen Rechten, Sandboxing und menschlicher Kontrolle bei kritischen Aktionen.