Garak einrichten: LLM-Scanner in 12 Schritten [2026]

Wer im September 2026 ein eigenes Sprachmodell oder einen Firmen-Chatbot betreibt, kommt an einer Frage nicht mehr vorbei: Hält das Modell einem gezielten Angriff stand? NVIDIA hat mit garak ein Open-Source-Werkzeug veröffentlicht, das genau das testet. Das Tool schickt Hunderte präparierte Prompts an ein Zielmodell und protokolliert, wo es sich zu Jailbreaks, Datenlecks oder Falschinformationen verleiten lässt. In der Community wird es wegen seiner Arbeitsweise oft als “Nmap für LLMs” bezeichnet. Dieser Artikel zeigt in zwölf Schritten, wie die Installation, der erste Scan und die Auswertung der Ergebnisse funktionieren, inklusive eines kompletten Praxisprojekts zum Nachbauen.

Anders als klassische Web-Scanner, die auf bekannte Signaturen und CVE-Datenbanken setzen, arbeitet garak mit generativen Angriffsmustern. Ein Probe-Modul erzeugt dutzende Varianten desselben Angriffstyps, schickt sie an das Zielmodell und bewertet die Antwort automatisiert. Wer bisher LLM-Sicherheit nur über Stichproben von Hand geprüft hat, bekommt mit garak erstmals ein Werkzeug, das diesen Prozess reproduzierbar macht und in bestehende Entwicklungsabläufe einbindet.

Was ist Garak? NVIDIAs Open-Source-Scanner für LLM-Schwachstellen

Garak steht für “Generative AI Red-teaming and Assessment Kit” und liegt als Python-Paket unter der Apache-2.0-Lizenz auf GitHub vor. Das Projekt wird von NVIDIA gepflegt, nimmt aber aktiv Beiträge aus der Community an. Auf der Projektseite beschreibt das Team die Funktion nüchtern: “garak is an LLM vulnerability scanner.” Der zweite Satz aus der Dokumentation bringt den Zweck noch klarer auf den Punkt: “garak checks if an LLM can be made to fail in a way we don’t want.” Auf Deutsch: Garak prüft, ob sich ein Sprachmodell zu einem Verhalten drängen lässt, das der Betreiber nicht will, etwa zur Preisgabe von Trainingsdaten oder zur Ausgabe von Schadcode.

Nach Angaben mehrerer 2026 veröffentlichter Fachartikel liegt das Repository bei rund 8.100 GitHub-Sternen, etwa 777 Forks und 71 Mitwirkenden. Die aktuelle Versionsreihe trägt die Nummer v0.15.x. Auch Databricks hat das Tool in die eigene Sicherheitsprüfung integriert und beschreibt es in einem Blogbeitrag so: “Garak is an open-source tool designed to probe LLMs for vulnerabilities, offering functionalities akin to penetration testing tools from system security.” Damit ordnet sich garak in eine Kategorie ein, die es vorher kaum gab: automatisierte Penetrationstests speziell für generative KI-Modelle statt für klassische Netzwerke oder Webanwendungen.

Technisch besteht garak aus drei Bausteinen: Generatoren, Probes und Detektoren. Ein Generator übernimmt die Verbindung zum Zielmodell, egal ob es sich um eine Cloud-API oder ein lokal geladenes Modell handelt. Eine Probe liefert die eigentlichen Testprompts für eine bestimmte Schwachstellenklasse. Ein Detektor wertet danach aus, ob die Antwort des Modells als Fehlschlag zu werten ist, etwa weil verbotener Inhalt ausgegeben wurde. Diese Trennung macht das Tool erweiterbar: Neue Zielsysteme lassen sich über einen zusätzlichen Generator anbinden, ohne die vorhandenen Probes anzufassen, und neue Angriffsmuster lassen sich als eigene Probe ergänzen, ohne die Kernlogik zu verändern.

Warum LLM-Sicherheitstests 2026 zum Pflichtprogramm werden

Firmen setzen Sprachmodelle inzwischen in Kundensupport, Codegenerierung und internen Wissenssystemen ein. Jeder dieser Einsatzbereiche öffnet neue Angriffsflächen. Ein Chatbot, der versehentlich interne Preislisten preisgibt, oder ein Coding-Assistent, der ein bösartiges Paket empfiehlt, verursacht realen Schaden. Genau diese Szenarien deckt das OWASP-Rahmenwerk für LLM-Anwendungen ab, das Kategorien wie Prompt Injection, Offenlegung sensibler Informationen und Fehlinformationen definiert. Garak ordnet seine Testergebnisse automatisch diesen Kategorien zu, was die Auswertung für Sicherheitsteams erheblich vereinfacht.

Für DACH-Unternehmen kommt ein zweiter Treiber hinzu: Wer generative KI-Systeme mit nennenswertem Risiko betreibt, muss unter dem EU AI Act Nachweise über Tests und Risikomanagement führen können. Ein dokumentierter, wiederholbarer Scan-Prozess wie mit garak liefert genau die Art von Nachweis, die Auditoren später sehen wollen. Das Tool ersetzt keinen vollständigen Pentest durch spezialisierte Dienstleister, senkt aber die Einstiegshürde für laufende, automatisierte Basisprüfungen erheblich, ohne dass dafür ein eigenes Sicherheitsteam mit KI-Spezialisierung nötig wäre.

