Jak testować AI broniącą sieci, gdy narzędzia obrony same działają autonomicznie

👁 120 przeczytań

Kerri Prinos i Lilianne Brush opublikowały na arXiv (2606.08168) artykuł liczący 17 stron, w którym opisują problem oceny autonomicznych agentów obronnych działających z komercyjnymi systemami EDR (endpoint detection and response). Pierwsza wersja trafiła na serwer 6 czerwca 2026, druga - 21 października 2026.

Na czym polega problem

Nowoczesne komercyjne systemy EDR przestały być pasywnymi narzędziami konfigurowanymi przez operatora. Autorki piszą, że produkty te przeszły od zestawów reguł konfigurowanych przez operatora do wielokomponentowych systemów, w których autonomiczne komponenty AI działają obok i coraz częściej zamiast polityk wdrożonych przez operatora. Innymi słowy, gdy autonomiczny agent obronny próbuje skonfigurować taki system, nie kręci gałkami w pasywnym narzędziu, tylko wchodzi w interakcję z czarną skrzynką, która sama podejmuje decyzje według logiki producenta.

To rodzi fundamentalne pytanie: jak w ogóle oceniać, czy agent obronny robi coś pożytecznego, skoro część działań obronnych wykonuje sam EDR, a nie agent?

Co zbudowały autorki

Prinos i Brush przedstawiają to, co opisują jako pierwsze ramy oceny (evaluation framework) dla autonomicznych agentów obronnych konfigurujących komercyjny EDR. Ramy zostały uruchomione w laboratorium Game of Active Directory (GOAD). Jako autonomiczny pentester użyto NodeZero firmy Horizon3, a głównym testowanym EDR był Microsoft Defender XDR. Następnie te same ramy rozszerzono na CrowdStrike Falcon i SentinelOne Singularity, by sprawdzić, czy wnioski z testów Defendera są specyficzne dla Microsoftu, czy ogólniejsze.

W próbnym benchmarku agentów obronnych użyto dwóch modeli językowych jako rdzeni (backbone): Claude Sonnet 4.6 oraz Cisco Foundation-Sec-8B. Dokument nie zawiera szczegółowych wyników liczbowych tego benchmarku - autorki skupiają się na opisie metodologii i wnioskach jakościowych.

Trzy lekcje, których nie widać w symulacjach

Autorki raportują trzy lekcje, których - jak twierdzą - nie da się wyciągnąć ani z symulacji, ani z testów na oprogramowaniu open source.

Po pierwsze, telemetria komercyjnego EDR jest projektowana pod workflow analityków SOC, a nie pod mierzenie skuteczności polityk. Oznacza to, że dane, które agent dostaje z systemu, nie nadają się bezpośrednio do oceny, czy jego własne działania cokolwiek zmieniły.

Po drugie, przypisanie działań do konkretnych polityk (per-policy attribution) jest kluczowe dla odróżnienia, co zrobił agent, a co zrobił sam EDR działając autonomicznie. Bez tego rozróżnienia nie wiadomo, komu przypisać zasługę lub winę za wynik.

Po trzecie, zachowanie EDR różni się między kolejnymi uruchomieniami, głównie dlatego, że „containment” - czyli izolowanie zagrożeń - akumuluje się i zmienia stan środowiska. To sprawia, że testy nie są powtarzalne w oczywisty sposób.

Wniosek autorski

Wszystkie trzy obserwacje razem wskazują na to, co autorki nazywają „sim-to-real gap” - luką między testami w symulacji a zachowaniem w realnym środowisku korporacyjnym. Motywuje to, ich zdaniem, potrzebę nowej metodologii benchmarkowania agentów obronnych w środowiskach zawierających czarne skrzynki z własną autonomią.

Co z tego wynika

Moim zdaniem ten artykuł dotyka czegoś, o czym rzadko się mówi wprost: gdy do autonomicznego atakującego dołożymy autonomicznego obrońcę, a ten obrońca konfiguruje system, który sam też działa autonomicznie, mamy trzy warstwy agentów i żadnego prostego sposobu, żeby powiedzieć, kto co zrobił. Wartość tego tekstu nie leży w wynikach benchmarku - tych właściwie nie ma - lecz w precyzyjnym nazwaniu trzech konkretnych problemów metodologicznych. To praca z obszaru „jak w ogóle mierzyć”, a nie „zmierzyliśmy i oto wyniki”. Dla kogoś, kto buduje lub ocenia systemy bezpieczeństwa oparte na AI w środowiskach korporacyjnych, te trzy lekcje są praktycznym przewodnikiem, czego nie zakładać przy projektowaniu testów.

Źródło: arXiv cs.AI: Closing the Sim-to-Real Gap: An Evaluation Framework for Autonomous Cyber Defense Configuration of Commercial EDR (dokument z 2026-10-22). To omówienie powstało na podstawie pełnego tekstu dokumentu, nie relacji innych mediów.