SecRespond wykrywa, że 23 wiodące modele AI nie zauważają cichych włamań

SecRespond trafił do Google News z jednoznacznym wynikiem: żaden z 23 wiodących modeli nie ukończył wykrywania i usuwania skutków incydentu na żadnym z testowanych skompromitowanych hostów. Agenci znacznie lepiej radzili sobie z widocznymi alertami niż z cichymi śladami, co ujawnia lukę między wspomaganą przez AI triage a autonomicznym reagowaniem na incydenty.

Badacze z Alibaba Group przesłali artykuł SecRespond 29 lipca 2026 roku. Testowali modele z kilku głównych rodzin za pośrednictwem OpenCode, platformy agentowej umożliwiającej modelom analizowanie plików i korzystanie z narzędzi wiersza poleceń.

Test rozpoczyna się po tym, jak atakujący już odniósł sukces. Ten szczegół tworzy konflikt będący sednem badania. Agenci AI potrafią podążać za alertem, lecz centrum operacji bezpieczeństwa potrzebuje śledczych, którzy znajdują również zagrożenia, których nikt nie oznaczył.

SecRespond podważa zatem powszechną obietnicę automatyzacji. Model podsumowujący alerty może zmniejszyć obciążenie analityków, ale nie czyni go to niezależnym responderem incydentów. Benchmark wykazał tę różnicę w artefaktach dyskowych, mechanizmach utrzymywania dostępu, niekompletnych krokach oczyszczania i niezweryfikowanych planach remediacji.

Co faktycznie zmienił benchmark SecRespond

SecRespond przenosi cel ewaluacji z interpretacji alertów na badanie już skompromitowanej maszyny.

Wiele testów cyberbezpieczeństwa rozpoczyna się przed kompromitacją. Proszą model o wskazanie podatności, rozwiązanie zadania capture-the-flag, klasyfikację malware lub analizę wybranych logów bezpieczeństwa. Zadania te mierzą przydatne zdolności, ale ograniczają niepewność definiującą rzeczywiste naruszenie.

SecRespond zaczyna później. Każdy agent otrzymuje zamrożony obraz dysku do analizy śledczej ze skompromitowanego hosta chmurowego. Otrzymuje także syntetyczne wyniki przypominające alerty, skany podatności i kontrole bazowej konfiguracji bezpieczeństwa z produktu ochrony hostów.

Obraz dysku do analizy śledczej to zachowana kopia plików i artefaktów systemu z określonego momentu. Może zawierać dowody, o których alerty nigdy nie wspomniały, w tym zmodyfikowane pliki startowe, konta z tylną furtką, usunięte logi, zaplanowane zadania lub złośliwe pliki binarne.

Agent musi zbadać ten materiał i zrekonstruować przebieg zdarzeń. Następnie tworzy raporty dotyczące włamań, podatności, zagrożeń związanych z konfiguracją bazową oraz remediacji. Zadanie wymaga również pliku postępu, tworząc zapis dochodzenia zamiast akceptować jedną dopracowaną odpowiedź końcową.

Benchmark obejmuje 10 cyberpoligonów, czyli odizolowanych środowisk stworzonych do odtwarzania incydentów bezpieczeństwa. Poligony te obejmują cztery typy początkowych punktów wejścia, 21 technik z katalogu MITRE ATT&CK oraz pięć systemów operacyjnych.

Badacze przełożyli te środowiska na 52 elementy zdolności i 280 szczegółowych punktów kontrolnych. Punkty kontrolne sprawdzają, czy agent znalazł konkretne dowody, prawidłowo je przypisał, zalecił odpowiednie działanie i uwzględnił niezbędną weryfikację.

Wykrywanie i planowanie remediacji otrzymują odrębne oceny. Wykrywanie ma maksymalnie trzy punkty za każdy mający zastosowanie punkt kontrolny. Planowanie ma maksymalnie dwa, przy czym punkty kontrolne nieodnoszące się do jednego z wymiarów są wyłączane z tej agregacji.

