SecRespond zeigt: 23 Frontier-AI-Modelle übersehen unauffällige Intrusionen
SecRespond schaffte es mit einem ernüchternden Ergebnis in Google News: Keines von 23 Frontier-Modellen schloss auf einem der getesteten kompromittierten Hosts sowohl Erkennung als auch Bereinigung vollständig ab. Die Agenten gingen deutlich besser mit sichtbaren Warnmeldungen als mit unauffälligen Spuren um – und offenbarten damit eine Lücke zwischen KI-gestützter Triage und autonomer Incident Response.
Forscher der Alibaba Group reichten die SecRespond-Studie am 29. Juli 2026 ein. Sie testeten Modelle aus mehreren großen Modellfamilien über OpenCode, ein Agent-Framework, das Modellen die Prüfung von Dateien und die Nutzung von Kommandozeilenwerkzeugen ermöglicht.
Der Test beginnt, nachdem ein Angreifer bereits erfolgreich war. Dieses Detail schafft den zentralen Konflikt der Studie. KI-Agenten können einer Warnmeldung nachgehen, doch ein Security Operations Center benötigt Ermittler, die auch Bedrohungen finden, auf die niemand hingewiesen hat.
SecRespond stellt daher ein gängiges Automatisierungsversprechen infrage. Ein Modell, das Warnmeldungen zusammenfasst, kann die Arbeitslast von Analysten senken – doch dadurch wird es noch nicht zu einem eigenständigen Incident Responder. Der Benchmark fand den Unterschied in Festplattenartefakten, Persistenzmechanismen, unvollständigen Bereinigungsschritten und nicht verifizierten Maßnahmenplänen.
Was der SecRespond-Benchmark tatsächlich verändert hat
SecRespond verlagert das Evaluierungsziel von der Interpretation von Warnmeldungen zur Untersuchung einer bereits kompromittierten Maschine.
Viele Cybersicherheitstests setzen vor einer Kompromittierung an. Sie fordern ein Modell auf, eine Schwachstelle zu identifizieren, eine Capture-the-Flag-Aufgabe zu lösen, Malware zu klassifizieren oder anhand ausgewählter Sicherheitslogs zu argumentieren. Diese Aufgaben messen nützliche Fähigkeiten, verringern aber die Unsicherheit, die einen realen Sicherheitsvorfall auszeichnet.
SecRespond setzt später an. Jeder Agent erhält einen eingefrorenen forensischen Festplatten-Snapshot eines kompromittierten Cloud-Hosts. Zusätzlich erhält er synthetische Ausgaben, die Warnmeldungen, Schwachstellenscans und Prüfungen von Sicherheitsbaselines eines Host-Protection-Produkts ähneln.
Ein forensischer Festplatten-Snapshot ist eine erhaltene Kopie der Dateien und Artefakte eines Systems zu einem bestimmten Zeitpunkt. Er kann Belege enthalten, die in Warnmeldungen nie erwähnt wurden, darunter veränderte Startdateien, Backdoor-Konten, gelöschte Logs, geplante Aufgaben oder bösartige Binärdateien.
Der Agent muss dieses Material untersuchen und rekonstruieren, was geschehen ist. Anschließend erstellt er Berichte zu Intrusionen, Schwachstellen, Baseline-Risiken und Gegenmaßnahmen. Die Aufgabe verlangt zudem eine Fortschrittsdatei, sodass ein Nachweis der Untersuchung entsteht, statt lediglich eine ausgefeilte abschließende Antwort zu akzeptieren.
Der Benchmark umfasst 10 Cyber-Ranges, also isolierte Umgebungen, die zum Nachstellen von Sicherheitsvorfällen aufgebaut wurden. Diese Ranges decken vier Arten initialer Einstiegspunkte, 21 Techniken aus dem MITRE ATT&CK-Katalog und fünf Betriebssysteme ab.
Die Forscher übersetzten diese Umgebungen in 52 Fähigkeitskriterien und 280 detaillierte Prüfpunkte. Die Prüfpunkte fragen, ob ein Agent konkrete Belege gefunden, sie korrekt zugeordnet, geeignete Maßnahmen empfohlen und notwendige Verifikationen abgedeckt hat.
Erkennung und Planung der Bereinigung werden getrennt bewertet. Für die Erkennung sind pro anwendbarem Prüfpunkt maximal drei Punkte möglich. Die Planung erhält maximal zwei Punkte, während Prüfpunkte, die für eine Dimension nicht gelten, aus der jeweiligen Gesamtsumme ausgeschlossen werden.
Diese Trennung ist wichtig, denn das Finden einer bösartigen Datei beantwortet nicht, was Einsatzteams als Nächstes tun sollten. Eine sichere Reaktion kann erfordern, einen Host zu isolieren, Beweise zu sichern, Prozesse zu beenden, Persistenz zu entfernen, Zugangsdaten zu rotieren, Infrastruktur zu blockieren, Dienste wiederherzustellen und die Wiederherstellung zu verifizieren.
Das öffentliche SecRespond-Dataset enthält Aufgaben-Prompts, Evaluierungsmaterialien, Checklisten, synthetische Sicherheitsausgaben und forensische Archive. Seine Veröffentlichung macht die zentrale Behauptung für Teams außerhalb des ursprünglichen Autorenteams überprüfbar.
SecRespond zieht zudem eine strengere Grenze für KI-gestützte Incident Response. Ein Agent erhält nicht deshalb die volle Punktzahl, weil er etwas vermutlich geprüft hat. Sein Bericht muss den Befund benennen und Belege anführen, die die relevante Checkliste erfüllen.
Diese Regel macht vage Sicherheitsformulierungen messbar. „Verdächtige Aktivitäten untersuchen“ ist nicht gleichbedeutend mit der Identifizierung eines konkreten Prozesses, einer Datei, eines Kontos, eines Endpunkts oder eines Persistenzpfads. „Den Server patchen“ ist nicht gleichbedeutend mit einem vollständigen, abgestimmten und verifizierten Wiederherstellungsplan.
Die Berichterstattung von Google News konzentrierte sich auf das zentrale Scheitern über 23 Modelle hinweg. Die tiefergehende Veränderung ist methodischer Natur. SecRespond fragt, ob ein Agent Spuren verfolgen kann, die ihm nie vorgelegt wurden, und diese Entdeckungen anschließend mit einem belastbaren Bereinigungsprozess verbindet.
Warum die Aufmerksamkeit von Google News für Käufer von KI-Sicherheitslösungen wichtig ist
Der Benchmark setzt Anbieter und Sicherheitsverantwortliche unter Druck, zwischen Unterstützung bei Warnmeldungen und autonomer Incident Response zu unterscheiden.
KI unterstützt Security Operations Center bereits beim Zusammenfassen von Warnmeldungen, Anreichern von Indikatoren, Durchsuchen von Dokumentation, Erstellen von Abfragen und Vorbereiten von Fallnotizen. Diese Workflows bleiben wertvoll, da Analysten häufig mit fragmentierten Belegen und wiederkehrender administrativer Arbeit konfrontiert sind.
SecRespond misst jedoch ein höheres Maß an Eigenständigkeit. Ein autonomer Responder muss entscheiden, wo er weiter untersucht, fehlende Belege erkennen, konkurrierende Erklärungen prüfen und fortfahren, nachdem die offensichtlichste Warnmeldung abgearbeitet wurde.
Das zentrale Ergebnis des Benchmarks zeigt, warum diese Unterscheidung wichtig ist. Über alle 23 bewerteten Modelle hinweg erreichte kein Agent selbst in einer einzigen Cyber-Range eine vollständige Erkennung und Bereinigung.
Das im berichteten Experiment insgesamt beste Modell war Claude Opus 4.7. Es erreichte einen durchschnittlichen Checkpoint-Score auf Range-Ebene von 79,0 Prozent bei der Erkennung und 65,7 Prozent bei der Planung.
Die Studie berichtet für das führende Modell außerdem einen Durchschnitt von 72,4 Prozent bei der Kombination dieser Dimensionen. Diese Leistung ließ dennoch bösartige Artefakte unberührt und die Bereinigung unvollständig – insbesondere in Ranges mit längeren und umfassenderen Angriffsketten.
Weitere führende Ergebnisse erzielten Claude Opus 4.6 mit 78,2 Prozent bei der Erkennung und 58,0 Prozent bei der Planung. GLM-5.1 erreichte 76,3 Prozent und 59,2 Prozent, während Qwen3.7 Plus auf 75,6 Prozent und 58,8 Prozent kam.
Diese Werte sollten nicht als allgemeines Ranking der zugrunde liegenden Modelle verstanden werden. Sie beschreiben ein Agent-Framework, eine Benchmark-Version, ein Aufgabendesign und einen spezifischen Evaluierungsprozess.
Stattdessen zeigen die Ergebnisse ein gemeinsames Fehlermuster. Modelle fanden Belege, die mit bestehenden Warnmeldungen verbunden waren, zuverlässiger als Belege, die eine nicht angeleitete Suche auf der Festplatte erforderten.
Dieses Muster setzt Sicherheitsanbieter unter Druck, die breite Bezeichnungen wie „AI analyst“ oder „autonomous SOC“ verwenden. Käufer müssen fragen, welche Teile des Response-Lebenszyklus das System tatsächlich ohne einen von Menschen erstellten Hinweis bewältigt.
Ein Produkt kann eine Endpoint-Warnmeldung präzise zusammenfassen und dennoch einen zweiten Persistenzmechanismus übersehen. Es kann empfehlen, eine bösartige Binärdatei zu löschen, aber versäumen, ihren Prozess zu beenden, ihren Loader zu entfernen, kompromittierte Zugangsdaten zu rotieren oder die Wiederherstellung des Dienstes zu verifizieren.
Jeder ausgelassene Schritt verändert das operative Ergebnis. Ein Angreifer kann über ein unberührtes Konto, eine geplante Aufgabe, eine Webshell, einen Dienst, einen Registry-Eintrag oder einen Shell-Hook zurückkehren. Eine technisch korrekte erste Maßnahme kann daher ein falsches Gefühl der Eindämmung erzeugen.
Sicherheitsverantwortliche müssen außerdem Untersuchungsqualität von Berichtsqualität trennen. Modelle liefern oft flüssige Erklärungen, doch SecRespond bewertet, ob diese Erklärungen die erforderlichen Belege und Details zur Bereinigung enthalten.
Das ist ein bekanntes Problem bei wissensintensiver Arbeit. Eine überzeugende Darstellung kann unvollständige Recherche verschleiern. Teams, die eine durchsuchbare Wissensdatenbank aufbauen, stehen vor einer ähnlichen Anforderung: Schlussfolgerungen müssen auf das Quellmaterial zurückführbar bleiben.
Der Benchmark macht diese Nachvollziehbarkeit für Incident Response konkret. Ein Agent muss zeigen, welches Artefakt jede Schlussfolgerung stützt und welche Maßnahme auf jede identifizierte Bedingung reagiert.
Die Sichtbarkeit in Google News kann diese Unterscheidung über Benchmark-Forscher hinaus tragen. Beschaffungsteams, CISOs, Managed-Security-Anbieter und interne Audit-Gruppen haben nun ein öffentliches Beispiel dafür, warum „bearbeitet Warnmeldungen“ und „bearbeitet Sicherheitsvorfälle“ keine gleichwertigen Aussagen sind.
Der eigentliche blinde Fleck ist die nicht angeleitete Untersuchung
Das schwächste Verhalten der Modelle zeigt sich, wenn ein Vorfall keine offensichtliche Warnmeldung hinterlässt, die auf das nächste Artefakt weist.
SecRespond bündelt die Leistung in fünf Fähigkeitsbereiche. Diese umfassen Intrusionsentitäten, Persistenzmechanismen, Baseline-Risiken, Schwachstellenrisiken sowie die Gesamtqualität von Untersuchung und Reaktion.
Eine Intrusionsentität ist ein konkretes bösartiges Objekt, etwa ein Prozess, eine Datei, ein Netzwerkendpunkt oder ein manipuliertes Artefakt. In dieser Kategorie erzielten die Modelle die besten Ergebnisse, weil diese Objekte häufig mit sichtbaren Sicherheitssignalen übereinstimmten.
Über alle Modelle hinweg erreichte die durchschnittliche Erkennung bei Intrusionsentitäten 75,4 Prozent. Mehrere führende Systeme schnitten deutlich besser ab, darunter Qwen3.7 Plus mit 88,4 Prozent und Claude Opus 4.6 mit 86,0 Prozent.
Bei Persistenzmechanismen ergab sich ein anderes Bild. Persistenz bezeichnet Änderungen, die Angreifern den Zugriff über einen Neustart oder eine erste Bereinigung hinaus ermöglichen. Beispiele sind geplante Aufgaben, Dienste, Shell-Startup-Hooks, Webshells, Konto-Backdoors und Windows-Management-Instrumentation-Abonnements.
Die durchschnittliche Erkennung fiel bei Persistenz auf 58,8 Prozent. Dieser Rückgang ist bedeutsam, denn genau diese Persistenz müssen Einsatzteams finden, bevor sie einen Host für bereinigt erklären können.
Der Benchmark zeigt nicht, dass Modelle keinerlei forensische Schlussfolgerungen ziehen können. Sie können eine Warnmeldung mit einem relevanten Prozess oder einer Datei verbinden und die unmittelbare Bedrohung oft korrekt beschreiben. Das Scheitern beginnt, wenn die Untersuchung über diesen Ausgangspunkt hinausgehen muss.
Betrachten wir einen kompromittierten Webserver. Eine Warnmeldung könnte einen bösartigen Prozess oder eine ausgehende Verbindung identifizieren. Die Verfolgung dieses Signals kann eine ausführbare Datei aufdecken, doch eine vollständige Untersuchung muss fragen, wie der Angreifer eingedrungen ist, welche Zugangsdaten offengelegt wurden und was eine Beendigung überdauert.
Der Responder muss möglicherweise außerdem Startskripte, Dienstdefinitionen, Cron-Einträge, Benutzerkonten, Befehlshistorien, Anwendungsverzeichnisse und veränderte Logs untersuchen. Keine einzelne Warnmeldung identifiziert diese Speicherorte zwingend.
Dadurch entsteht ein Suchproblem mit unsicheren Grenzen. Der Agent muss entscheiden, welche Hypothesen geprüft werden sollten und wie lange die Untersuchung fortgesetzt werden muss. Er muss erkennen, dass das Fehlen eines Artefakts andere Persistenzwege nicht ausschließt.
Aktuelle Sprachmodell-Agenten optimieren häufig auf die Belege, die bereits im Kontext vorhanden sind. Warnmeldungen schaffen stark hervorgehobene Anker, sodass der Agent sein Budget damit verbringen kann, diese Anker zu erklären, statt nach nicht erwähnten Belegen zu suchen.
Längere Angriffsketten verstärken diese Schwäche. Jede zusätzliche Technik führt einen weiteren Zweig, Artefakttyp, Zeitstempel, Account oder Dienst ein, den das Modell korrelieren muss.
Die Studie stellte fest, dass die Leistung abnahm, wenn Angriffe länger und breiter wurden. Dieses Ergebnis passt zur operativen Herausforderung: Incident Response ist keine einzelne Klassifikationsentscheidung, sondern eine Folge miteinander verknüpfter Urteile unter unvollständiger Informationslage.
Ein separater Threat-Hunting-Benchmark aus dem Jahr 2026 berichtete über ein ähnliches Problem. Fünf Frontier-Modelle durchsuchten rohe Windows-Ereignislogs aus 26 Angriffskampagnen, und das beste Modell fand nur einen kleinen Teil der bösartigen Ereignisse.
Die beiden Studien testen unterschiedliche Workflows, weshalb ihre Scores nicht unmittelbar vergleichbar sind. Beide legen jedoch nahe, dass nicht angeleitete Suche weiterhin schwieriger bleibt als Schlussfolgerungen auf Grundlage vorselektierter Belege.
Dies ist die zentrale Umkehrung des Benchmarks. Agenten scheinen dort am leistungsfähigsten, wo herkömmliche Sicherheitswerkzeuge die Unsicherheit bereits reduziert haben. Weniger zuverlässig werden sie dort, wo menschliche Ermittler den größten Mehrwert schaffen, indem sie hinterfragen, was der Alarm nicht offengelegt hat.
Ein Sicherheitsteam kann KI innerhalb dieser Grenze weiterhin produktiv einsetzen. Das Modell kann Belege zusammenfassen, Hypothesen vorschlagen, Abfragen entwerfen, Artefakte vergleichen und einen Ermittlungszeitplan pflegen.
Der unsichere Sprung besteht darin, diese Fähigkeiten als Beleg dafür zu behandeln, dass das Modell den gesamten Vorfall untersucht hat. SecRespond zeigt, dass eine überzeugend formulierte Antwort mit unentdeckter Persistenz und einer unvollständigen Darstellung der Angreiferaktivität einhergehen kann.
Erkennungswerte verbergen eine größere Lücke bei der Bereinigung
Mehr gefundene Belege führten nicht zu ebenso vollständigen Bereinigungsplänen, wodurch die Behebung zum zweiten großen Versagen des Benchmarks wurde.
Jedes bewertete Modell erzielte bei der Erkennung höhere Werte als bei der Planung. Bei GPT-5.5 betrug die gemeldete Differenz 34,7 Prozentpunkte.
Die Forschenden führen dieses Muster darauf zurück, dass Agenten eine offensichtliche erste Maßnahme anwenden, weitere Schritte jedoch auslassen. Dieses Verhalten ähnelt einer verkürzten Checkliste: Sobald das zentrale schädliche Objekt behandelt wurde, verhält sich das Modell, als sei der Vorfall gelöst.
Die tatsächliche Behebung endet selten mit einer einzigen Löschung oder Konfigurationsänderung. Ein Incident Responder muss Abhängigkeiten, Beweissicherung, Geschäftsauswirkungen, Dienstkontinuität, kompromittierte Zugangsdaten und alternative Zugangswege des Angreifers berücksichtigen.
Der Planungswert von SecRespond bewertet, ob eine Maßnahme korrekt und vollständig ist. Außerdem untersucht er Verifizierung und Nebenwirkungen, wenn der jeweilige Prüfschritt dies erfordert.
Verifizierung ist kein bloßes Ritual. Ein Plan zum Entfernen einer geplanten Aufgabe sollte bestätigen, dass die Aufgabe nicht mehr existiert und ihre Nutzlast nicht über einen anderen Mechanismus gestartet werden kann.
Ein Plan zum Blockieren einer Angreiferadresse sollte gegebenenfalls sowohl eingehenden als auch ausgehenden Datenverkehr berücksichtigen. Er sollte zudem nicht den Eindruck erwecken, dass eine Adresssperre Malware, gestohlene Zugangsdaten oder bereits auf dem Host vorhandene Persistenz entfernt.
Standardisierte Konfigurationsprobleme erwiesen sich als leichter. Claude Opus 4.7 erreichte bei der Planung für grundlegende Risiken 74,8 Prozent und für Schwachstellenrisiken 72,6 Prozent.
Diese Aufgaben lassen sich häufig vertrauten Maßnahmen zuordnen, etwa dem Härten einer Konfiguration oder dem Aktualisieren betroffener Software. Der Agent kann ein erkennbares Behebungsmuster abrufen und auf den Befund anwenden.
Die Qualität bei Untersuchung und Reaktion blieb deutlich schwächer. Die durchschnittliche Planungsleistung in dieser Kategorie erreichte nur 31,8 Prozent.
Diese Kategorie umfasst Arbeit, die statt von einer bekannten Einzelmaßnahme von Synthese abhängt. Dazu gehören die Rekonstruktion der Angriffskette, die Qualität der Belege, ein ehrlicher Umgang mit Unsicherheit, Vollständigkeit, Verifizierung und das Bewusstsein für operative Auswirkungen.
Das stärkste Erkennungsergebnis in dieser Kategorie lag bei 75,5 Prozent. Laut der Arbeit blieben fast alle Modelle bei der Planung unter 50 Prozent.
Diese Ergebnisse untergraben eine einfache Skalierungsstrategie. Ein Modell mit mehr Alarmen zu versorgen, erzeugt nicht automatisch einen vollständigen Reaktionsplan. Mehr sichtbare Befunde können stattdessen zu mehr unverbundenen Empfehlungen führen.
Ein glaubwürdiger Plan braucht eine Reihenfolge. Teams können eine Maschine isolieren, bevor sie sie verändern, flüchtige Belege sichern, bevor sie Prozesse beenden, und Zugangsdaten rotieren, nachdem sie den Umfang der Gefährdung bestimmt haben.
Sie müssen auch Rollback- und Dienstaspekte berücksichtigen. Das Entfernen einer kompromittierten Komponente ohne Verständnis ihrer Abhängigkeiten kann die Produktion unterbrechen oder für die Attribution erforderliche Belege zerstören.
SecRespond bewertet schriftliche Pläne und keine Live-Behebung auf Produktionssystemen. Das begrenzt, was der Benchmark belegen kann, hält aber auch die Sicherheitsfrage sichtbar.
Wenn ein Modell in einer kontrollierten Umgebung keine vollständige und verifizierte Behebung konsistent beschreiben kann, haben Organisationen wenig Grundlage, ihm uneingeschränkte Befugnisse auf einem Live-Host zu gewähren.
Der Benchmark unterstützt daher ein engeres Betriebsmodell. KI kann Maßnahmen vorschlagen, Belege organisieren und auf fehlende Felder hinweisen, während menschliche Responder die Freigabe für Eindämmungs- und Wiederherstellungsschritte behalten.
Diese Anordnung ist keine Absage an SOC-Automatisierung. Sie ist eine Reaktion auf die spezifische Asymmetrie in den Daten. Die Systeme waren besser darin, bekannte Objekte zu identifizieren, als sicherzustellen, dass jede Folge sicher behandelt wurde.
Sicherheitsteams sollten diese Asymmetrie in Zugriffssteuerungen abbilden. Schreibgeschützter forensischer Zugriff birgt ein anderes Risiko als die Berechtigung, Prozesse zu beenden, Dateien zu löschen, Konten zu deaktivieren oder Netzwerkrichtlinien zu ändern.
Ein Agent, der ein verborgenes Artefakt übersieht, erstellt einen unvollständigen Bericht. Ein Agent, der auf Grundlage dieses unvollständigen Berichts handelt, kann die Wiederherstellung stören und zugleich den alternativen Weg des Angreifers offenlassen.
Was die Zahlen nicht beweisen
SecRespond ist ein starkes Indiz für eine gemeinsame Einschränkung, aber kein endgültiges Urteil über jedes Modell oder jede Produktions-SOC-Konfiguration.
Die Arbeit ist ein arXiv-Preprint und kein abgeschlossenes Peer-Review-Ergebnis. Zu den Autoren gehören Forschende von Tongyi Lab und Alibaba Cloud, und der Benchmark bewertet Modelle über ein repräsentatives Harness.
Die Wahl von OpenCode hilft, die Werkzeugnutzung über Systeme hinweg zu standardisieren. Sie bedeutet auch, dass die Ergebnisse eine Kombination aus Modell und Harness messen, nicht eine abstrakte Modellfähigkeit losgelöst von Prompting, Werkzeugen, Kontextmanagement und Ausführungsrichtlinien.
Unterschiedliches Scaffolding kann die Leistung verändern. Ein Incident-Response-Agent könnte eine verpflichtende Ermittlungscheckliste, spezialisierte forensische Dienstprogramme, Retrieval über interne Verfahren, mehrere kooperierende Agenten oder deterministische Validierungsskripte verwenden.
SecRespond bleibt nützlich, weil diese Verbesserungen an denselben Ranges getestet werden können. Die veröffentlichten Zahlen sollten jedoch nicht als dauerhafte Grenzen für jede Modellfamilie behandelt werden.
Die Bewertung verwendet zudem ein LLM-as-a-Judge-Verfahren, bei dem Sprachmodelle generierte Berichte anhand detaillierter Checklisten bewerten. Drei proprietäre Judges wurden unabhängig eingesetzt, um die Abhängigkeit von einem einzelnen Bewerter zu reduzieren.
Diese Judges waren Claude Opus 4.7, Gemini 3.1 Pro und GPT-5.4 Pro. Mehrere Judges reduzieren individuelle Verzerrungen, beseitigen jedoch nicht jedes Kalibrierungsproblem.
Ein Bewerter könnte unvollständige Formulierungen anders interpretieren als ein menschlicher Forensikspezialist. Er könnte auch explizite Berichtssprache belohnen, ohne vollständig zu klären, ob der zugrunde liegende Ermittlungsprozess solide war.
Die Bewertungsanweisungen versuchen, dieses Risiko zu begrenzen. Judges müssen Belege zitieren und dürfen Punkte nur für Inhalte vergeben, die ausdrücklich in den Berichten enthalten sind.
Die 280 Prüfpunkte des Benchmarks sorgen für zusätzliche Struktur. Dennoch kodiert jede Checkliste Entscheidungen darüber, welche Artefakte, Reaktionsschritte und Eigenschaften Gewicht erhalten sollen.
Die 10 Ranges sind vielfältig genug, um wiederkehrendes Verhalten sichtbar zu machen. Sie decken nicht jedes Betriebssystem, jede Cloud-Architektur, Identitätsplattform, Endpoint-Produkt oder jede Angreifertechnik ab.
Auch die Umgebungen sind kontrolliert. Die Forschenden stellten die Hosts für den Benchmark bereit und kompromittierten sie, bevor sie Zugangsdaten und personenbezogene Daten bereinigten.
Dieses Design ermöglicht Reproduzierbarkeit und verhindert die Offenlegung von Produktionsinformationen. Es kann das Rauschen, die unvollständige Telemetrie, organisatorische Einschränkungen und geschäftlichen Abhängigkeiten eines Live-Unternehmensvorfalls jedoch nicht vollständig reproduzieren.
Ein Ergebnis zeigt auch, wie Sicherheitsverhalten die Benchmark-Abdeckung beeinflussen kann. Claude Opus 4.7 verweigerte die npm-worm-Aufgabe, weshalb die Arbeit dieses Modell aus der detaillierten Prüfpunkttabelle der Range ausließ.
Eine Verweigerung kann den operativen Nutzen während einer legitimen defensiven Untersuchung senken. Sie kann auch die Bemühung eines Anbieters widerspiegeln, zu verhindern, dass Dual-Use-Unterstützung in schädliche Anleitungen abgleitet.
SecRespond entscheidet diesen politischen Zielkonflikt nicht. Es zeigt, dass eine sichere Bereitstellung Aufgabenbeschreibungen braucht, die autorisierte forensische Arbeit von offensiven Anweisungen unterscheiden.
Die Benchmark-Autoren erklären, dass die veröffentlichten Belege aus isolierten Umgebungen stammen und keine ausführbaren Exploit-Ketten enthalten. Die öffentlichen Materialien sind für defensive Forschung bestimmt.
Diese Einschränkung ist wichtig bei der Interpretation von Behauptungen über Reaktion in der „realen Welt“. Die Ranges bilden End-to-End-Kompromittierungen über reale Netzwerkprotokolle nach, doch das veröffentlichte Paket enthält bereinigte forensische Belege statt aktiver Angriffswerkzeuge.
Zudem gibt es keine unabhängige Feldstudie, die zeigt, wie sich SecRespond-Werte in eingesparte Analystenzeit, verringerte Schwere von Vorfällen oder schnellere Eindämmung übersetzen. Diese Ergebnisse erfordern Bewertungen innerhalb operativer Teams.
Für Käufer ist daher eine nüchterne Lesart richtig. Der Benchmark stellt unbelegte Behauptungen über autonome Incident Response stark infrage. Er zeigt nicht, dass KI-Unterstützung innerhalb eines von Menschen geführten SOC keinen Wert hat.
Er belegt auch nicht, dass ein namentlich genanntes Modell über künftige Versionen hinweg vorne bleiben wird. Die gemeldete Claude-Serie verbesserte sich über mehrere Releases hinweg, während Fortschritte bei anderen Familien nicht universell waren.
Die aussagekräftige Einheit der Bewertung ist das eingesetzte System. Dazu gehören Modell, Werkzeuge, Prompts, Berechtigungen, Retrieval-Quellen, Review-Gates, Logging und Wiederherstellungsverfahren.
Drei Signale, die nach dem SecRespond-Google-News-Zyklus zu beobachten sind
Der nächste Test besteht darin, ob Anbieter ungesteuerte Entdeckung, Verifizierung der Behebung und reproduzierbare Produktionsevaluierungen verbessern.
Das erste Signal ist die unabhängige Reproduktion. Forschende und Sicherheitsanbieter können das öffentliche Benchmark-Repository mit anderen Harnesses, Prompts, Werkzeugen und Modellversionen ausführen.
Die Reproduktion wird zeigen, ob die Lücke bei stillen Intrusionen Änderungen am Scaffolding übersteht. Wenn spezialisierte forensische Agenten weiterhin nicht alarmierte Persistenz übersehen, wird das zentrale Urteil der Arbeit stärker.
Wenn deterministische Suchverfahren große Verbesserungen erzielen, ändert sich die Lehre leicht. Der Engpass läge dann weniger im Modellwissen und stärker im Ermittlungsdesign, in der Werkzeugweiterleitung und in erzwungener Abdeckung.
Das würde Behauptungen über allgemeine autonome Agenten weiterhin schwächen. Es würde zugleich einen klareren technischen Weg zu sichereren Systemen bieten.
Das zweite Signal ist, ob Anbieter getrennte Ergebnisse für Erkennung und Behebung veröffentlichen. Eine einzelne Zahl zur „Genauigkeit der Incident Response“ kann die von SecRespond aufgedeckte Planungslücke verbergen.
Nützliche Bewertungen sollten angeben, was das System gefunden hat, was es übersehen hat, welche Maßnahme es vorgeschlagen hat und wie es deren Abschluss verifiziert hat. Sie sollten zudem Verweigerungen, Werkzeugfehler und Fälle berichten, die menschliches Eingreifen erfordern.
Achten Sie besonders auf Tests von Persistenzmechanismen. Verbesserungen bei alarmverknüpfter Malware sind wichtig, behandeln aber nicht den zentralen blinden Fleck des Benchmarks.
Achten Sie auch darauf, ob Pläne die Breite der Bereinigung abdecken. Ein stärkerer Agent sollte gegebenenfalls Prozesse, Dateien, Konten, geplante Ausführung, Netzwerkkontrollen, Rotation von Zugangsdaten, Dienstwiederherstellung und Validierung nach der Behebung behandeln.
Das dritte Signal sind Belege aus überwachten SOC-Bereitstellungen. Anbieter müssen zeigen, wie ihre Agenten mit realer Telemetrie, internen Verfahren, Zugriffssteuerungen und Analysten-Freigabegates arbeiten.
Die stärksten operativen Belege werden nicht nur aus einer polierten Fallstudie bestehen. Sie werden Fehlerraten, Eskalationsraten, unbegründete Behauptungen, Korrekturhäufigkeit und den Anteil der Empfehlungen umfassen, die Analysten unverändert genehmigen.
Eine glaubwürdige Bereitstellung sollte einen Audit-Trail bewahren. Prüfer müssen Schlussfolgerungen auf Artefakte zurückführen und feststellen können, welche Suchen der Agent abgeschlossen hat, bevor er stoppte.
Organisationen sollten außerdem Berechtigungsgrenzen testen. Schreibgeschützte Untersuchung, empfohlene Maßnahmen und autonome Ausführung stellen drei unterschiedliche Risikostufen dar.
SecRespond unterstützt die Einführung auf den ersten beiden Stufen, legt der dritten jedoch eine hohe Beweislast auf. Seine Ergebnisse rechtfertigen nicht, einem Modell weitreichende Eindämmungsbefugnisse zu übertragen, das keine umfassende Entdeckung nachgewiesen hat.
Die Google-News-Schlagzeile wird verblassen, doch der Benchmark hinterlässt Sicherheitsteams eine dauerhafte Beschaffungsfrage: Was findet der Agent, wenn kein Alarm ihm sagt, wo er suchen soll?
Bitten Sie Anbieter, diese Frage mit reproduzierbaren Belegen zu beantworten. Fragen Sie anschließend, wie das System jeden Bereinigungsschritt überprüft und Unsicherheit an eine menschliche Einsatzkraft signalisiert.
Die Antworten werden zeigen, ob sich AI-SOC-Produkte zu Ermittlern entwickeln oder weiterhin schnelle Assistenten rund um bestehende Erkennungen bleiben. Vorerst ordnet SecRespond alle 23 getesteten Modelle der Assistentenseite dieser Trennlinie zu.
