AI Security Testing: OWASP AI Testing Guide und NVIDIA Garak im Vergleich

Unit-Tests prüfen Funktionen mit festen Inputs. LLM-Agents arbeiten probabilistisch: Derselbe Prompt kann morgen eine andere Antwort liefern, ein indirekter Kontext kann eine Policy umgehen, und ein Tool-Call kann Daten exfiltrieren, obwohl alle klassischen Checks grün sind. Für Teams, die KI-gestütztes Coding im Unternehmen skalieren, ist AI Security Testing deshalb kein Nischenprojekt der Security-Abteilung, sondern Teil der Softwarequalität.

Zwei Referenzen setzen sich in der Praxis durch: Der OWASP AI Testing Guide v1 liefert eine audit-taugliche Methodik über vier Architekturschichten. Garak von NVIDIA automatisiert Angriffsprobes gegen Modelle und Dialogsysteme. Dieser Artikel ordnet beides ein, zeigt Alternativen, CI-Integration und die Verbindung zu Autonomiestufen bei Agentic Coding.

Warum klassische Tests für LLM-Agents nicht reichen

Ein Coding-Agent in Cursor oder Claude Code durchläuft oft dutzende Modellaufrufe: Planung, Dateizugriff, Shell, Commit. Jeder Schritt ist ein Angriffs- und Fehlervektor. Prompt Injection kann über README-Dateien im Repo erfolgen. Excessive Agency kann dazu führen, dass ein Agent Befehle ausführt, die niemand freigegeben hat. Halluzinationen wirken wie korrekte API-Dokumentation, bis die falsche Bibliothek in Produktion landet.

Klassische SAST- und Unit-Tests sehen den Prompt-Pfad nicht. Du brauchst wiederholbare Sicherheits- und Vertrauensprüfungen, die Modell-, Prompt- und Infrastrukturänderungen abdecken. Genau hier setzen OWASP und Garak an.

OWASP AI Testing Guide v1

Der OWASP AI Testing Guide wurde im November 2025 als Version 1 veröffentlicht. Er ist die erste offene, community-getriebene Standardisierung für Trustworthiness Testing von KI-Systemen und baut auf Googles Secure AI Framework (SAIF) auf. Statt nur Risiken zu benennen, liefert der Guide wiederholbare Testfälle über vier Schichten:

• AI Application Layer (AITG-APP): Prompt Injection, indirekte Injection, sensible Datenlecks, Halluzination, excessive Agency, Output-Manipulation.
• AI Model Layer (AITG-MOD): Evasion, Runtime Poisoning, Membership Inference, Model Extraction, Robustheit bei neuen Daten.
• AI Infrastructure Layer (AITG-INF): Supply-Chain-Tampering, Resource Exhaustion, Plugin-Grenzverletzungen, Fine-Tuning Poisoning, Model Theft in der Entwicklung.
• AI Data Layer (AITG-DAT): Training Data Exposure, Runtime Exfiltration, Dataset-Coverage, schädliche Inhalte, Data Minimization und Consent.

Der Guide mappt Bedrohungen aus dem OWASP Top 10 for LLM Applications auf diese Schichten. Für Entwickler, Architekten und Auditoren ist das die Checklisten-Schicht: nicht nur „was kann schiefgehen“, sondern „wie teste ich es dokumentiert und wiederholbar“. In DevSecOps-Pipelines eignet sich der Guide als Abnahmekriterium nach Modell-, Prompt- oder Datenänderungen.

NVIDIA Garak: automatisierte Angriffsprobes

Garak (Generative AI Red-teaming and Assessment Kit) ist ein LLM-Vulnerability-Scanner. Wer nmap oder Metasploit kennt, findet ein ähnliches Prinzip: Garak feuert Probes gegen ein Zielmodell und wertet Antworten mit Detectors aus. Abgedeckt werden unter anderem Halluzination, Datenlecks, Prompt Injection, Fehlinformation, Toxicity, Jailbreaks und Encoding-Tricks.

Die Architektur trennt Generatoren (Anbindung an OpenAI, Hugging Face, lokale Modelle), Probes (Angriffsszenarien) und Detectors (Schwachstellen-Erkennung). Per CLI listest Du verfügbare Probes (garak --list_probes) und schränkst Scans ein, z. B. nur PromptInject-Framework. Reports dokumentieren, welche Probes durchkamen. Garak ersetzt kein manuelles Red Teaming, beschleunigt aber Regressionen bei Baseline-Modellen und Prompt-Versionen erheblich.

OWASP vs. Garak: Methodik und Scanner

Beide ergänzen sich, sie konkurrieren nicht:

• OWASP AI Testing Guide: Breite Abdeckung über Application, Model, Infrastructure und Data; menschenlesbar, audit-tauglich, technologieagnostisch. Hoher manueller Anteil bei der Ausführung einzelner Testfälle.
• Garak: Fokus auf automatisierte Modell- und Dialog-Schwachstellen; schnelle Scans, gut für CI, aber kontextabhängig. Deckt nicht jede Infrastruktur- oder Daten-Layer-Prüfung des OWASP-Guides ab.

In der Praxis nutzt Du OWASP für die Testmatrix und Release-Checkliste, Garak für automatisierte Regression auf dem konkreten Modell-Endpoint. Findings aus Garak ordnest Du den AITG-Kategorien zu, damit Audit und Entwicklung dieselbe Sprache sprechen.

Alternativen im Überblick

Kein einzelnes Tool deckt alles ab. Ergänzend oder alternativ kommen infrage:

• Manuelles Red Teaming und Purple-Team-Sessions: unverzichtbar vor High-Risk-Releases und für domänenspezifische Angriffe.
• Eigene Eval-Datasets in Observability-Plattformen: domänenspezifische Fälle, höherer Pflegeaufwand, dafür nah am Produktkontext.
• LLM-as-a-Judge-Pipelines: skalierbare Qualitäts- und Policy-Checks, weniger Fokus auf klassische Jailbreak-Corpora.
• Gateway- und DLP-Schichten vor dem Modell: präventiv, kein Ersatz für Post-Deployment-Tests.
• OWASP GenAI Red Teaming Guide: vertieft Red-Team-Methodik, ergänzt den AI Testing Guide.

Für Agentic Coding lohnt die Kombination: Garak für bekannte Angriffsmuster, OWASP für die vollständige Schichtenabdeckung, eigene Evals für Geschäftslogik und Tool-Policies.

CI-Integration und Qualitätsgates

AI Security Testing gehört in dieselbe Pipeline wie Lint, Typecheck und E2E. Ein pragmatischer Ablauf:

• Pull Request: Garak-Subset gegen Staging-Modell oder Prompt-Fixture; Schwellenwert für kritische Probes (z. B. Injection, Leakage).
• Release-Kandidat: erweiterter Garak-Lauf plus stichprobenartige OWASP-Testfälle aus Application und Infrastructure Layer.
• Nach Modell-Upgrade: vollständige Regression, weil Verhalten sich ohne Codeänderung verschieben kann.

Ergebnisse speicherst Du als Artefakte. Koppel sie mit Traces aus Langfuse für LLM Observability, damit klar ist, welcher Prompt- oder Modellwechsel eine Regression ausgelöst hat. In kurzlebigen CI-Jobs musst Du Telemetrie explizit flushen, sonst gehen Events verloren.

Blockierende Gates definierst Du nach Risiko: Ein Jailbreak in einer internen Dokumentationshilfe ist weniger kritisch als Datenexfiltration in einem Agenten mit Produktions-DB-Zugriff. Das passt zur Softwareentwicklung mit Qualitätsgates, die wir für produktionsreife Systeme empfehlen.

Autonomiestufen und Testtiefe

Die Testtiefe muss zur Autonomiestufe des Agents passen. Unser Vier-Stufen-Modell für Unternehmen:

• Stufe 1 (Vorschlagen): Garak-Light auf Demomodellen, OWASP-Stichproben, starker menschlicher Review.
• Stufe 2 (Ausführen unter Aufsicht): Garak in CI auf Prompt-Versionen, AITG-APP-Tests für Injection und Leakage.
• Stufe 3 (Teilautonom in Workflows): harte Gates für Tool-Policies, AITG-INF für Plugin-Grenzen, Traces für jeden Agenten-Lauf.
• Stufe 4 (Hochautonom mit engen Grenzen): vollständige OWASP-Matrix, erweiterte Garak-Probes, periodisches manuelles Red Teaming, Incident-Playbooks.

Je höher die Autonomie, desto weniger reicht „wir haben Unit-Tests“. Ownership bleibt beim Menschen: Der Guide und Garak liefern Evidenz, nicht Entlastung von Verantwortung.

Fazit

AI Security Testing ist Teil produktionsreifer Software, nicht ein optionales Security-Add-on. Der OWASP AI Testing Guide v1 gibt den Rahmen über Application, Model, Infrastructure und Data. Garak automatisiert wiederholbare Angriffsprobes gegen LLMs und Agents. Alternativen und manuelles Red Teaming bleiben wichtig für domänenspezifische Risiken.

Wer Agentic Coding ernst nimmt, verankert beides in CI, koppelt Findings mit Observability und skaliert die Testtiefe mit der Autonomiestufe. So bleibt Geschwindigkeit ohne Blindflug in Produktion.