Eine LLM-Anwendung zu shippem bedeutet, ein System zu shippem, dessen Fehlermodi keine Exceptions oder Stack Traces sind, sondern Outputs — ein Chatbot, das sein System Prompt leckt, ein Agent, das zu Aufrufen eines Tools überredet werden kann, das es nicht sollte, ein Support Assistant, das selbstbewusst eine Rückgabe-Richtlinie erfindet. Nichts davon wirft einen Fehler. Traditionelles Testen, das behauptet, dass eine Funktion einen erwarteten Wert zurückgibt, kann die meisten davon nicht ausdrücken. Die Disziplin, die emörstand, um diese Lücke zu füllen, ist LLM Red Teaming: absichtlich deine eigenes Modell und deine Anwendung angreifen, um die Eingaben zu finden, die unakzeptables Verhalten erzeugen, bevor jemand anderes das tut.
Bis 2026 hat das sich von Ad-hoc-Prompt-Experimenten zu einer Tool-Landschaft mit unterschiedlichen Layern entwickelt. Dieser Leitfaden maps diese Landschaft — garak und PyRIT bei der Model Layer, DeepTeam und promptfoo bei der Application Layer, Agentic Security für Black-Box Endpunkt-Fuzzing und Giskard und Inspect für Scanning und strenge Evaluation. Der Durchgang ist, dass diese Tools keine Konkurrenten sind: sie fangen unterschiedliche Fehler-Klassen, und nur einen zu laufen lässt vorhersehbare Lücken.
Was du tatsächlich testest
Bevor die Tools, hilft es, die Fehler-Klassen zu benennen, denn sie fordern unterschiedliche Tests. Jailbreaks und Prompt Injection sind die Schlagzeile: das Modell dazu bringen, seine Anweisungen zu ignorieren, entweder durch direkte Manipulation ("ignore previous instructions") oder indirekt durch Inhalt, den es abruft — ein vergiftetes Dokument, das Anweisungen trägt, denen das Modell dann folgt. Indirekte Injection ist die ernsthaftere Variante in RAG und Agent-Systemen, denn der Attacker berührt niemals die Prompt-Box.
Data Leakage deckt Extraktion des System Prompts, von PII, das das Modell im Kontext sah, oder von Training Data. Excessive Agency ist die Fehler-Klasse, die am meisten gefährlich wird, wenn Agenten Tools gewinnen: das Modell Aktion ergreifend, das es hätte verweigern sollen, oder Tools in einer Weise ketten, die seine beabsichtigte Autorität überschreitet. Harmful Content ist geradezu Einhaltung von Anfragen, die die Anwendung verweigern sollte. Und Hallucination — selbstsichere Fabrikation — ist oft das Höchste-Häufigkeit-Business-Risiko, obwohl es am wenigsten dramatisch ist.
Jede davon lebt bei unterschiedlichem Layer. Jailbreak-Anfälligkeit ist größtenteils eine Eigenschaft des Modells. Excessive Agency und Prompt Leakage sind Eigenschaften der Anwendung — sein System Prompt, seine Tools, seine Guardrails. Hallucination ist eine Eigenschaft der Pipeline, besonders Abruf-Qualität. Diese Layering ist genau, warum die Tools die Weise, die sie tun, spalten.
Model-Layer-Scanner: garak und PyRIT
garak (von NVIDIA) ist das nächstliegende Ding zu nmap für LLMs. Es läuft eine große Bibliothek von Probes gegen ein Modell — Jailbreak-Familien, Prompt Injection, Toxicity, Data Leakage, Encoding Attacks — und berichtet, welche erfolgreich waren. Du zeigst es auf ein Modell (ein HuggingFace-Modell, einen OpenAI-Endpunkt, einen lokalen Server) und es arbeitet durch seinen Katalog. Sein Wert ist Breite und niedriger Aufwand: du lernst schnell, welche bekannten Angriff-Familien dein Modell anfällig ist, ohne etwas selbst zu designen.
PyRIT (von Microsoft) targets ein schwierigeres Problem: Multi-Turn und Multi-Modal Attacks. Viele reale Jailbreaks funktionieren nicht in einer einzelnen Nachricht; sie funktionieren durch Etablierung von Kontext über mehrere Turns und gradueller Eskalation. PyRIT bietet Orchestration davon — Angriff Strategien wie Crescendo (Langsam Eskalation) und TAP (Baum-von-Angriffen mit Pruning), die basierend auf den Modell's Responses sich anpassen. Es ist mehr eines SDK als eines Scanner: du komponierst Orchestrators, Targets, Konverter und Scorer. Das macht es mehr Arbeit um zu starten und mächtiger für Forschung in Attacke, die eine Single-Shot Probe nicht finden kann.
Die Gemeinsame Limitation ist, dass beide hauptsächlich das Modell testen, nicht deine Anwendung. Ein Modell, das Garak's Probes in Isolation widersetzt, kann noch trivial innerhalb deiner App kompromittiert werden, denn dein System Prompt, dein Abruf und deine Tools schaffen eine Angriff-Oberfläche, die der Modell-Layer-Scan nie sah.
Application-Layer-Suites: DeepTeam und promptfoo
Das ist, wo DeepTeam und promptfoo passen. Beide testen deine Anwendung wie deployed, wrappend was auch immer deine App tatsächlich ist — Prompt, Abruf, Tools, Guardrails — und angreifend das gesamte Assembly.
DeepTeam, vom DeepEval Team, drückt Red Teaming als Python aus: du stellst ein model_callback zur Verfügung, das deine App ruft, deklarierst welche Anfälligkeiten zu proben sind (PII Leakage, Excessive Agency, Bias, Prompt Leakage) und welche Attacken zu verwenden sind, und es generiert und läuft adversariale Fälle. Seine Angriff Enhancements sind die interessanten Teile — derselbe Basis-Angriff umgeschrieben als base64, in einer anderen Sprache, als Roleplay oder eskaliert über Turns, welche ist, wie reale Attacker naive Filter umgehen. Denn es ist Code, es fällt in eine Test Suite und läuft in CI.
promptfoo kommt davon von Evaluation: es ist ein Config-getriebenes CLI zum Testen von LLM Outputs, das eine großartige Red-Teaming-Fähigkeit war, Auto-Generating Adversarial Prompts über Dutzende von Angriff Plugins und Mapping Befunde auf Compliance Frameworks. Seine Stärke ist CI Integration und die Tat, dass dieselbe Tool beide Qualität Evals und Sicherheit Tests deckt, sodass eine Harness beide Zwecke bedient.
Für die meiste Teams, die ein LLM Produkt shippem, matters dieser Layer mehr als der Modell Layer, denn es testet das Ding, das du tatsächlich deployed. Der Catch ist, dass es erfordert, dass du definierst, was "unakzeptabel" für deine Anwendung bedeutet — die Tools generieren die Attacken, aber du versorgst das Urteil über, welche Outputs Fehler sind.
Black-Box und Scanning Ansätze
Zwei andere Formen sind werth zu wissen. Agentic Security behandelt deinen Endpunkt als eine Black Box und fuzzt ihn agentically — generierend Probes, beobachtend Responses, adaptierend — mit der nützlichen Ergänzung von API Stress Testing. Das letzte Teile ist unterbewertet: eine bedeutende Share von LLM Deployments Fehler auf Rate Limits, Token Erschöpfung und Ressourcen Missbrauch bevor sie auf Content Safety Fehler, und die meisten Red-Teaming Tools ignorieren das ganz.
Giskard invertiert den üblichen Workflow. Anstatt zu erfordern, dass du spezifizierst, was zu testen, scannt es das Modell — nutzing deine Beschreibung von, was die App tut, um Domain-relevante Probes zu generieren — und erzeugt ein Bericht von erkannten Anfälligkeiten, die es dann in eine wiederverwendbare Test Suite konvertieren kann. Dieses Scan-Then-Testify Muster ist wertvoll genau, denn der schwierigste Teile von Red Teaming ist es zu wissen, worauf zu schauen. Giskard findet Probleme, die du nicht dachtest zu testen, dann sperrt sie als Regression Tests.
Schließlich sitzt Inspect vom UK AI Safety Institute leicht Apart: es ist ein strenge Evaluation Framework eher als ein Angriff Tool, aber seine Struktur (Datensätze, Solver, Scorer) und sein Excellent Transcript Viewer machen es die richtige Wahl, wenn du ein verteidigungs-fähig, reproduzierbar Measurement brauchst — inkludierend von Agentische Verhalten — eher als eine Anfälligkeits-Liste.
Bauen einer geschichteten Praxis
Das praktische Schließung ist, dass diese Tools komponieren. Ein vernünftig 2026 Praxis sieht wie das aus.
Wenn du ein Basis-Modell auswählst oder upgradest, führe einen Modell-Layer-Scanner aus — garak für Breite, PyRIT wenn Multi-Turn Robustheit dein Risiko-Profil wichtig ist. Das informiert Modell-Wahl und sagt dir, was die Foundation in selbst widersetzt.
Während Entwicklung, führe ein Scan-Style Tool wie Giskard gegen deine aktuale Anwendung aus um Fehler-Klassen zu entdecken, die du nicht angetiziert hattest und konvertiere seine Befunde in Tests.
In CI, auf jedem Prompt, Modell oder Tool Change, führe eine Application-Layer-Suite aus — DeepTeam oder promptfoo — als ein Gate. Das ist die Höchst-Wert Automation, denn Prompts und Tool Definitionen sind die Kontrolle-Oberfläche einer LLM App und sie ändern ständig. Ein Prompt Edit, der unschuldig scheint, kann den Satz entfernen, der eine Jailbreak verhindert.
Bevor Release, addiere Black-Box Fuzzing gegen den deployed Endpunkt, inkludierend Stress Testing, um Deployment-Level Probleme zu fangen, die Code-Level Tests vermissen.
Und halte Menschen darin. Jedes Automatisierte Tool testet bekannte Angriff-Familien. Novel Attacks — die Eins's, die zu deiner Domain, deinen Daten und deinen Tools spezifisch sind — kommen von einer Person, die das Business Logic versteht, denkend adversarially. Automation hebt den Floor; es ersetzt nicht die Decke.
Indirekte Injection: der Angriff, der das Modell bricht
Eine Angriff-Klasse verdient Separate Behandlung, denn es besiegte die Intuition, dass die meisten Teams anfangen mit. Direkte Prompt Injection — ein Benutzer typen "ignore your instructions" — ist, was jeder testet zuerst und es ist die Leichter Hälfte. Indirekte Prompt Injection ist, wenn die bösartige Anweisungen ankommen durch Inhalt, den das System abruft: ein Dokument in deinem Knowledge Base, eine Webseite, die der Agent browst, ein Email, das es zusammenfasst, ein Code Comment, das es liest. Der Attacker interagiert niemals mit deiner Prompt Box alls.
Das matter enorm für RAG Systeme und Agenten, denn ihre gesamte Wert-Proposition ist konsumieren Externe Inhalt. Ein Support Assistant, das von deiner Dokumentation beantwortet, wird treu folgen Anweisungen, die in einem Dokument embeddet sind, wenn jemand ein Dokument in den Corpus erhalten kann — durch ein Public Wiki, ein Customer-Einreichung Ticket oder eine Scraped Seite. Ein Agent, das ein GitHub Issue liest, kann sein instruierte von dem Issue. Die Vertrauen-Grenze, die Leute imaginieren ("Benutzer sind Unvertraute, unsere Daten sind Vertraute") hält nicht einmal, wenn irgendein Teile des Corpus Influenceable ist.
Testen davon ist schwieriger als Testen direkter Injection, denn es benötigt Simulieren von vergiftet Inhalt, nicht vergiftet Prompts — du musst Adversarial Text platzieren, wo Abruf ihn findet und Verifikation das Modell handelt nicht drauf. Application-Layer Tools handhaben das besser als Modell-Layer-Scanner, seit der Abruf-Pipeline Teile von, was sie exercisen, aber es erfordert oft, dass du das Szenario absichtlich konstruierst.
Die Mitigationen sind Architektur eher als Prompt-basiert. Behandle alle abgerufenen Inhalt als Unvertraute Input, die gleich Weg du behandelst Benutzer Input. Lass nicht abgerufene Text eine Position erreichen, wo es als Anweisungen interpretiert werden kann, wenn du es strukturell vermeiden kannst. Constrain, was Tools ein Agent kann während Verarbeitens Unvertraute Inhalt aufrufen und benötigen Bestätigung für konsequentielle Aktionen. Und halte Provenance: Wissen, welches Dokument eine Schlechte Antwort produziert ist, was einen Incident in ein Fix verwandelt.
Was Red Teaming nicht fixiert
Eine Warnung werth zu sagend Deutlich: finden eine Anfälligkeit ist nicht dasselbe als fixieren sie, und LLM Anfälligkeiten sind häufig nicht völlig fixierbar. Du kannst ein Modell nicht patchen die Weg du patchest einen Buffer Overflow. Die realistischen Responses sind Mitigation eher als Elimination: Stärker System Prompts, Input und Output Guardrails wie LLM Guard, Constrained Tool Berechtigungen, Menschliche Genehmigung für konsequentielle Aktionen und Überwachung für anomalisch Verhalten.
Das ändert, was ein Red Team Report bedeutet. In traditioneller Sicherheit, eine Befund impliziert ein Fix. In LLM Sicherheit, eine Befund impliziert häufig eine Risiko-Entscheidung: dieser Angriff erfolgreich bei einiger Rate, hier ist die Mitigation, hier ist das Restlich-Risiko, ist das akzeptabel für diesen Anwendungsfall? Teams, die erwarten, Red Teaming produziere eine saubere Bill von Gesundheit ist perpetually enttäuscht sein. Teams, die nutzen es zu quantifizieren und bewusst zu akzeptieren Risiko, kriegen reale Wert.
Die Korollar ist, dass Architektur Beats Prompt Engineering für die Fehler, die die meisten Matters. Ein Agent, das kann nicht getrickst werden in Transferring Geld, denn es strukturell lacks diese Berechtigung, ist sicherer als Eins verlassen sich auf das Modell zu verweigern. Excessive Agency ist beste Addressed durch weniger Agency zu geben. Red Teaming's Meisten nutzen Output ist häufig die Realisierung, dass eine Fähigkeit sollte nicht gewesen haben Exposed in die erste Platz.
Die Bottom Line
LLM Red Teaming wurde eine reale Disziplin, denn LLM Fehler sind Outputs eher als Errors, und ordinäre Testen können sie nicht ausdrücken. Die 2026 Tools teilen sich nach Layer, und dass Split ist der Schlüssel zu Nutzen it Well: garak und PyRIT probend das Modell, DeepTeam und promptfoo angreifend die Anwendung du tatsächlich deployed, Agentic Security fuzzend der Endpunkt inkludierend seine Ressourcen Limits und Giskard entdeckend Probleme du nicht wisstest zu schauen. Führe mehr als Eins, Gate CI auf die Application Layer, wo Prompts Change am meisten, halte Menschliche Adversarial Denken in der Loop und behandle Befunde als Risiko-Entscheidungen eher als Bugs zu erwarten ein Patch — dann fixe, was du kannst in der Architektur eher als in dem Prompt.
Ressourcen und Referenzen
Tools
Hintergrund und Analyse
- Best LLM Vulnerability Scanners 2026: Garak, PyRIT, Promptfoo
- LLM Red Teaming Guide 2026: Tools, Attacks & Methodology — AppSec Santa
- LLM Red Teaming Tools Compared — QAwerk
- awesome-ai-security-tools
Verwandte 1337skills Cheatsheets