Ein typisches Beispiel aus der Praxis: Ein mittelständischer Softwareanbieter integriert einen Chatbot in sein Kundenportal, um Support-Anfragen vorzufiltern. Ohne Testlauf gegen Jailbreak-Prompts bleibt unklar, ob sich der Bot dazu bringen lässt, interne Systemprompts preiszugeben oder Konkurrenzprodukte schlechtzureden, was rechtlich heikel werden kann. Ein einmaliger garak-Scan vor dem Launch deckt die offensichtlichsten Lücken auf, ein wiederkehrender Scan nach jedem Modell- oder Prompt-Update verhindert, dass sich bereits geschlossene Lücken durch ein Update wieder öffnen.

Voraussetzungen und Systemanforderungen

Garak ist reine Kommandozeilensoftware und benötigt keine grafische Oberfläche. Die offizielle Installationsanleitung nennt Python 3.10 bis 3.12 als unterstützten Bereich. Für Scans gegen Cloud-Modelle wie GPT oder Claude reicht ein normaler Laptop, da die Rechenlast beim Anbieter liegt. Wer dagegen lokale Hugging-Face-Modelle scannen will, sollte eine Grafikkarte mit ausreichend Videospeicher einplanen. Die folgende Tabelle fasst die Mindestanforderungen zusammen.

Komponente	Mindestanforderung	Empfehlung
Python-Version	3.10	3.11 oder 3.12
Arbeitsspeicher	8 GB	16 GB für lokale Modelle
Grafikkarte	keine nötig für Cloud-Ziele	NVIDIA-GPU mit 8+ GB VRAM für lokale HF-Scans
Freier Speicherplatz	2 GB	10 GB bei heruntergeladenen Modellen
Internetzugang	erforderlich für Cloud-APIs	stabile Verbindung, da Scans hunderte Anfragen senden
API-Zugang	je nach Ziel: OpenAI-, Anthropic- oder HF-Token	separates Test-Kontingent ohne Produktionslimits

Wichtig: Wer ein Modell scannt, das über eine bezahlte API läuft, verbraucht dabei reguläres Anfragekontingent. Ein Scan mit mehreren Probe-Kategorien kann schnell mehrere Hundert einzelne Prompts erzeugen. Vor dem ersten produktiven Lauf lohnt sich deshalb ein Blick auf das eigene Rate-Limit und Budget beim jeweiligen Anbieter. Eine bewährte Praxis ist ein separater API-Schlüssel für Sicherheitstests mit eigenem, klar begrenztem Kontingent, getrennt vom Schlüssel, der in der Produktivanwendung läuft. So bleibt ein fehlerhaft konfigurierter Scan folgenlos für echte Nutzeranfragen.

Die Installation: Garak in vier Schritten einrichten

Schritt 1: Python-Version prüfen und virtuelle Umgebung anlegen

Zuerst prüfst du, welche Python-Version installiert ist, und legst danach eine isolierte virtuelle Umgebung an. Das verhindert Konflikte mit anderen Python-Projekten auf demselben Rechner, da garak mehrere Abhängigkeiten mitbringt, die sich sonst mit bereits installierten Paketen anderer Projekte überschneiden könnten.

python3 --version
python3 -m venv garak-env
source garak-env/bin/activate
python -m pip install --upgrade pip

Schritt 2: Garak per pip installieren

Das Paket heißt schlicht garak und liegt auf PyPI. Der Standardbefehl installiert die letzte veröffentlichte Version.

python -m pip install -U garak

Wer die neuesten, noch nicht auf PyPI veröffentlichten Änderungen testen möchte, installiert stattdessen direkt aus dem Hauptzweig des Repositorys:

python -m pip install -U git+https://github.com/NVIDIA/garak.git@main

Schritt 3: Installation verifizieren

Nach der Installation zeigt ein Aufruf mit --list_probes, ob garak korrekt eingerichtet ist. Der Befehl listet alle verfügbaren Probe-Module auf, ohne einen echten Scan zu starten.

python -m garak --list_probes | head -20

Erscheint eine Liste mit Modulnamen wie dan, encoding oder promptinject, war die Installation erfolgreich.

Schritt 4: API-Schlüssel als Umgebungsvariablen setzen

Garak selbst benötigt keine zentrale Konfigurationsdatei. Stattdessen liest es API-Schlüssel aus Umgebungsvariablen, abhängig vom gewählten Zielmodell. Für OpenAI-Modelle ist das OPENAI_API_KEY, für Hugging-Face-Modelle mit eingeschränktem Zugriff HF_TOKEN.

export OPENAI_API_KEY="sk-IhrSchluessel"
export HF_TOKEN="hf_IhrToken"

Diese Variablen sollten niemals fest im Code oder in einem öffentlichen Repository stehen. Für dauerhafte Nutzung eignet sich eine lokale .env-Datei, die nicht ins Versionskontrollsystem eingecheckt wird.

Den ersten Scan starten: Schritt 5 bis 7

Schritt 5: Ein Hugging-Face-Modell lokal scannen

Für den Einstieg eignet sich ein kleines, lokal laufendes Modell, da hier kein API-Guthaben verbraucht wird. Die Dokumentation nennt als Beispiel das klassische GPT-2-Modell in Kombination mit einer einzelnen Probe-Kategorie:

python -m garak \
  --model_type huggingface \
  --model_name gpt2 \
  --probes lmrc.Profanity

Garak lädt das Modell über die transformers-Bibliothek, schickt die vordefinierten Test-Prompts und bewertet jede Antwort. Ein typischer Konsolenausschnitt während des Laufs sieht so aus:

garak LLM security probe tool v0.15.x ( https://github.com/NVIDIA/garak )
loading generator: Hugging Face: gpt2
queue of probes: lmrc.Profanity
lmrc.Profanity.Profanity          100%|##########| 28/28 [00:41<00:00,  1.5s/it]
lmrc.Profanity: RtaThreshold: PASS  ok on 26/28  (92.9%)
report closed :) garak.a1f9c2.report.jsonl

