Red-Teaming für AI Agents: Schwachstellen systematisch aufdecken

Red-Teaming für AI Agents bezeichnet das systematische, simulierte Angreifen von KI-Agenten, um Schwachstellen wie Prompt Injection, Jailbreaks, Tool-Missbrauch und Datenabfluss aufzudecken, bevor echte Angreifer sie ausnutzen. Es kombiniert automatisierte Angriffs-Tools mit manueller, mehrstufiger Angriffskreativität und liefert messbare Befunde wie Attack-Success-Rates statt binärer Schwachstellen-Listen. Anders als ein Funktionstest fragt es nicht „funktioniert der Agent?", sondern „wie lässt er sich gegen seinen eigentlichen Zweck missbrauchen?".

Dieser Artikel ist Teil des Hubs „AI-Agent-Sicherheit nach OWASP" und konkretisiert, wie Sie die im OWASP Agentic Top 10 (ASI01–ASI10) katalogisierten Risiken offensiv prüfen.

Drei Schnellantworten

• Was wird angegriffen? Die agentenspezifische Angriffsfläche – nicht nur das Modell, sondern Tool-Aufrufe, persistenter Speicher, Inter-Agenten-Kommunikation und der Human-in-the-Loop. Ziel ist das Aufdecken von Goal Hijack, Tool-Missbrauch, Memory-Poisoning und Datenabfluss.
• Womit? Open-Source-Scanner (Garak, PyRIT, DeepTeam, Promptfoo) für die Breite, manuelles Red-Teaming für die mehrstufigen Angriffe, plus Bug-Bounty für die Langzeitabdeckung.
• Wie oft? Quartalsweise Baseline plus auslösergesteuert (neue Tools, Prompt-Änderungen, Modell-Upgrades, akute CVEs).

Warum AI Red Teaming kein klassischer Pentest ist

Die wichtigste Abgrenzung vorweg: AI Red Teaming ist nicht synonym mit einem traditionellen Penetrationstest. DACH-Procurement-Teams verwechseln beide regelmäßig – mit teuren Folgen, wenn ein Burp-Suite-Pentest als „KI-Sicherheitsnachweis" akzeptiert wird.

Die Unterschiede sind fundamental:

Ein KI-Agent „bricht" oft gar nicht im klassischen Sinn – er folgt Instruktionen, von denen er getäuscht wurde, dass sie legitim seien. Weil Agenten und das zugrunde liegende Modell Instruktionen nicht zuverlässig von Daten unterscheiden können, ist jeder Text, den der Agent liest, Teil der Angriffsfläche. Das verlangt eine andere Prüfdisziplin.

Welche Schwachstellen ein Red-Team gezielt sucht

Das Red-Teaming arbeitet die agentenspezifischen Bedrohungsklassen des OWASP Agentic Top 10 ab. Praktisch heißt das, gezielt folgende Angriffe zu konstruieren:

• Prompt Injection / Goal Hijack (ASI01). Direkte und indirekte Injection – versteckte Instruktionen in Dokumenten, RAG-Korpus, E-Mails, Kalendereinladungen, PR-Beschreibungen oder Tool-Outputs. Besonders perfide: der „boiling-frog"-Multi-Turn-Drift, bei dem jeder Einzelschritt plausibel wirkt, die kumulative Trajektorie aber bösartig ist.
• Jailbreaks. Umgehung der Safety-Leitplanken, um verbotene Aktionen oder Inhalte auszulösen.
• Tool-Missbrauch (ASI02). Eine legitime Funktion (z. B. send_email) wird zweckentfremdet; Auto-Approve- bzw. „YOLO"-Modi, die Bestätigungsabfragen deaktivieren, werden ausgenutzt.
• Memory- und Context-Poisoning (ASI06). Einmal eingeschleuste Inhalte vergiften den persistenten Speicher dauerhaft; „delayed tool invocation" zündet erst Wochen später bei einem Trigger-Wort.
• Datenabfluss. Exfiltration über manipulierte Markdown-Bilder, Redirect-Ketten oder missbrauchte Proxies.
• Inter-Agenten-Angriffe (ASI07) und Human-Agent-Trust-Exploitation (ASI09). Gefälschte Nachrichten zwischen Agenten sowie das gezielte Aushebeln des menschlichen Freigabe-Layers durch souverän formulierte, aber manipulierte Empfehlungen.

