Kurz zusammengefasst
- Red Teaming sucht kreativ nach Schwachstellen, während normale Evals bekannte Anforderungen wiederholbar messen.
- Der Umfang umfasst Modell, Anwendung, Identität, Daten, Retrieval, Tools, Infrastruktur und menschlichen Prozess.
- Tests brauchen klare Regeln, sichere Umgebungen, erlaubte Ziele und einen verantwortlichen Umgang mit gefundenen Daten.
- Funde werden priorisiert, behoben und als dauerhafte Regressionstests in den Entwicklungsprozess übernommen.
Was wird beim AI Red Teaming geprüft?
Der Test orientiert sich am realen Einsatz und möglichen Angreifern. Ein internes Schreibwerkzeug hat andere Risiken als ein Agent mit Zugriff auf E-Mail und Zahlungen. Auch unbeabsichtigter Missbrauch und schädliche Wirkung auf betroffene Personen gehören in den Umfang.
- Prompt Injection, Jailbreaks und versteckte Anweisungen
- Datenabfluss, Rechteausweitung und unerlaubte Tool-Aktionen
- Manipulierte Quellen, Modelle oder Abhängigkeiten
- Unsichere Ausgabeweitergabe an Code, Browser oder Fachsysteme
- Umgehung von Guardrails, Limits, Freigaben und Monitoring
Wie läuft ein Red-Team-Test ab?
Vor dem Angriff werden Ziele, Systemgrenzen und Erfolgskriterien aus dem Threat Model abgeleitet. Das Red Team arbeitet möglichst unabhängig von der Implementierung, während ein Blue Team Betrieb und Schutz kontrolliert. Gefährliche Aktionen werden in einer isolierten oder simulierten Umgebung getestet.
- Schritt 1
Bedrohungen modellieren
Wertvolle Daten, mögliche Angreifer, Wirkung und Vertrauensgrenzen bestimmen.
- Schritt 2
Testregeln festlegen
Erlaubte Systeme, Zeitfenster, Daten, Abbruchkriterien und Kontakte dokumentieren.
- Schritt 3
Angriffe durchführen
Bekannte Techniken und kreative Varianten über den gesamten Ablauf kombinieren.
- Schritt 4
Wirkung belegen
Reproduzierbaren Pfad, Voraussetzungen und tatsächliche Folgen festhalten.
- Schritt 5
Nachtesten
Korrekturen und verwandte Umgehungen gezielt erneut prüfen.
Wie bleibt der Test selbst sicher?
Ein Red Team darf keine echten Kundendaten verlieren oder reale Zahlungen auslösen. Produktionsnahe Systeme sind nützlich, benötigen aber technische Begrenzungen, künstliche Konten, sichere Beweisablage und einen sofort erreichbaren Incident-Kontakt.
- Schriftliche Autorisierung und klarer Testumfang
- Isolierte Daten, Testkonten und begrenzte Werkzeuge
- Stop-Möglichkeit bei unerwarteter Wirkung
- Geschützter Umgang mit Schwachstellen und Beweismaterial
- Koordinierte Meldung an interne Teams und betroffene Anbieter
Wie ergänzt Red Teaming andere Prüfungen?
Red Teaming ist kein Ersatz für funktionale Tests, Evals, Code Review oder klassische Penetrationstests. Es findet neue Angriffsideen und systemische Kombinationen. Reproduzierbare Funde sollten anschliessend automatisiert oder als feste Szenarien geprüft werden.
| Prüfmethode | Leitfrage | Vorgehen und Ergebnis | Sinnvoller Zeitpunkt |
|---|---|---|---|
| Eval | Erfüllt die Lösung bekannte Qualitäts- und Sicherheitsanforderungen wiederholbar? | Feste Testfälle und Metriken liefern vergleichbare Ergebnisse und Release-Gates. | Während Entwicklung, vor jedem Release und nach Modell-, Prompt- oder Datenänderungen. |
| Penetrationstest | Gibt es klassische technische Schwachstellen in Anwendung, API, Cloud oder Identität? | Gezielte technische Angriffe liefern reproduzierbare Schwachstellen und Abhilfen. | Vor Produktion und nach wesentlichen Architektur- oder Sicherheitsänderungen. |
| Audit | Sind Nachweise, Prozesse und zugesagte Kontrollen vorhanden und wirksam umgesetzt? | Dokumente, Konfigurationen, Stichproben und Verantwortlichkeiten werden bewertet. | Bei Freigabe, regelmässiger Governance-Prüfung oder Anbieterbewertung. |
| AI Red Teaming | Welche unerwarteten Angriffsketten und Umgehungen funktionieren im realen System? | Adversariale Szenarien kombinieren Modell, Daten, Tools und Menschen; Funde werden zu Regressionstests. | Vor risikoreichen Releases und nach neuen Fähigkeiten, Datenquellen oder Angriffsmustern. |
| Monitoring | Treten bekannte oder ähnliche Muster im laufenden Betrieb auf? | Signale, Alarme und Incident-Abläufe erkennen Abweichungen und reale Wirkung. | Kontinuierlich nach Freigabe. |
Beispiel: Red Teaming eines Einkaufsagenten
Das Team erstellt Testlieferanten, E-Mails und Dokumente mit direkten, versteckten und mehrsprachigen Angriffen. Ziel ist, interne Angebote auszulesen oder eine Bankänderung ohne zweite Freigabe vorzubereiten. Ein Fund zeigt, dass ein Tool-Ergebnis als vertrauenswürdige Anweisung behandelt wird. Die Schnittstelle wird getrennt, Rechte werden reduziert und das Szenario in die Release-Evals aufgenommen.
Was Sie mitnehmen sollten
Red-teamen Sie den realen Anwendungsfall und seine Folgen, nicht nur einen Chat. Verwandeln Sie jeden belastbaren Fund in eine behobene Kontrolle, einen Regressionstest und ein besseres Monitoring-Signal.
Quellen und Vertiefung
Diese Primärquellen vertiefen Definitionen, technische Grundlagen oder verantwortlichen Einsatz.
Inhaltlich geprüft