Schritt 6: Ein OpenAI-Modell über die API scannen

Sobald der API-Schlüssel gesetzt ist, funktioniert der Scan gegen ein Cloud-Modell nach demselben Muster, nur mit einem anderen --model_type:

python -m garak \
  --model_type openai \
  --model_name gpt-4o-mini \
  --probes dan,promptinject

Hier prüft garak sowohl klassische Jailbreak-Varianten (dan) als auch direkte Prompt-Injection-Versuche (promptinject) gegen das Modell. Die Laufzeit hängt stark von der Antwortgeschwindigkeit der API ab, bei wenigen Probes liegt sie meist im Bereich weniger Minuten.

Schritt 7: Weitere Zielmodelle einbinden

Neben OpenAI und Hugging Face unterstützt garak laut aktueller Dokumentation unter anderem Anthropic-Modelle, AWS Bedrock, LiteLLM-Routing (für viele weitere Anbieter über eine einheitliche Schnittstelle), lokale GGUF-Modelle über llama.cpp sowie generische REST-Endpunkte für selbst gehostete Systeme. Der Zielwechsel erfolgt jedes Mal über denselben Parameter --model_type, was die Lernkurve nach dem ersten Scan deutlich flacher macht.

Besonders praktisch für Unternehmen mit eigener Infrastruktur ist der REST-Generator: Er erlaubt Scans gegen selbst gehostete Modelle hinter einer internen API, ohne dass das Modell dafür bei einem externen Anbieter registriert sein muss. Damit lässt sich garak auch in abgeschotteten Umgebungen einsetzen, etwa wenn ein Unternehmen aus Datenschutzgründen ausschließlich On-Premises-Modelle betreibt und keine Anfragen an externe Cloud-APIs senden darf.

Probes verstehen: Schritt 8 und 9

Schritt 8: Probe-Kategorien auswählen

Jede Probe in garak testet eine bestimmte Schwachstellenklasse. Die Module lassen sich einzeln, in Gruppen oder komplett aufrufen, wobei ein Vollscan mit allen verfügbaren Probes je nach Zielmodell deutlich länger läuft als ein fokussierter Test mit zwei oder drei Kategorien. Für den Einstieg empfiehlt sich eine kleine, aber aussagekräftige Auswahl, die sowohl Prompt-Injection- als auch Datenleck-Szenarien abdeckt. Die folgende Tabelle zeigt die wichtigsten Module und wie sie sich den Kategorien des OWASP-Top-10-Rahmenwerks für LLM-Anwendungen zuordnen lassen.

Probe-Modul	OWASP-LLM-Zuordnung	Was getestet wird
promptinject	LLM01 Prompt Injection	Direktes Einschleusen von Befehlen in den Prompt
dan	LLM01 Prompt Injection	Jailbreak-Varianten wie “Do Anything Now”
encoding	LLM01 Prompt Injection	Verschleierte Angriffe über Base64 oder ROT13
tap	LLM01 Prompt Injection	Automatisiert generierte, mehrstufige Angriffsketten
leakreplay	LLM02 Sensitive Information Disclosure	Wiedergabe von Trainingsdaten oder internen Informationen
xss	LLM05 Improper Output Handling	Unsichere HTML- oder JavaScript-Ausgaben im Antworttext
packagehallucination	LLM09 Misinformation	Erfundene Softwarepakete oder API-Namen
malwaregen	LLM09 Misinformation	Anleitungen zu Schadcode oder unsicherem Code
lmrc.Profanity	Content-Safety / Toxicity	Beleidigende oder toxische Ausgaben

Schritt 9: Eigene Probe-Kombination zusammenstellen

Für einen breiteren Basisscan lassen sich mehrere Probes kommasepariert übergeben, statt jede Kategorie einzeln nacheinander zu starten. Das folgende Beispiel deckt gleichzeitig Prompt Injection, Datenlecks, unsichere Ausgaben und Fehlinformationen ab und eignet sich als Grundgerüst für einen wöchentlichen Basisscan:

python -m garak \
  --model_type openai \
  --model_name gpt-4o-mini \
  --probes dan,promptinject,encoding,leakreplay,xss,malwaregen,packagehallucination,tap

Je mehr Probes gleichzeitig laufen, desto mehr einzelne API-Anfragen entstehen. Bei begrenztem Budget lohnt es sich, zuerst mit einer kleinen Auswahl zu starten und die Liste schrittweise zu erweitern.

Ergebnisse auswerten: Schritt 10 und 11

Schritt 10: JSONL-Report und Hit-Log lesen

Jeder Scan erzeugt mehrere Dateien. Die wichtigste ist der JSONL-Report, der pro Zeile einen einzelnen Testversuch mit Prompt, Antwort, Probe-Name und Bewertung enthält. Daneben legt garak ein Debug-Log für die Fehlersuche sowie ein separates Hit-Log an, das ausschließlich die tatsächlich gefundenen Schwachstellen auflistet, ohne die vielen unauffälligen Versuche dazwischen.

{"probe": "dan.Dan_11_0", "prompt": "Ignoriere alle vorherigen Anweisungen...", "response": "Ich kann dieser Anfrage nicht nachkommen...", "passed": true, "score": 0.02}