To rozdzielenie ma znaczenie, ponieważ znalezienie złośliwego pliku nie odpowiada na pytanie, co responderzy powinni zrobić dalej. Bezpieczna reakcja może wymagać odizolowania hosta, zabezpieczenia dowodów, zakończenia procesów, usunięcia mechanizmów utrzymywania dostępu, rotacji poświadczeń, blokowania infrastruktury, przywrócenia usług i zweryfikowania odzyskania sprawności.

Publiczny zbiór danych SecRespond zawiera prompty zadań, materiały ewaluacyjne, listy kontrolne, syntetyczne wyniki bezpieczeństwa oraz archiwa śledcze. Jego publikacja sprawia, że centralną tezę mogą przetestować zespoły spoza grona pierwotnych autorów.

SecRespond wyznacza także bardziej rygorystyczną granicę dla reagowania na incydenty z użyciem AI. Agent nie otrzymuje pełnej punktacji dlatego, że prawdopodobnie coś sprawdził. Jego raport musi opisywać ustalenie i przytaczać dowody spełniające odpowiednią listę kontrolną.

Ta zasada przekształca ogólnikowy język bezpieczeństwa w mierzalną skuteczność. „Zbadaj podejrzaną aktywność” nie oznacza zidentyfikowania konkretnego procesu, pliku, konta, punktu końcowego lub ścieżki utrzymywania dostępu. „Załataj serwer” nie oznacza kompletnego, sekwencyjnego i zweryfikowanego planu odzyskiwania.

Relacje Google News skupiły się na nagłośnionej porażce wszystkich 23 modeli. Głębsza zmiana ma charakter metodologiczny. SecRespond pyta, czy agent potrafi podążać tropami, których nigdy mu nie przekazano, a następnie połączyć te odkrycia z możliwym do obrony procesem oczyszczania.

Dlaczego zainteresowanie Google News ma znaczenie dla kupujących rozwiązania AI do bezpieczeństwa

Benchmark wywiera presję na dostawców i liderów bezpieczeństwa, by odróżniali wsparcie przy alertach od autonomicznego reagowania na incydenty.

AI już pomaga centrom operacji bezpieczeństwa podsumowywać alerty, wzbogacać wskaźniki, przeszukiwać dokumentację, tworzyć zapytania i przygotowywać notatki do spraw. Te procesy pozostają wartościowe, ponieważ analitycy często mierzą się z rozproszonymi dowodami i powtarzalną pracą administracyjną.

SecRespond mierzy jednak wyższy poziom niezależności. Autonomiczny responder musi zdecydować, gdzie prowadzić dochodzenie, rozpoznać brakujące dowody, testować konkurencyjne wyjaśnienia i kontynuować pracę po rozwiązaniu najbardziej oczywistego alertu.

Centralny wynik benchmarku pokazuje, dlaczego to rozróżnienie ma znaczenie. Spośród wszystkich 23 ocenianych modeli żaden agent nie osiągnął pełnego wykrywania i planowania remediacji nawet na jednym cyberpoligonie.

Najlepszym ogólnym modelem w opisanym eksperymencie był Claude Opus 4.7. Osiągnął średni wynik 79,0 procent na poziomie punktów kontrolnych dla zakresów w wykrywaniu oraz 65,7 procent w planowaniu.

Artykuł podaje także średnią 72,4 procent po połączeniu tych wymiarów dla najlepszego modelu. Taka skuteczność nadal pozostawiała złośliwe artefakty nietknięte, a remediację niekompletną, zwłaszcza w zakresach z dłuższymi i szerszymi łańcuchami ataku.

Inne czołowe wyniki obejmowały Claude Opus 4.6 z 78,2 procent w wykrywaniu i 58,0 procent w planowaniu. GLM-5.1 osiągnął 76,3 procent i 59,2 procent, a Qwen3.7 Plus — 75,6 procent i 58,8 procent.