Dass diese Angriffe real sind, belegen dokumentierte Vorfälle: EchoLeak (CVE-2025-32711, CVSS 9.3) war die erste reale zero-click Prompt Injection in einem produktiven LLM-System und umging Microsofts XPIA-Klassifikator (Cross-Prompt Injection Attempt). CamoLeak (CVSS 9.6) exfiltrierte über GitHubs eigenen Camo-Image-Proxy private Repository-Secrets und Quellcode zeichenweise. Beide zeigen: Jede veröffentlichte Guardrail wurde von kompetenten Forschern binnen Monaten umgangen.

Vorgehen: automatisiert vs. manuell

Reifes Red-Teaming kombiniert zwei Modi, die sich ergänzen.

Automatisiert bedeutet Skalierung und Wiederholbarkeit. Scanner spielen breite Probe-Bibliotheken gegen den Agenten und messen, welcher Anteil durchkommt. Sie eignen sich für die kontinuierliche Integration in CI/CD und für Regressionstests nach jeder Änderung. Schwäche: Sie finden überwiegend bekannte Angriffsmuster.

Manuell bedeutet Kreativität und Kontext. Erfahrene Analysten konstruieren mehrstufige, auf den konkreten Agenten zugeschnittene Kampagnen – genau jene Angriffe, die Scanner verfehlen. Beispiele aus der Forschung: das „Agent Session Smuggling" gegen Googles A2A-Protokoll (Palo Alto Unit 42, November 2025) ist keine Single-Shot-Injection, sondern eine anhaltende Social-Engineering-Kampagne Agent-gegen-Agent. Der Google-Gemini-Memory-Angriff (Johann Rehberger, Februar 2025) nutzte „delayed tool invocation", um den Speicher zeitversetzt zu vergiften.

Tools und Frameworks (Stand 2026)

Die folgenden Werkzeuge sind die in der Praxis etablierten Bausteine. Versions- und Marktangaben Stand 2026.

Kommerziell: Lakera Red (Schweizer Anbieter, DACH-relevant), HiddenLayer AIDR, Robust Intelligence (Cisco), Trustwise und Cranium.

Bug-Bounty mit KI-Scope: HackerOne (GitHub nutzte HackerOne für die CamoLeak-Disclosure), Bugcrowd und das EU-ansässige, DACH-freundliche Intigriti.

Reporting: messbar und framework-gemappt

Der Wert eines Red-Teamings steht und fällt mit dem Bericht. Da Befunde probabilistisch sind, müssen sie quantifiziert werden. Sinnvolle Kennzahlen:

• Attack-Success-Rate – Anteil erfolgreicher Angriffe pro Klasse.
• Detection-Rate – wie viele Angriffe das Monitoring erkannte.
• Time-to-Detection – wie lange bis zur Erkennung.
• Blast-Radius – wie viele nachgelagerte Agenten/Systeme betroffen wären.

Jeder Befund sollte auf etablierte Frameworks gemappt werden: OWASP Agentic Top 10 (ASI01–ASI10) als Risikoregister, MITRE ATLAS als Adversary-Playbook (mit der ehrlichen Einschränkung, dass ATLAS dem agentischen Frontier 6–12 Monate hinterherläuft, besonders bei ASI07, ASI08 und ASI10) und – aufkommend, Stand 2026 – AIVSS (Version 0.8, März 2026) für quantitatives Scoring. Befunde lassen sich zudem AVID-kompatibel strukturieren, was sie als reproduzierbare Audit-Evidenz für ISO 42001 A.5 und EU AI Act Art. 9 nutzbar macht. Wichtig für Procurement: „OWASP-compliant" ist keine belastbare Aussage – OWASP zertifiziert nicht.

Wie oft und wer

Frequenz (Faustregel): quartalsweise Baseline plus auslösergesteuert – vor jeder neuen Tool-Integration mit destruktiven Rechten, nach jeder substanziellen Prompt-/Systemnachricht-Änderung, nach jedem Modell-Version-Upgrade und ad-hoc, sobald ein CVE oder PoC den eigenen Stack betrifft.