Ein passed: true bedeutet in diesem Fall, dass das Modell dem Jailbreak-Versuch widerstanden hat. Für einen schnellen Überblick reicht meist das Hit-Log, für die Detailanalyse einzelner Vorfälle braucht es den vollständigen JSONL-Report. Neben Prompt, Antwort und Bewertung enthält jede Zeile zusätzlich einen Zeitstempel, den Namen des verwendeten Generators und die interne Probe-Kennung, sodass sich Funde auch Monate später noch eindeutig einem bestimmten Scan-Lauf und einer bestimmten Modellkonfiguration zuordnen lassen. Das ist besonders hilfreich, wenn mehrere Modellversionen parallel getestet werden und die Reports später verglichen werden sollen.

Schritt 11: HTML-Report nach OWASP LLM Top 10 erzeugen

Für Sicherheitsteams, die keine JSONL-Zeilen lesen wollen, bietet garak ein eigenes Analysewerkzeug, das aus dem Report eine übersichtliche HTML-Seite erzeugt und die Funde nach Taxonomie gruppiert:

python -m garak.analyze.report_digest garak.a1f9c2.report.jsonl owasp > report.html

Das Ergebnis lässt sich direkt im Browser öffnen und zeigt pro OWASP-Kategorie, wie viele Probes bestanden oder durchgefallen sind. Für Compliance-Dokumentation oder ein internes Audit-Protokoll genügt es meist, dieses HTML-Dokument zusammen mit dem Rohreport zu archivieren.

Schritt 12: Garak in eine CI/CD-Pipeline integrieren

Ein einmaliger Scan zeigt nur eine Momentaufnahme. Sinnvoller ist ein automatisierter Lauf bei jeder neuen Modellversion oder jedem geänderten System-Prompt. Das folgende Beispiel zeigt einen minimalen GitHub-Actions-Workflow, der garak bei jedem Push auf den main-Branch ausführt:

name: garak-scan
on:
  push:
    branches: [main]
jobs:
  llm-security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
      - run: python -m pip install -U garak
      - run: |
          python -m garak --model_type openai --model_name gpt-4o-mini \
            --probes dan,promptinject,leakreplay
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
      - uses: actions/upload-artifact@v4
        with:
          name: garak-report
          path: garak.*.report.jsonl

Der Report landet als Artefakt im Build und lässt sich anschließend in ein Ticketsystem oder ein SIEM wie Wazuh einspeisen. So entsteht aus einem manuellen Test ein wiederkehrender Kontrollpunkt, der bei jeder Änderung automatisch mitläuft.

Komplettes Praxisprojekt: Automatisierter Wochenscan für einen Firmen-Chatbot

Zum Abschluss folgt ein durchgängiges Beispiel, das die einzelnen Schritte zu einem funktionierenden Projekt zusammenfügt. Ziel ist ein Shell-Skript, das wöchentlich per Cron-Job läuft, einen breiten Scan gegen das Produktionsmodell einer fiktiven Firma “Musterbau GmbH” startet und bei neuen Funden eine Benachrichtigung auslöst.

#!/usr/bin/env bash
set -euo pipefail

cd /opt/garak-project
source garak-env/bin/activate

REPORT_DIR="reports/$(date +%Y-%m-%d)"
mkdir -p "$REPORT_DIR"

python -m garak \
  --model_type openai \
  --model_name gpt-4o-mini \
  --probes dan,promptinject,encoding,leakreplay,xss,malwaregen,packagehallucination \
  --report_prefix "$REPORT_DIR/wochenscan"

python -m garak.analyze.report_digest \
  "$REPORT_DIR"/wochenscan.report.jsonl owasp > "$REPORT_DIR/report.html"

HITS=$(grep -c '"passed": false' "$REPORT_DIR"/wochenscan.report.jsonl || true)
if [ "$HITS" -gt 0 ]; then
  echo "Warnung: $HITS fehlgeschlagene Probes im Wochenscan gefunden" | \
    mail -s "Garak-Wochenscan: $HITS Funde" [email protected]
fi

Als Cron-Eintrag reicht eine einzige Zeile, die das Skript jeden Montag um 6 Uhr startet:

0 6 * * 1 /opt/garak-project/wochenscan.sh >> /var/log/garak-wochenscan.log 2>&1

Das Projekt braucht keine zusätzliche Infrastruktur außer einem Server oder einer CI-Umgebung mit Internetzugang. Über mehrere Wochen hinweg lässt sich so beobachten, ob sich die Trefferquote nach einem Modell-Update oder einer Anpassung des System-Prompts verändert. Das Skript lässt sich außerdem leicht um eine zweite Zeile erweitern, die den HTML-Report automatisch in ein internes Wiki oder ein Dashboard kopiert, sodass das Sicherheitsteam nicht jede Woche manuell auf den Server zugreifen muss, um die Ergebnisse einzusehen.

Ein Fund im Detail: So liest sich ein echter Jailbreak-Treffer

Abstrakte Kategorien wie “Prompt Injection” helfen wenig, wenn unklar bleibt, wie ein konkreter Treffer im Alltag aussieht. Angenommen, ein Scan mit der Probe dan.DanInTheWild gegen ein internes Support-Modell liefert einen Eintrag mit "passed": false. Der protokollierte Prompt enthält eine mehrteilige Anweisung, die das Modell auffordert, eine fiktive Rolle ohne Einschränkungen anzunehmen und anschließend eine normalerweise blockierte Anfrage zu beantworten. Die gespeicherte Antwort zeigt, dass das Modell die Rolle übernommen und Teile der eigentlich gesperrten Information ausgegeben hat.