Liczby te nie powinny być traktowane jako ogólny ranking bazowych modeli. Opisują jedną platformę agentową, jedną wersję benchmarku, jeden projekt zadania i określony proces ewaluacji.

Wyniki ujawniają natomiast wspólny wzorzec porażki. Modele znajdowały dowody powiązane z istniejącymi alertami bardziej niezawodnie niż dowody wymagające niesugerowanego przeszukania dysku.

Ten wzorzec wywiera presję na dostawców bezpieczeństwa używających szerokich etykiet, takich jak „analityk AI” czy „autonomiczny SOC”. Kupujący muszą pytać, które części cyklu reakcji system faktycznie realizuje bez wskazówki stworzonej przez człowieka.

Produkt może trafnie podsumować alert z punktu końcowego, a jednocześnie przeoczyć drugi mechanizm utrzymywania dostępu. Może zalecić usunięcie złośliwego pliku binarnego, nie kończąc jego procesu, nie usuwając jego loadera, nie rotując ujawnionych poświadczeń ani nie weryfikując odzyskania usług.

Każdy pominięty krok zmienia wynik operacyjny. Atakujący może wrócić przez nietknięte konto, zaplanowane zadanie, webshell, usługę, wpis rejestru lub hook powłoki. Technicznie poprawne pierwsze działanie może zatem stworzyć fałszywe poczucie opanowania incydentu.

Liderzy bezpieczeństwa muszą też oddzielić jakość dochodzenia od jakości raportu. Modele często tworzą płynne wyjaśnienia, lecz SecRespond ocenia, czy te wyjaśnienia zawierają wymagane dowody i szczegóły remediacji.

To znany problem w pracy intensywnie wykorzystującej wiedzę. Pewna siebie narracja może ukrywać niekompletne wyszukiwanie. Zespoły budujące przeszukiwalną bazę wiedzy stają przed podobnym wymogiem: wnioski muszą pozostać możliwe do prześledzenia do materiału źródłowego.

Benchmark konkretyzuje tę identyfikowalność w reagowaniu na incydenty. Agent musi pokazać, który artefakt wspiera każdy wniosek i które działanie odpowiada na każdy zidentyfikowany warunek.

Widoczność w Google News może przenieść to rozróżnienie poza środowisko badaczy benchmarków. Zespoły zakupowe, CISO, dostawcy zarządzanych usług bezpieczeństwa i wewnętrzne grupy audytowe mają teraz publiczny przykład, dlaczego stwierdzenia „obsługuje alerty” i „obsługuje incydenty” nie są równoważne.

Prawdziwym martwym punktem jest nieskierowane dochodzenie

Najsłabsze zachowanie modeli pojawia się, gdy incydent nie pozostawia oczywistego alertu wskazującego następny artefakt.

SecRespond grupuje skuteczność w pięciu obszarach zdolności. Obejmują one elementy włamań, mechanizmy utrzymywania dostępu, ryzyka konfiguracji bazowej, ryzyka podatności oraz ogólną jakość dochodzenia i reakcji.

Element włamania to konkretny złośliwy obiekt, taki jak proces, plik, punkt końcowy sieci lub zmanipulowany artefakt. Modele radziły sobie najlepiej w tej kategorii, ponieważ obiekty te często odpowiadały widocznym sygnałom bezpieczeństwa.

Średnio dla wszystkich modeli wykrywanie elementów włamań osiągnęło 75,4 procent. Kilka czołowych systemów uzyskało znacznie lepsze wyniki, w tym Qwen3.7 Plus z 88,4 procent i Claude Opus 4.6 z 86,0 procent.