Wer: Konzerne mit eigenem Agenten-Stack über sensiblen Daten halten ein dediziertes AI-Red-Team vor (in-house oder retained extern), das auf Garak, PyRIT und DeepTeam gegen das OWASP_ASI_2026-Framework arbeitet, plus ein Bug-Bounty-Programm. Mittelstands-Deployer von Managed-API-Agenten lagern Red-Teaming an spezialisierte Dienstleister aus, weil die ML-spezifischen Skills intern fehlen.

Für DACH-Finanzdienstleister ist das faktisch reguliert: DORA (Art. 24–27) fordert Threat-Led Penetration Testing, und die BaFin-Orientierungshilfe vom 18.12.2025 empfiehlt Adversarial Penetration Tests sowie die Simulation von Angriffen (Data Poisoning, Evasion) explizit. Beide sind formal nicht-bindend, kehren in Audits aber die Beweislast praktisch um.

Praxis-Beispiel mit Zahlen

Ein Versicherer betreibt einen Multi-Agenten-Workflow für die Schadensbearbeitung. Ein internes Red-Team konstruiert eine indirekte Injection: In einer eingescannten Arztbriefkopie wird per OCR-rekonstruierbarem Text die Instruktion versteckt, Fälle bestimmter Kategorien automatisch freizugeben. Der „Risk-Scoring"-Agent übernimmt die manipulierte Bewertung und reicht sie an „Pricing"- und „Compliance"-Agenten weiter.

Die gemessenen Kennzahlen: Attack-Success-Rate der Injection 1 von 1 (erfolgreich), Time-to-Detection > 4 Stunden, Blast-Radius 3 nachgelagerte Agenten. Zum Vergleich: Galileo-AI-Forschung (Dezember 2025) zeigte in simulierten Multi-Agenten-Systemen, dass ein einziger kompromittierter Agent 87 % der nachgelagerten Entscheidungsfindung binnen 4 Stunden vergiftete. Ein dokumentierter Manufacturing-Procurement-Vorfall (2025): Ein Agent wurde über drei Wochen schrittweise überzeugt, sein Freigabelimit liege bei 500.000 USD – der Angreifer platzierte anschließend 5 Mio. USD an falschen Bestellungen über 10 Transaktionen. Solche Befunde übersetzen abstrakte Risiken in vorstandstaugliche Zahlen.

Praxis-Checkliste

• Scope definieren: Welche Tools, Speicher, Inter-Agenten-Pfade und HITL-Gates sind in scope?
• Threat-Model-informierte Szenarien aus OWASP ASI01–ASI10 ableiten.
• Automatisierten Baseline-Scan (Garak/PyRIT/DeepTeam) in CI/CD verankern.
• Manuelle, mehrstufige Kampagnen ergänzen (boiling-frog, A2A, delayed invocation).
• Kennzahlen erheben: Attack-Success-Rate, Detection-Rate, Time-to-Detection, Blast-Radius.
• Befunde auf OWASP/MITRE ATLAS/AIVSS mappen, AVID-kompatibel dokumentieren.
• „Test-Injections" zur Prüfung, ob der Human-in-the-Loop tatsächlich greift.
• Kadenz festlegen: quartalsweise plus auslösergesteuert.

Für Agenturen und B2B-Entscheider

Wer Agenten für Kunden baut oder im eigenen Marketing- und Vertriebsstack einsetzt, sollte Red-Teaming als festen Bestandteil des Liefer- und Betriebsprozesses verstehen – nicht als einmaligen Abnahmetest. Für Agenturen ist es zugleich ein Differenzierungsmerkmal: nachweisbare Attack-Success-Rates und ein OWASP-gemapptes Reporting schaffen bei DACH-Kunden Vertrauen, das „wir nutzen Guardrails" nicht erreicht. Blck Alpaca unterstützt Sie dabei, ein zur Reife und Regulierung Ihres Hauses passendes Red-Teaming-Setup aufzubauen – von der Tool-Auswahl über die Szenario-Entwicklung bis zum audit-tauglichen Bericht. Sprechen Sie uns an, bevor Ihr Agent in Produktion geht.