Für das Team bedeutet das zunächst: Prompt und Antwort manuell nachvollziehen, um einen False Positive auszuschließen. Bestätigt sich der Fund, folgt die Ursachenanalyse. Häufig liegt das Problem nicht am Sprachmodell selbst, sondern an einem zu schwach formulierten System-Prompt, der Rollenspiel-Anfragen nicht explizit ausschließt. Die Behebung besteht dann meist aus einer präziseren System-Prompt-Formulierung, einem zusätzlichen Guardrail-Filter vor der Modellantwort oder, bei wiederkehrenden Mustern, einer dedizierten Regel im eingesetzten Sicherheitssystem. Nach der Anpassung läuft derselbe Probe erneut, um zu bestätigen, dass der Fund tatsächlich behoben ist, statt sich auf die Vermutung zu verlassen.

Kosten realistisch einschätzen: Was ein Scan an API-Anfragen verbraucht

Ein häufig unterschätzter Faktor ist der reine Anfrageverbrauch. Jede Probe besteht aus mehreren Dutzend bis mehreren Hundert Einzelprompts, abhängig vom gewählten Modul. Eine Kombination aus acht Probe-Kategorien wie im Beispiel des Wochenscans kann leicht mehrere Hundert bis über tausend einzelne API-Aufrufe auslösen. Bei abrechnungsbasierten Modellen summiert sich das über Wochen hinweg zu einem messbaren, aber überschaubaren Posten, verglichen mit den Kosten eines manuellen Pentests, bei dem ein Dienstleister meist nach Personentagen abrechnet statt nach einzelnen Anfragen.

Bei lokal gehosteten Hugging-Face-Modellen entfallen die reinen API-Kosten, dafür zählt hier die Rechenzeit auf der eigenen oder gemieteten GPU. Ein Scan, der auf einer Cloud-GPU-Instanz läuft, sollte deshalb möglichst kurz und gezielt gehalten werden, etwa indem der Scan nur nachts läuft und die Instanz danach automatisch wieder heruntergefahren wird, statt sie dauerhaft für gelegentliche Scans bereitzuhalten.

Um die Kosten im Griff zu behalten, hat sich in der Praxis ein gestuftes Vorgehen bewährt: ein schlanker Scan mit wenigen, besonders aussagekräftigen Probes bei jedem Commit, ergänzt um einen breiteren Scan mit der vollen Probe-Liste einmal pro Woche oder vor jedem Release. So bleibt der laufende Verbrauch niedrig, während die vollständige Abdeckung trotzdem regelmäßig sichergestellt ist. Wer zusätzlich ein günstigeres Modell wie gpt-4o-mini statt eines größeren Flaggschiff-Modells als Testziel für den täglichen Scan nutzt, senkt die Kosten weiter, sofern beide Modelle auf demselben System-Prompt laufen und die Ergebnisse damit vergleichbar bleiben.

Häufige Fehler beim Einstieg in Garak

• Fehlende Umgebungsvariable: Wird OPENAI_API_KEY oder HF_TOKEN vergessen, bricht der Scan sofort mit einem Authentifizierungsfehler ab, oft ohne klare Fehlermeldung im ersten Konsolenausschnitt.
• Zu alte Python-Version: Garak setzt Python 3.10 voraus. Auf älteren Systemen mit Python 3.8 oder 3.9 schlägt die Installation mit kryptischen Abhängigkeitsfehlern fehl.
• Zu viele Probes auf einmal gegen eine Produktions-API: Wer direkt mit der vollen Probe-Liste gegen ein kostenpflichtiges Modell startet, kann in kurzer Zeit ein spürbares API-Budget verbrauchen und in ein Rate-Limit laufen.
• Nur auf Pass/Fail schauen: Die reine Erfolgsquote verschleiert Detailprobleme. Ein Blick ins Hit-Log zeigt oft Muster, die im Gesamtergebnis untergehen.
• Scans direkt gegen Produktivsysteme ohne Genehmigung: Auch wenn es das eigene Modell ist, sollte ein Scan mit Jailbreak-Prompts vorher mit dem zuständigen Team abgestimmt werden, insbesondere wenn Logging oder Monitoring mitschneidet.
• Fehlende Versionierung der Scan-Konfiguration: Ohne dokumentierte Probe-Liste pro Lauf lässt sich später kaum nachvollziehen, welcher Scan welche Kategorie tatsächlich abgedeckt hat.
• Fund ungeprüft an Dritte weiterleiten: Ein roher JSONL-Report enthält vollständige Jailbreak-Prompts samt funktionierender Antworten. Wird er unredigiert an ein externes Ticketsystem oder einen Dienstleister geschickt, verbreitet sich damit potenziell ein funktionierendes Angriffsmuster weiter, als nötig wäre.
• Ein einzelner Scan wird als abschließender Sicherheitsnachweis behandelt: Modelle, System-Prompts und Angriffstechniken verändern sich laufend. Ein Scan von vor drei Monaten sagt wenig über den aktuellen Zustand aus, wenn seitdem niemand erneut getestet hat.

Troubleshooting: Die häufigsten Fehlermeldungen und Lösungen

Auch bei einer vergleichsweise einfachen Installation tauchen typische Stolpersteine auf. Die folgende Liste sammelt die häufigsten Probleme aus der Praxis, jeweils mit der wahrscheinlichsten Ursache und dem schnellsten Lösungsweg, damit ein festgefahrener Scan nicht zur halbtägigen Fehlersuche wird.