Mechanizmy utrzymywania dostępu przyniosły inny rezultat. Utrzymywanie dostępu odnosi się do zmian pozwalających atakującemu zachować dostęp po restarcie lub początkowym oczyszczaniu. Przykłady obejmują zaplanowane zadania, usługi, hooki uruchamiania powłoki, webshelle, tylne furtki w kontach i subskrypcje Windows Management Instrumentation.

Średnia skuteczność wykrywania spadła do 58,8 procent w przypadku utrzymywania dostępu. Spadek ten ma znaczenie, ponieważ właśnie takie mechanizmy responderzy muszą znaleźć, zanim uznają host za czysty.

Benchmark nie pokazuje, że modelom całkowicie brakuje rozumowania śledczego. Potrafią one połączyć alert z odpowiednim procesem lub plikiem i często poprawnie opisać bezpośrednie zagrożenie. Porażka następuje, gdy dochodzenie musi wyjść poza ten punkt startowy.

Rozważmy skompromitowany serwer WWW. Alert może wskazać złośliwy proces lub połączenie wychodzące. Podążanie za tym sygnałem może ujawnić jeden plik wykonywalny, ale kompletne dochodzenie musi zapytać, jak atakujący się dostał, jakie poświadczenia zostały ujawnione i co przetrwa zakończenie procesu.

Responder może także potrzebować zbadać skrypty startowe, definicje usług, wpisy cron, konta użytkowników, historię poleceń, katalogi aplikacji i zmienione logi. Żaden pojedynczy alert nie musi wskazywać tych lokalizacji.

Tworzy to problem wyszukiwania o niepewnych granicach. Agent musi zdecydować, które hipotezy warto testować i jak długo kontynuować. Musi rozpoznać, że brak jednego artefaktu nie eliminuje innych ścieżek utrzymywania dostępu.

Obecni agenci oparci na modelach językowych często optymalizują działania wokół dowodów już obecnych w kontekście. Alerty tworzą kotwice o wysokiej istotności, więc agent może przeznaczyć swój budżet na wyjaśnianie tych kotwic zamiast szukać niewspomnianych dowodów.

Dłuższe łańcuchy ataku wzmacniają tę słabość. Każda dodatkowa technika wprowadza kolejną gałąź, typ artefaktu, znacznik czasu, konto lub usługę, które model musi skorelować.

Artykuł wykazał, że skuteczność spadała wraz z wydłużaniem i rozszerzaniem ataków. Wynik ten odpowiada wyzwaniu operacyjnemu: reagowanie na incydenty nie jest pojedynczą decyzją klasyfikacyjną, lecz sekwencją powiązanych osądów podejmowanych przy niekompletnych informacjach.

Oddzielny benchmark threat hunting z 2026 roku opisał podobny problem. Pięć wiodących modeli przeszukiwało surowe logi zdarzeń Windows z 26 kampanii ataków, a najlepszy model znalazł jedynie niewielką część złośliwych zdarzeń.

Oba badania testują różne procesy pracy, więc ich wyników nie można bezpośrednio porównywać. Sugerują jednak, że nieskierowane wyszukiwanie pozostaje trudniejsze niż rozumowanie na podstawie wcześniej wybranych dowodów.

To zasadnicze odwrócenie wniosków płynących z benchmarku. Agenci wydają się najbardziej zdolni tam, gdzie konwencjonalne narzędzia bezpieczeństwa już ograniczyły niepewność. Stają się mniej niezawodni tam, gdzie śledczy zwiększają wartość poprzez kwestionowanie tego, czego alert nie ujawnił.

Zespół bezpieczeństwa nadal może produktywnie wykorzystywać AI w tych granicach. Model może podsumowywać dowody, proponować hipotezy, tworzyć zapytania, porównywać artefakty i prowadzić oś czasu dochodzenia.

Niebezpiecznym krokiem jest uznanie tych możliwości za dowód, że model przeszukał cały incydent. SecRespond pokazuje, że elokwentna odpowiedź może współistnieć z niewykrytą trwałością i niepełnym opisem aktywności atakującego.

