Von einer festen Testliste zu einer adaptiven Suche
CART – die Abkürzung steht für Closed-Loop Adaptive Red Teaming – ist ein Evaluierungsrahmen, der Sicherheitstests an die Ergebnisse während einer Prüfung anpassen soll. Die zentrale Idee: Ein Befund wird nicht nur am Ende einer Testkampagne festgehalten, sondern kann auch beeinflussen, welcher Versuch als Nächstes folgt. Die Arbeit ist als Preprint erschienen. Sie sollte daher nicht mit einer unabhängigen Validierung oder einer Sicherheitsgarantie gleichgesetzt werden.
CART soll ein konkretes Problem angehen. Eine feste Sammlung von Prompts kann dazu dienen, bekannte Risiken zu prüfen und wiederholbare Vergleiche zu ermöglichen. Sie ändert sich jedoch nicht unbedingt, wenn ein Test eine unerwartete Schwachstelle aufdeckt. Laut der Zusammenfassung beginnt CART mit einer breiten Abdeckung von Risiken, untersucht anschließend neu auftretende Schwächen und versucht, zu vermeiden, dass neue Tests lediglich Varianten desselben Angriffs sind.
Das bedeutet nicht, dass statische Tests ihren Nutzen verlieren. Eine feste Testsuite kann einen gemeinsamen Bezugspunkt liefern; der adaptive Ansatz ergänzt sie um eine Suche, die sich an den bisherigen Ergebnissen orientiert. Entscheidend ist, ob diese Anpassung relevante Fehler aufspürt, die bei einer Wiederholung der ursprünglichen Fälle unentdeckt geblieben wären – und unter welchen Bedingungen. Die Zusammenfassung berichtet, dass CART bei allen Targets, für die eine Baseline verfügbar war, mehr Fehler und ein höheres durchschnittliches Risiko als die statische Wiederholung der Ausgangstests entdeckt. Das hier zusammengefasste Material enthält jedoch keine Zahlen, anhand derer sich die Größe dieses Unterschieds bestimmen ließe.
Der Vergleich bezieht sich somit darauf, was zwei Teststrategien in den durchgeführten Evaluierungen aufdecken. Daraus allein lässt sich weder schließen, dass die untersuchten Systeme im Alltag häufiger versagen, noch dass CART sämtliche denkbaren Risiken abgedeckt hat.
Was die beiden Ansätze unterscheidet
Der methodische Unterschied besteht darin, ob der nächste Testfall angepasst wird. Die Tabelle bedeutet nicht, dass ein Ansatz den anderen in allen Anwendungsfällen ersetzen sollte.
| Ansatz | Vorgehen | Was sich damit beobachten lässt | Einschränkung |
|---|---|---|---|
| Statische Wiederholung | Führt eine anfängliche Testsammlung erneut aus. | Ergebnisse zu bekannten Fällen und eine wiederholbare Referenz. | Neue Schwächen, die während der Kampagne zutage treten, werden nicht unbedingt untersucht. |
| CART | Nutzt Evaluierungsergebnisse, um spätere Tests zu lenken, und versucht zugleich, die Suche breit und vielfältig zu halten. | Ob die Anpassung Fehler entdeckt, die bei einer Wiederholung der Ausgangstests nicht auftreten. | Die Ergebnisse hängen von den Tests, den Rollen und den untersuchten Targets ab. |
Drei getrennte Funktionen im Evaluierungszyklus
Das Framework unterscheidet drei Rollen. Der Challenger schlägt Tests vor; das Target ist das Modell oder der Agent, an den diese Tests gerichtet sind; und der Judge bewertet die Ergebnisse. Durch diese Trennung lassen sich die einzelnen Funktionen unabhängig voneinander untersuchen. CART wird dadurch nicht als einzelnes Modell beschrieben, das zugleich entscheidet, antwortet und überprüft. Als Target kommt ein textbasiertes Modell oder ein Agent mit Tools infrage. Die verfügbare Zusammenfassung nennt allerdings weder die konkreten Modelle noch die verwendeten Tools.
In einem adaptiven Zyklus können die Antworten des Targets Hinweise darauf geben, welche Schwachstelle als Nächstes untersucht werden sollte. Der Challenger erstellt daraufhin neue Tests, und der Judge analysiert die Antworten. Zugleich werden die Belege und die Herkunft der Befunde festgehalten. Die Zusammenfassung hebt diese Dokumentation ausdrücklich hervor, erläutert im verfügbaren Material aber weder die einzelnen erfassten Felder noch das verwendete Format.
Eine Trennung der Rollen beseitigt nicht das Fehlerrisiko. Ein Judge kann eine Antwort falsch einordnen, und die Wahl von Challenger und Judge kann beeinflussen, welche Belege sichtbar werden. Die CART-Zusammenfassung weist selbst darauf hin, dass die Kombination aus Challenger und Judge die entdeckten Belege verändert. Die Zahl der gemeldeten Fehler sollte deshalb nicht losgelöst von den Entscheidungen betrachtet werden, mit denen sie erzeugt und bewertet wurden.
Der von CART beschriebene Evaluierungszyklus
- 01Mit Tests beginnen, die ein breites Spektrum an Risiken abdecken.
- 02Einen Test an das Target senden, bei dem es sich um ein Textmodell oder um einen Agenten mit Tools innerhalb festgelegter Grenzen handeln kann.
- 03Die Antwort durch den Judge bewerten lassen und die zugehörigen Belege sowie die Herkunft des Befunds festhalten.
- 04Die Ergebnisse nutzen, um weitere Tests zu steuern und die Untersuchung auszuweiten, ohne denselben Fehler lediglich zu wiederholen.
- 05Vor der Interpretation des Ergebnisses prüfen, welche Kombination aus Challenger und Judge die Belege hervorgebracht hat.
Welche Ergebnisse das Preprint berichtet
Die Zusammenfassung ordnet die Experimente drei Evaluierungsfamilien zu: Frontier, JAH und Agentic. Sie berichtet, dass CART bei jedem Target mit verfügbarer Baseline mehr Fehler und ein höheres durchschnittliches Risiko als die statische Wiederholung der Ausgangstests gefunden hat. Außerdem hätten sich die Verbesserungen auf Tests von Agenten erstreckt, bei denen Tools zum Einsatz kamen. Den beschriebenen Experimenten zufolge deutet das darauf hin, dass eine kontextbezogene Anpassung Schwächen aufdecken kann, die durch die direkte Wiederholung von Prompts nicht erprobt werden.
Diese Ergebnisse sind jedoch mit wichtigen Einschränkungen zu lesen. Die hier vorliegende Zusammenfassung nennt weder die Zahl der untersuchten Targets noch die Modellnamen, Erkennungsraten, numerischen Unterschiede zwischen den Verfahren oder die Einzelheiten der jeweiligen Evaluierungsfamilie. Auch das Wort „mehr“ reicht nicht aus, um die statistische oder praktische Bedeutung des Unterschieds einzuschätzen. Dafür müssen die vollständigen Ergebnisse und die jeweiligen Bedingungen herangezogen werden; aus der Zusammenfassung allein lassen sich diese Angaben nicht ableiten.
Die Autoren warnen zudem, dass die Ergebnisse beschreiben, was die Teststrategien aufdecken – nicht, wie häufig Fehler in realen Deployments auftreten. Red-Teaming-Kampagnen wählen Eingaben, Bedingungen und Bewertungskriterien aus. Sie entsprechen nicht der Beobachtung sämtlicher Interaktionen, die ein System im Produktivbetrieb haben könnte. CART kann somit Belege zur Leistung einer Suchstrategie liefern, aber keine unmittelbare Schätzung der Zahl realer Vorfälle.
Was sich folgern lässt – und was offenbleibt
| Frage | Angabe in der Zusammenfassung | Was sich daraus allein nicht ableiten lässt |
|---|---|---|
| Welche Evaluierungsfamilien werden beschrieben? | Frontier, JAH und Agentic. | Die vollständigen Details der einzelnen Protokolle. |
| Wie schneidet CART gegenüber der Baseline ab? | Bei allen Targets mit verfügbarer Baseline werden mehr Fehler und ein höheres durchschnittliches Risiko berichtet. | Die numerische Größe des Unterschieds und seine praktische Bedeutung. |
| Wurden Agenten getestet? | Die Zusammenfassung berichtet Ergebnisse zu Tests von Agenten, bei denen Tools zum Einsatz kamen. | Welche Agenten und Tools mit welchen konkreten Grenzen verwendet wurden. |
| Wie häufig versagen Systeme im Produktivbetrieb? | Die Arbeit stellt klar, dass sie misst, was die Teststrategien aufdecken. | Die Häufigkeit von Fehlern in realen Deployments. |
Nachvollziehbarkeit, Vielfalt und offene Fragen
Die Herkunft und die Belege eines Befunds zu dokumentieren ist wichtig, weil sich dadurch nachvollziehen lässt, wie er zustande kam und welche Beobachtung seine Einstufung stützt. Ohne solche Informationen kann eine Ergebnisliste schwer zu interpretieren oder zu reproduzieren sein. CART gibt an, Belege und Herkunft festzuhalten. Die Zusammenfassung beschreibt jedoch weder das Datenschema und die verwendeten Kennungen noch die Verfügbarkeit der Aufzeichnungen oder die Möglichkeit, dass eine unabhängige Person jeden Test nachvollzieht.
Auch Vielfalt braucht eine messbare Definition. Die Aussage, dass Tests vielfältig sein sollen, belegt noch nicht, dass sich die Fälle in relevanter Hinsicht unterscheiden: Unterschiedliche Formulierungen können dieselbe Schwachstelle betreffen, während ähnlich wirkende Fälle verschiedene Mechanismen untersuchen können. Die Zusammenfassung sagt, CART halte neue Tests vielfältig, nennt hier aber weder die verwendete Metrik noch Schwellenwerte oder Prüfverfahren. Auf Grundlage dieser Beschreibung allein lässt sich daher nicht bestätigen, wie Duplikate erkannt oder oberflächliche Varianten vermieden werden.
Auch die Reproduzierbarkeit ist nicht geklärt. Für eine Wiederholung der Evaluierung sind üblicherweise Angaben wie Modellversionen, Anweisungen, freigeschaltete Tools, Suchbudget, Evaluierungs-Harness und Bewertungsregeln wichtig. Das bereitgestellte Material bestätigt nicht, welche Bestandteile von CART veröffentlicht wurden und ob Code, generierte Tests und Befunde für eine externe Replikation zur Verfügung stehen. Ohne Überprüfung sollte diese Verfügbarkeit nicht als Tatsache dargestellt werden.
Bei realen Deployments hängt die Interpretation außerdem vom Produkt und seiner Konfiguration ab. Ein Ergebnis aus einem experimentellen Endpunkt beschreibt nicht zwangsläufig das Verhalten einer Produktionsoberfläche oder -konfiguration. Die Evaluierung sollte offenlegen, was mit welchen Einschränkungen getestet wurde, und zusätzliche Tests des tatsächlich bereitgestellten Systems in Betracht ziehen. Das ändert nichts an den von CART berichteten Ergebnissen, grenzt aber ein, welche Entscheidungen sich darauf stützen lassen.
Ein Beitrag zur Evaluierung – kein Sicherheitszertifikat
Der von CART vorgeschlagene Beitrag ist methodischer Art: Ergebnisse einer Testkampagne sollen Informationen für die nächste Testrunde liefern, statt sich ausschließlich auf eine unveränderte Liste zu verlassen. Das Preprint berichtet in drei Evaluierungsfamilien von Vorteilen gegenüber einer statischen Baseline, darunter Tests mit Agenten und Tools. Diese Evidenz macht den Ansatz interessant. Sie reicht jedoch nicht aus, um zu behaupten, CART erkenne alle Risiken, funktioniere bei jedem Modell gleich oder erhöhe von selbst die Sicherheit eines Produkts.
Um zu entscheiden, wie viel Vertrauen der Vorschlag verdient, sind praktische Fragen entscheidend: Welche Targets wurden verglichen? Unter welchen Bedingungen und mit welchen Budgets? Wie wurde die Vielfalt überprüft? Wie wurden Fehler des Judges kontrolliert? Können Dritte die Ergebnisse reproduzieren? Außerdem sollte geprüft werden, ob die Tests dem Modell und dem Endpunkt entsprechen, die tatsächlich eingesetzt werden. Solange es auf diese Fragen keine überprüfbaren Antworten gibt, sollte CART als vielversprechender Rahmen für adaptive Suche verstanden werden, dessen Ergebnisse von den Autoren berichtet werden und dessen Grenzen sie selbst benennen – nicht als Sicherheitsgarantie.
Kriterien zur Einordnung einer adaptiven Evaluierung
- 01Feststellen, welche Modelle, Agenten, Tools und Konfigurationen getestet wurden.
- 02Die adaptive Strategie mit einer klar definierten Baseline vergleichen und nicht nur die Richtung, sondern auch die Größe der Ergebnisse prüfen.
- 03Nachvollziehen, wie Vielfalt und Deduplizierung der Tests gemessen wurden.
- 04Die menschlichen oder unabhängigen Kontrollen für automatische Bewertungen überprüfen.
- 05Klären, welche Belege, welcher Code und welche Aufzeichnungen für eine Replikation verfügbar sind.
- 06Ergebnisse einer Testkampagne nicht ohne konkrete Belege auf die Häufigkeit von Fehlern im Produktivbetrieb übertragen.
Offene Fragen
- Das bereitgestellte Material nennt weder die Identitäten und Versionen der getesteten Modelle und Agenten noch die Grenzen der verwendeten Tools im Detail.
- Detaillierte Zahlen, Stichprobengrößen oder Unsicherheitsschätzungen zur Quantifizierung des Vorteils gegenüber der Baseline fehlen hier.
- Es wird nicht angegeben, wie die Vielfalt der Tests gemessen oder wie mit Angriffen umgegangen wird, die dieselbe Schwachstelle untersuchen.
- Es ist nicht bestätigt, welche unabhängigen oder menschlichen Verfahren falsch positive Ergebnisse und Verzerrungen des Judges erkennen sollen.
- Es ist nicht bestätigt, ob Code, generierte Tests und Aufzeichnungen für eine externe Replikation verfügbar sind.
- Die Ergebnisse des Preprints belegen nicht, wie häufig Fehler in Systemen unter realen Einsatzbedingungen auftreten.
Weiter entdecken
Verwendete Quellen
Korrekturen und Transparenz
Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.
Korrektur vorschlagen