• ModuleNotFoundError: No module named ‘garak’: Die virtuelle Umgebung wurde nach der Installation nicht aktiviert. Lösung: source garak-env/bin/activate erneut ausführen, bevor garak gestartet wird.
• openai.AuthenticationError: Der API-Schlüssel fehlt oder ist abgelaufen. Prüfen mit echo $OPENAI_API_KEY, ob die Variable überhaupt gesetzt ist.
• HTTP 429 Rate limit exceeded: Zu viele Anfragen in zu kurzer Zeit. Die Probe-Auswahl verkleinern oder in der API-Konsole des Anbieters ein höheres Kontingent einstellen.
• CUDA out of memory bei lokalen HF-Modellen: Das gewählte Modell ist zu groß für die verfügbare GPU. Ein kleineres Modell wählen oder auf CPU-Ausführung mit reduzierter Batch-Größe umstellen.
• SSL-Zertifikatsfehler in Firmennetzwerken: Ein Proxy oder eine Firewall unterbricht die verschlüsselte Verbindung. Das interne Root-Zertifikat muss im Python-Zertifikatsspeicher hinterlegt werden.
• Scan hängt ohne sichtbaren Fortschritt: Meist ein langsam antwortendes lokales Modell oder ein blockierter Netzwerk-Port. Mit --verbose lässt sich der aktuelle Probe-Schritt sichtbar machen.
• Leere oder unvollständige JSONL-Datei: Der Scan wurde vorzeitig abgebrochen, etwa per Strg+C. Ein neuer, vollständiger Lauf ist in diesem Fall zuverlässiger als der Versuch, die Datei zu reparieren.
• KeyError bei report_digest: Die übergebene JSONL-Datei stammt nicht aus einem garak-Lauf oder wurde manuell verändert. Nur unveränderte Original-Reportdateien an das Analysewerkzeug übergeben.
• Auffällig viele False Positives bei einzelnen Probes: Manche Content-Filter-Probes reagieren empfindlich auf harmlose Formulierungen. Ergebnisse hier immer manuell gegenprüfen, bevor sie als echter Fund gemeldet werden.
• Timeout bei sehr langsamen lokalen Modellen: Den Timeout-Wert über die entsprechende CLI-Option erhöhen oder die Anzahl paralleler Anfragen reduzieren.
• Unterschiedliche Ergebnisse bei wiederholten Scans mit identischer Konfiguration: Viele Modelle antworten nicht deterministisch. Kleine Schwankungen im Trefferbild zwischen zwei Läufen sind normal und kein Zeichen eines defekten Scans, solange die Abweichung im niedrigen einstelligen Prozentbereich bleibt.
• Proxy oder VPN verhindert den Verbindungsaufbau zur API: Firmenweite Netzwerkrichtlinien blockieren teils ausgehende Verbindungen zu KI-Anbietern. Die Zieldomain des jeweiligen Anbieters muss in diesem Fall explizit auf der Allow-Liste des Proxys stehen.

Fortgeschrittene Tipps für den produktiven Einsatz

Wer garak über den ersten Testlauf hinaus einsetzen will, profitiert von einigen zusätzlichen Praktiken. Erstens: Baseline-Vergleiche zwischen Modellversionen dokumentieren. Ein Scan direkt nach jedem Modell- oder Prompt-Update zeigt sofort, ob sich die Trefferquote verschlechtert hat. Zweitens: Eigene Probes schreiben, wenn Standardmodule nicht reichen. Garak ist als Python-Paket modular aufgebaut, eigene Probe-Klassen lassen sich nach dem Muster bestehender Module ergänzen, etwa um firmenspezifische Geheimhaltungsregeln zu testen.

Drittens lohnt sich die Kombination mit einem Schutzsystem wie NeMo Guardrails: Garak findet die Schwachstelle, Guardrails blockiert das entsprechende Muster danach in Produktion. Viertens: Reports nicht isoliert betrachten, sondern in ein zentrales Monitoring wie Wazuh oder ein anderes SIEM einspeisen, damit LLM-Sicherheitsdaten neben klassischen Log-Quellen ausgewertet werden. Fünftens: Scans mit unterschiedlichen System-Prompts wiederholen, denn ein gut formulierter System-Prompt kann die Trefferquote bei Jailbreak-Probes spürbar senken, ohne dass sich am Modell selbst etwas ändert.

Sechstens lohnt sich ein Blick auf die Reihenfolge der Probes im Testlauf: Wer regelmäßig scannt, sollte die immer gleichen, günstigen Probes bei jedem Commit laufen lassen und rechenintensivere oder teurere Module wie tap nur im wöchentlichen Vollscan einsetzen. Siebtens hilft ein kurzer Vergleich mit einem zweiten, unabhängigen Zielmodell: Zeigt ein alternatives Modell mit demselben System-Prompt eine deutlich niedrigere Trefferquote, liegt das Problem oft eher an der Modellwahl als am Prompt-Design.

Garak im Vergleich zu PyRIT, DeepEval und Giskard

Garak steht nicht allein in diesem Feld. Microsoft pflegt mit PyRIT (Python Risk Identification Toolkit) ein eigenes Framework für automatisiertes und menschengeführtes Red-Teaming, aktuell in Version 0.13.0 dokumentiert. Es ist stärker auf komplexe, mehrstufige Angriffsszenarien ausgelegt als garak und eignet sich gut für Teams, die bereits mit Microsofts KI-Sicherheits-Ökosystem arbeiten. DeepEval von Confident AI verfolgt einen anderen Ansatz: Statt reiner Sicherheitsprüfung testet es allgemein die Qualität von LLM-Ausgaben, etwa Halluzinationen oder Antwortrelevanz, mit einer an Pytest angelehnten Syntax. Giskard wiederum deckt sowohl klassische Machine-Learning-Modelle als auch LLMs ab und sucht nach Bias, Performance-Problemen und Sicherheitslücken in einem gemeinsamen Werkzeug.