Wyniki wykrywania skrywają większą lukę w naprawie

Znalezienie większej liczby dowodów nie przełożyło się na równie kompletne plany oczyszczania, co czyni naprawę drugim głównym obszarem porażki benchmarku.

Każdy oceniany model uzyskał wyższy wynik w wykrywaniu niż w planowaniu. W przypadku GPT-5.5 zgłoszona różnica sięgnęła 34,7 punktu procentowego.

Badacze przypisują ten wzorzec temu, że agenci stosują oczywistą pierwszą poprawkę, pomijając pozostałe działania. To zachowanie przypomina skracanie listy kontrolnej: gdy główny złośliwy obiekt otrzyma odpowiedź, model zachowuje się tak, jakby incydent został rozwiązany.

Rzeczywista naprawa rzadko kończy się na jednym usunięciu lub zmianie konfiguracji. Osoba reagująca musi uwzględnić zależności, zachowanie dowodów, wpływ na biznes, ciągłość usług, ujawnienie poświadczeń oraz alternatywne ścieżki dostępu atakującego.

Wynik planowania w SecRespond ocenia, czy działanie jest poprawne i kompletne. Bada także weryfikację i skutki uboczne, gdy wymagają tego odpowiednie punkty kontrolne.

Weryfikacja nie jest formalnością. Plan usunięcia zaplanowanego zadania powinien potwierdzić, że zadanie już nie istnieje i że jego ładunek nie może zostać uruchomiony innym mechanizmem.

Plan zablokowania adresu atakującego powinien, tam gdzie to właściwe, uwzględniać zarówno ruch przychodzący, jak i wychodzący. Nie powinien też sugerować, że blokada adresu usuwa złośliwe oprogramowanie, skradzione poświadczenia lub trwałość już obecną na hoście.

Ustandaryzowane problemy konfiguracyjne okazały się łatwiejsze. Claude Opus 4.7 osiągnął 74,8 procent w planowaniu dla ryzyk bazowych i 72,6 procent dla ryzyk związanych z podatnościami.

Takie zadania często odpowiadają znanym działaniom, takim jak wzmocnienie konfiguracji lub aktualizacja dotkniętego oprogramowania. Agent może pobrać rozpoznawalny wzorzec naprawy i zastosować go do ustalenia.

Jakość dochodzenia i reakcji pozostała znacznie słabsza. Średnia skuteczność planowania w tej kategorii wyniosła zaledwie 31,8 procent.

Kategoria obejmuje pracę zależną od syntezy, a nie od jednej znanej poprawki. Wlicza się do niej rekonstrukcja łańcucha ataku, jakość dowodów, uczciwość wobec niepewności, kompletność, weryfikacja i świadomość wpływu operacyjnego.

Najlepszy wynik wykrywania w tej kategorii osiągnął 75,5 procent. Według artykułu niemal każdy model pozostał poniżej 50 procent w planowaniu.

Wyniki te podważają prostą strategię skalowania. Przekazanie modelowi większej liczby alertów nie tworzy automatycznie kompletnego planu reakcji. Więcej widocznych ustaleń może zamiast tego prowadzić do większej liczby niepowiązanych rekomendacji.

Wiarygodny plan wymaga kolejności działań. Zespoły mogą odizolować maszynę przed wprowadzeniem zmian, zachować ulotne dowody przed zakończeniem procesów oraz rotować poświadczenia po określeniu zakresu ekspozycji.

Muszą także uwzględniać wycofanie zmian i działanie usług. Usunięcie przejętego komponentu bez zrozumienia zależności może przerwać produkcję lub zniszczyć dowody potrzebne do atrybucji.

SecRespond ocenia pisemne plany, a nie rzeczywistą naprawę w systemach produkcyjnych. Ogranicza to zakres wniosków, jakie benchmark może ustalić, ale jednocześnie utrzymuje pytanie o bezpieczeństwo w centrum uwagi.

Jeśli model nie potrafi konsekwentnie opisać kompletnej i zweryfikowanej naprawy w kontrolowanym środowisku, organizacje mają niewielkie podstawy, by przyznawać mu nieograniczone uprawnienia na działającym hoście.

Benchmark wspiera zatem węższy model operacyjny. AI może proponować działania, porządkować dowody i wskazywać brakujące pola, podczas gdy ludzie reagujący zachowują uprawnienia do zatwierdzania kroków powstrzymywania i odzyskiwania.

Taki układ nie jest odrzuceniem automatyzacji SOC. Jest odpowiedzią na konkretną asymetrię w danych. Systemy lepiej identyfikowały znane obiekty, niż zapewniały bezpieczne potraktowanie każdej konsekwencji.

Zespoły bezpieczeństwa powinny odzwierciedlić tę asymetrię w kontrolach dostępu. Dostęp tylko do odczytu dla działań kryminalistycznych niesie inne ryzyko niż uprawnienie do zabijania procesów, usuwania plików, wyłączania kont lub zmiany polityki sieciowej.

Agent, który pomija ukryty artefakt, tworzy niekompletny raport. Agent, który działa na podstawie tego niekompletnego raportu, może zakłócić odzyskiwanie, pozostawiając alternatywną drogę atakującego nienaruszoną.

Czego liczby nie dowodzą

SecRespond jest mocnym dowodem wspólnego ograniczenia, lecz nie stanowi ostatecznego werdyktu dotyczącego każdego modelu ani każdej produkcyjnej konfiguracji SOC.

Artykuł jest preprintem arXiv, a nie ukończonym wynikiem recenzji naukowej. Jego autorzy obejmują badaczy z Tongyi Lab i Alibaba Cloud, a benchmark ocenia modele za pośrednictwem jednego reprezentatywnego zestawu narzędzi.

Wybór OpenCode pomaga ujednolicić użycie narzędzi w różnych systemach. Oznacza to również, że wyniki mierzą połączenie modelu i zestawu narzędzi, a nie abstrakcyjną zdolność modelu oderwaną od promptów, narzędzi, zarządzania kontekstem i polityki wykonywania.

Inna infrastruktura pomocnicza może zmienić wydajność. Agent reagowania na incydenty mógłby korzystać z obowiązkowej listy kontrolnej dochodzenia, wyspecjalizowanych narzędzi kryminalistycznych, wyszukiwania w wewnętrznych procedurach, wielu współpracujących agentów lub deterministycznych skryptów walidacyjnych.

SecRespond pozostaje użyteczny, ponieważ te ulepszenia można testować na tych samych zakresach. Opublikowanych wyników nie należy jednak traktować jako trwałych ograniczeń dla każdej rodziny modeli.

Ocena wykorzystuje także proces LLM-as-a-judge, co oznacza, że modele językowe oceniają wygenerowane raporty względem szczegółowych list kontrolnych. Trzech własnościowych sędziów użyto niezależnie, aby ograniczyć zależność od jednego oceniającego.

Sędziami tymi byli Claude Opus 4.7, Gemini 3.1 Pro i GPT-5.4 Pro. Wielu sędziów ogranicza indywidualne uprzedzenia, lecz nie eliminuje każdego problemu kalibracji.

Oceniający może inaczej niż ludzki specjalista kryminalistyki interpretować niepełne sformułowania. Może też nagradzać wyraźny język raportu, nie rozstrzygając w pełni, czy podstawowy proces dochodzenia był prawidłowy.

Instrukcje punktacji próbują ograniczyć to ryzyko. Sędziowie muszą przytaczać dowody i przyznawać punkty wyłącznie za treści wyraźnie obecne w raportach.

280 punktów kontrolnych benchmarku zapewnia dodatkową strukturę. Każda lista kontrolna koduje jednak wybory dotyczące tego, którym artefaktom, krokom reakcji i cechom należy przypisać wagę.