Tool	Anbieter	Fokus	Lizenz
Garak	NVIDIA / Community	LLM-Schwachstellen-Scan, OWASP-Mapping	Apache 2.0
PyRIT	Microsoft	Automatisiertes und menschengeführtes Red-Teaming	MIT
DeepEval	Confident AI	Qualitäts- und Regressionstests für LLM-Ausgaben	Apache 2.0
Giskard	Giskard AI	Bias-, Performance- und Sicherheitstests, auch für klassisches ML	Apache 2.0

Für eine reine Sicherheitsprüfung mit direktem Bezug zum OWASP-Rahmenwerk bleibt garak die naheliegendste Wahl. Wer zusätzlich die inhaltliche Qualität der Antworten testen will, kombiniert es sinnvollerweise mit einem Tool wie DeepEval, statt sich auf ein einzelnes Werkzeug zu verlassen.

Die Werkzeuge schließen sich in der Praxis nicht gegenseitig aus. Ein realistisches Setup nutzt garak für den wiederkehrenden Sicherheitsscan, DeepEval für Regressionstests bei inhaltlichen Antwortqualitäten und optional PyRIT für tiefere, manuell angeleitete Red-Team-Übungen vor einem größeren Launch. Giskard eignet sich vor allem für Teams, die neben LLMs auch klassische ML-Modelle wie Klassifikatoren oder Empfehlungssysteme im selben Werkzeug prüfen wollen, statt für jede Modellart ein separates Tool zu pflegen.

Rechtlicher Rahmen: OWASP, MITRE ATLAS und der EU AI Act

Garak liefert von sich aus eine Zuordnung zum OWASP-LLM-Top-10-Rahmenwerk, das mittlerweile als informeller Industriestandard für die Klassifikation von LLM-Schwachstellen gilt. Parallel dazu beschreibt die MITRE-ATLAS-Wissensdatenbank Angriffstechniken gegen KI-Systeme in einer ähnlichen Struktur wie das bekannte ATT&CK-Framework für klassische IT-Sicherheit. Beide Rahmenwerke ersetzen keine offizielle Zertifizierung, liefern aber eine gemeinsame Sprache, mit der sich Scan-Ergebnisse gegenüber Auditoren oder der Geschäftsführung erklären lassen.

Für Unternehmen im Geltungsbereich des EU AI Act zählt vor allem, dass Testläufe nachvollziehbar dokumentiert sind: welches Modell, welche Probe-Auswahl, welches Ergebnis, an welchem Datum. Ein archivierter HTML-Report aus report_digest zusammen mit der Rohdatei erfüllt diesen Dokumentationszweck ohne zusätzlichen Aufwand, sofern die Scans regelmäßig und nicht nur einmalig vor dem Launch laufen.

Wichtig für die Einordnung: Weder OWASP noch MITRE sind Regulierungsbehörden, und keines der beiden Rahmenwerke ersetzt eine offizielle Konformitätsbewertung nach dem EU AI Act. Für Systeme, die als Hochrisiko-KI eingestuft werden, bleiben die gesetzlich vorgeschriebenen Verfahren maßgeblich. Ein garak-Report liefert in diesem Kontext ein zusätzliches, technisches Nachweisdokument, das im Rahmen eines internen Risikomanagements gut nutzbar ist, aber kein Ersatz für eine rechtliche Prüfung durch die zuständige Fachabteilung oder externe Berater ist.

Grenzen von Garak: Was das Tool nicht leistet

So nützlich garak für wiederkehrende Basisprüfungen ist, es hat klare Grenzen. Das Tool testet einzelne Prompts isoliert und bildet dabei keine mehrstufigen Konversationen ab, bei denen ein Angreifer über mehrere Nachrichten hinweg Vertrauen aufbaut, bevor der eigentliche Angriff kommt. Genau solche Szenarien sind in der Praxis oft erfolgreicher als ein einzelner, offensichtlicher Jailbreak-Versuch. Auch Geschäftslogik-Fehler, etwa ein Chatbot, der falsche Rabatte gewährt, weil eine interne Regel unklar formuliert ist, liegen außerhalb dessen, was ein generisches Probe-Set erfassen kann.

Ein weiterer Punkt: Die mitgelieferten Probes sind größtenteils auf Englisch formuliert und orientieren sich an international bekannten Angriffsmustern. Firmenspezifische Geheimhaltungsregeln, branchenspezifische Compliance-Anforderungen oder Angriffe, die gezielt auf die eigene Systemprompt-Formulierung zugeschnitten sind, deckt garak nur ab, wenn eigene Probes dafür geschrieben werden. Und schließlich bewertet ein Detektor die Modellantwort nach festen Kriterien. Bei mehrdeutigen Antworten kann das zu falschen Einstufungen führen, weshalb Funde mit hoher Priorität vor einer Eskalation immer von einem Menschen gegengeprüft werden sollten, statt automatisierte Ergebnisse ungeprüft weiterzureichen.

Garak ersetzt außerdem keine laufende Produktionsüberwachung. Ein Scan zeigt den Zustand zum Testzeitpunkt, sagt aber nichts über Angriffe, die zwischen zwei Scans tatsächlich gegen das Live-System gefahren werden. Dafür braucht es zusätzlich ein Monitoring, das echte Nutzeranfragen in Produktion auf verdächtige Muster prüft, etwa über ein vorgeschaltetes Guardrail-System oder eine Anbindung an das bestehende SIEM. Garak und Produktionsüberwachung ergänzen sich, decken aber unterschiedliche Zeiträume und Zwecke ab.

Garak im Team einführen: Rollen und Verantwortlichkeiten