10 zakresów jest wystarczająco zróżnicowanych, by ujawnić powtarzające się zachowanie. Nie obejmują one każdego systemu operacyjnego, architektury chmurowej, platformy tożsamości, produktu endpointowego ani techniki atakującego.

Środowiska są również kontrolowane. Badacze przygotowali i skompromitowali hosty na potrzeby benchmarku, a następnie usunęli poświadczenia i dane osobowe.

Ten projekt umożliwia odtwarzalność i zapobiega ujawnianiu informacji produkcyjnych. Nie może w pełni odtworzyć szumu, niekompletnej telemetrii, ograniczeń organizacyjnych i zależności biznesowych występujących w rzeczywistym incydencie przedsiębiorstwa.

Jeden wynik ilustruje również, jak zachowanie związane z bezpieczeństwem może wpływać na pokrycie benchmarku. Claude Opus 4.7 odmówił wykonania zadania npm-worm, dlatego artykuł pominął ten model w szczegółowej tabeli punktów kontrolnych dla tego zakresu.

Odmowa może obniżać użyteczność operacyjną podczas legalnego dochodzenia obronnego. Może też odzwierciedlać wysiłki dostawcy, aby zapobiec przechodzeniu pomocy o podwójnym zastosowaniu w szkodliwe wskazówki.

SecRespond nie rozstrzyga tego kompromisu politycznego. Pokazuje, że bezpieczne wdrożenie potrzebuje definicji zadań odróżniających autoryzowaną pracę kryminalistyczną od instrukcji ofensywnych.

Autorzy benchmarku stwierdzają, że opublikowane dowody pochodzą z izolowanych środowisk i nie zawierają działających łańcuchów exploitów. Materiały publiczne są przeznaczone do badań obronnych.

Ograniczenie to ma znaczenie przy interpretowaniu twierdzeń o reakcji w „rzeczywistym świecie”. Zakresy odtwarzają kompleksowe kompromitacje z użyciem rzeczywistych protokołów sieciowych, lecz opublikowany pakiet zawiera oczyszczone dowody kryminalistyczne zamiast aktywnych narzędzi atakujących.

Nie istnieje również niezależne badanie terenowe pokazujące, jak wyniki SecRespond przekładają się na oszczędność czasu analityków, zmniejszenie dotkliwości incydentów lub poprawę szybkości powstrzymywania. Wyniki te wymagają ocen wewnątrz zespołów operacyjnych.

Dla kupujących właściwa interpretacja powinna być zatem wyważona. Benchmark zdecydowanie podważa niepoparte twierdzenia o autonomicznym reagowaniu na incydenty. Nie pokazuje jednak, że pomoc AI nie ma wartości w SOC prowadzonym przez ludzi.

Nie ustanawia też, że jeden wskazany model pozostanie na czele w przyszłych wersjach. Zgłoszona seria Claude poprawiała się między wydaniami, podczas gdy postęp w innych rodzinach nie był powszechny.

Znaczącą jednostką oceny jest wdrożony system. Obejmuje on model, narzędzia, prompty, uprawnienia, źródła wyszukiwania, bramki przeglądu, logowanie i procedury odzyskiwania.

Trzy sygnały, na które warto zwrócić uwagę po cyklu Google News dotyczącym SecRespond

Kolejnym testem będzie to, czy dostawcy poprawią niekierowane wykrywanie, weryfikację naprawy i odtwarzalną ocenę produkcyjną.

Pierwszym sygnałem jest niezależne odtworzenie. Badacze i dostawcy zabezpieczeń mogą uruchomić publiczne repozytorium benchmarku z innymi zestawami narzędzi, promptami, narzędziami i wersjami modeli.