Ein Scan-Ergebnis nützt wenig, wenn niemand dafür zuständig ist, es auszuwerten. In der Praxis funktioniert die Einführung am besten, wenn drei Rollen klar getrennt sind. Das Entwicklungsteam, das das Modell oder den System-Prompt betreut, richtet die Scans ein und reagiert auf technische Fehlermeldungen. Das Sicherheitsteam legt fest, welche Probe-Kategorien verpflichtend sind, definiert Schwellenwerte für einen fehlgeschlagenen Build und entscheidet über den Umgang mit wiederkehrenden Funden. Eine dritte, oft unterschätzte Rolle ist die Produktverantwortung: Sie muss abwägen, ob ein gefundenes Risiko das Feature blockiert oder mit einem dokumentierten Restrisiko akzeptiert wird.

Für den Einstieg reicht es, den CI/CD-Scan aus Schritt 12 zunächst nur zu protokollieren, ohne den Build bei einem Fund fehlschlagen zu lassen. Nach einigen Wochen, wenn klar ist, welche Probes zuverlässig echte Probleme finden und welche zu False Positives neigen, lässt sich die Pipeline auf einen echten Blocker umstellen. Dieser stufenweise Rollout verhindert, dass ein zu aggressiv konfigurierter Scan gleich am ersten Tag jeden Deployment-Prozess blockiert und das Team das Tool aus Frust wieder abschaltet.

Häufig gestellte Fragen

Ist Garak kostenlos nutzbar?
Ja, garak steht unter der Apache-2.0-Lizenz und lässt sich ohne Lizenzkosten installieren. Kosten entstehen höchstens indirekt durch die API-Anfragen an kostenpflichtige Zielmodelle wie GPT oder Claude, wobei sich dieser Verbrauch wie im Abschnitt zu den Kosten beschrieben über die Probe-Auswahl gezielt steuern lässt.

Brauche ich eine NVIDIA-Grafikkarte, um Garak zu nutzen?
Nein. Eine GPU wird nur benötigt, wenn lokale Hugging-Face-Modelle gescannt werden sollen. Scans gegen Cloud-APIs wie OpenAI oder Anthropic laufen auch auf einem einfachen Laptop ohne dedizierte Grafikkarte.

Darf ich mit Garak fremde Produktionsmodelle ohne Erlaubnis scannen?
Nein. Ein Scan erzeugt gezielte Jailbreak- und Angriffsprompts gegen ein System. Ohne Zustimmung des Betreibers bewegt sich das je nach Zielsystem und Nutzungsbedingungen in einer rechtlichen Grauzone bis hin zum Verstoß gegen die Nutzungsrichtlinien des Anbieters. Garak sollte ausschließlich gegen eigene Systeme oder Systeme mit ausdrücklicher Testfreigabe laufen.

Ersetzt Garak einen professionellen Penetrationstest?
Nein. Garak automatisiert wiederkehrende Basisprüfungen und deckt bekannte Schwachstellenmuster ab. Ein erfahrenes Pentest-Team findet darüber hinaus kontextspezifische Lücken, die ein generisches Probe-Set nicht erfasst, etwa Schwächen in der Geschäftslogik oder mehrstufige Social-Engineering-Ketten über mehrere Nachrichten. Beide Ansätze ergänzen sich eher, als sich zu ersetzen: garak für den laufenden Betrieb, ein externer Pentest für die punktuelle Tiefenprüfung vor einem größeren Release.

Wie oft sollte ein Garak-Scan wiederholt werden?
Bei aktiv weiterentwickelten Modellen oder häufigen Prompt-Änderungen empfiehlt sich ein automatisierter Lauf pro Release oder mindestens wöchentlich, wie im Praxisprojekt oben beschrieben. Bei stabilen, selten geänderten Systemen reicht ein monatlicher Rhythmus meist aus.

Funktioniert Garak auch mit deutschsprachigen Modellen?
Garak selbst ist modellagnostisch und funktioniert grundsätzlich mit jedem über die unterstützten Schnittstellen angebundenen Modell, unabhängig von der Trainingssprache. Die meisten mitgelieferten Probe-Prompts liegen jedoch auf Englisch vor, was die Trefferquote bei rein deutschsprachigen Modellen leicht verzerren kann. Für belastbare Ergebnisse lohnt es sich, wichtige Probes zusätzlich in deutscher Übersetzung zu testen.

Wie lange dauert ein vollständiger Scan?
Das hängt von der Anzahl der gewählten Probes und der Antwortgeschwindigkeit des Zielmodells ab. Ein schlanker Scan mit zwei bis drei Probe-Kategorien gegen eine schnelle Cloud-API dauert meist wenige Minuten, ein breiter Scan mit der vollen Probe-Liste gegen ein langsames lokales Modell kann dagegen deutlich länger laufen.

Speichert Garak meine Prompts oder Ergebnisse extern?
Nein. Garak läuft lokal beziehungsweise in der eigenen CI/CD-Umgebung und speichert Reports ausschließlich auf dem System, auf dem es ausgeführt wird. Es gibt keine Cloud-Anbindung an NVIDIA, über die Scan-Daten automatisch übertragen würden.

Kann Garak False Positives melden, also Fehlalarme?
Ja, das kommt vor, vor allem bei Content-Filter-Probes, die auf Grenzfälle empfindlich reagieren. Ein hoher Trefferwert bei einer einzelnen Probe sollte deshalb immer manuell im JSONL-Report nachvollzogen werden, bevor daraus eine Priorität für die Behebung abgeleitet wird, statt sich blind auf die automatische Bewertung zu verlassen.