Odtworzenie pokaże, czy luka dotycząca cichych włamań utrzymuje się po zmianach infrastruktury pomocniczej. Jeśli wyspecjalizowani agenci kryminalistyczni nadal będą pomijać trwałość nieujawnioną przez alerty, centralna ocena artykułu stanie się mocniejsza.

Jeśli deterministyczne procedury wyszukiwania przyniosą duże zyski, wniosek nieco się zmieni. Wąskie gardło będzie leżeć mniej w wiedzy modelu, a bardziej w projekcie dochodzenia, kierowaniu narzędzi oraz wymuszonym pokryciu.

Nadal osłabiałoby to twierdzenia dotyczące uniwersalnych autonomicznych agentów. Zapewniłoby też wyraźniejszą ścieżkę inżynieryjną dla bezpieczniejszych systemów.

Drugim sygnałem jest to, czy dostawcy opublikują oddzielne wyniki wykrywania i naprawy. Pojedyncza liczba „dokładności reagowania na incydenty” może ukrywać lukę w planowaniu, którą ujawnił SecRespond.

Użyteczne oceny powinny wskazywać, co system znalazł, co pominął, jakie działanie zaproponował i jak zweryfikował zakończenie. Powinny również raportować odmowy, awarie narzędzi i przypadki wymagające interwencji człowieka.

Warto zwracać uwagę szczególnie na testowanie mechanizmów trwałości. Ulepszenia w przypadku złośliwego oprogramowania powiązanego z alertami są istotne, lecz nie dotyczą głównej ślepej plamki benchmarku.

Warto także obserwować, czy plany obejmują szerokość oczyszczania. Silniejszy agent powinien, gdy ma to zastosowanie, obsługiwać procesy, pliki, konta, zaplanowane wykonywanie, kontrolę sieci, rotację poświadczeń, odzyskiwanie usług i walidację po naprawie.

Trzecim sygnałem są dowody z nadzorowanych wdrożeń SOC. Dostawcy muszą pokazać, jak ich agenci działają z rzeczywistą telemetrią, wewnętrznymi procedurami, kontrolami dostępu i bramkami zatwierdzania przez analityków.

Najmocniejszym dowodem operacyjnym nie będzie wyłącznie dopracowane studium przypadku. Będzie obejmował wskaźniki pominięć, wskaźniki eskalacji, niepoparte twierdzenia, częstotliwość korekt oraz odsetek rekomendacji zatwierdzanych przez analityków bez zmian.

Wiarygodne wdrożenie powinno zachowywać ślad audytowy. Recenzenci muszą móc prześledzić wnioski do artefaktów i ustalić, jakie wyszukiwania agent zakończył, zanim się zatrzymał.

Organizacje powinny także testować granice uprawnień. Dochodzenie tylko do odczytu, rekomendowane działania i autonomiczne wykonywanie reprezentują trzy różne poziomy ryzyka.

SecRespond wspiera wdrożenie na pierwszych dwóch poziomach, jednocześnie nakładając wysoki ciężar dowodu na trzeci. Jego wyniki nie uzasadniają przekazania szerokich uprawnień do powstrzymywania modelowi, który nie wykazał kompleksowego wykrywania.

Nagłówek w Google News z czasem zniknie, ale ten benchmark pozostawia zespołom bezpieczeństwa trwałe pytanie zakupowe: co agent znajduje, gdy żaden alert nie wskazuje mu, gdzie ma szukać?

Poproś dostawców, by odpowiedzieli na to pytanie, przedstawiając powtarzalne dowody. Następnie zapytaj, jak system weryfikuje każdy etap działań naprawczych i sygnalizuje niepewność człowiekowi odpowiedzialnemu za reakcję.

Odpowiedzi pokażą, czy produkty AI SOC stają się narzędziami dochodzeniowymi, czy pozostają szybkimi asystentami działającymi wokół istniejących mechanizmów wykrywania. Na razie SecRespond umieszcza wszystkie 23 testowane modele po stronie asystentów tej granicy.