AI Kontra Pentesterzy – Lekcje Z Badania Stanford 2025

Dlaczego to ma znaczenie

Rosnące zdolności sztucznej inteligencji (AI) wywołują pytania o jej wpływ na bezpieczeństwo – zarówno pozytywny, jak i negatywny. Najnowsze raporty wskazują, iż zaawansowane grupy atakujące (od cyberprzestępców po aktorów państwowych) już zaczynają wykorzystywać AI w operacjach ofensywnych. W odpowiedzi liderzy branży (np. OpenAI, Anthropic) uwzględniają ryzyko cyber w swoich zasadach bezpieczeństwa AI. Skoro napastnicy testują AI jako broń, obrońcy muszą zrozumieć, na co stać takie systemy – jak wypadają one na tle żywych pentesterów?

Dotychczas pojawiły się wprawdzie benchmarki do oceny AI w cyberbezpieczeństwie, takie jak BountyBench czy CyBench, oraz eksperymentalne agentowe frameworki (np. CyAgent, Incalmo, MAPTA). Jednak wiele z tych prób miało charakter teoretyczny lub odbywało się w warunkach laboratoryjnych, jak quizy Q&A albo symulacje CTF. Brakowało realizmu – prawdziwe sieci pełne są „szumu”, interakcji i niespodzianek, których nie oddają proste zadania. Co więcej, większość realnych włamań nie polega na jednym znanym CVE, ale na łańcuchach zdarzeń: wykorzystaniu wykradzionych poświadczeń, błędnej konfiguracji, phishingu czy niezałatanych dziur. Przykładowo, raport Verizon DBIR 2025 wskazuje, iż podatności stanowiły wektor startowy ataku w 20% incydentów (wzrost z 15% rok wcześniej), a Mandiant odnotowuje, iż aż 42% włamań wiązało się z exploitacją luk. jeżeli AI potrafi szybciej i taniej wykrywać takie podatności, może to radykalnie zmienić reguły gry dla Red Teamów (atakujących) i Blue Teamów (obrońców).

Najnowsze badanie Stanforda (2025) próbuje odpowiedzieć na te pytania, porównując bezpośrednio agenta AI i profesjonalnych pentesterów w realnym środowisku. To pionierskie przedsięwzięcie pokazało, gdzie AI błyszczy, gdzie zawodzi oraz jakie wnioski strategiczne powinni z tego wyciągnąć praktycy bezpieczeństwa. Poniżej omawiamy najważniejsze rezultaty i ich znaczenie – bez marketingowego szumu, za to z technicznymi konkretami.

AI kontra pentesterzy: test w realnym środowisku (badanie Stanford 2025)

Agent ARTEMIS – nowy rywal dla ludzkich pentesterów

W ramach eksperymentu badacze z Uniwersytetu Stanforda stworzyli autonomicznego agenta pentesterskiego o nazwie ARTEMIS. To nie pojedynczy bot, ale framework multi-agentowy – coś w rodzaju roju współpracujących botów z centralnym nadzorcą. ARTEMIS potrafi dynamicznie generować instrukcje (prompty) dla pod-agentów, uruchamiać dowolną liczbę sub-agentów do równoległych zadań oraz automatycznie triagować (oceniać) znalezione podatności. Innymi słowy, zaprojektowano go tak, by wydobyć z nowoczesnych modeli AI (GPT-4/5, Claude etc.) maksimum ofensywnych zdolności w warunkach zbliżonych do prawdziwego testu penetracyjnego.

Sam skrót ARTEMIS zdradza ambicje projektu – Automated Red Teaming Engine with Multi-agent Intelligent Supervision. Agent-nadzorca zarządza workflowem ataku, a rój sub-agentów wykonuje równolegle zadania: skanowanie, eksploitacja, zbieranie logów itp. Całość ma wbudowany moduł notatek i podsumowań, dzięki czemu agent może pracować dłużej bez “zapominania” (sesje są okresowo streszczane, aby odciążyć kontekst LLM). Framework ten jest na tyle uniwersalny, iż można go uruchomić w tej samej infrastrukturze co człowieka pentestera – w badaniu ARTEMIS działał na zwykłej maszynie wirtualnej obok środowiska testowego.

Co ważne, ARTEMIS to krok naprzód względem wcześniejszych agentów. Poprzednie podejścia (np. OpenAI Codex, Claude Code, wspomniany CyAgent czy MAPTA) okazały się mniej skuteczne i bardziej ograniczone – nie radziły sobie z długotrwałym działaniem, odmawiały wykonania pewnych poleceń lub miały sztywne, zaszyte na sztywno sekwencje działań. ARTEMIS został zaprojektowany, by te słabości obejść dzięki elastycznej architekturze. To czyni z niego potencjalnie nowego rywala dla ludzkich pentesterów – agenta, który łączy szybkość maszyny z pomysłowością zawartą w ogromnych modelach językowych.

Skuteczność i koszt: ile podatności znalazło AI i za jaką cenę

Stanfordzki test przeprowadzono na dużej, rzeczywistej infrastrukturze: sieci uniwersyteckiej ~8000 hostów w 12 podsieciach, z typowym przekrojem usług (Windows, Unix, IoT, urządzenia sieciowe, w tym np. serwery Dell iDRAC) zabezpieczonej standardowymi mechanizmami (firewalle, systemy IDS, łatki na bieżąco itp.). Do „wyścigu” stanęło dziesięciu doświadczonych pentesterów (każdy otrzymał wynagrodzenie 2000 USD za udział) oraz sześć różnych agentów AI, w tym ARTEMIS w dwóch konfiguracjach. Zawodnicy mieli do dyspozycji maksymalnie 4 dni dostępu do systemu (w tym do 10 godzin aktywnej pracy na testy) – warunki zbliżone do krótkiego engagementu pentestowego.

Wyniki? ARTEMIS zdeklasował niemal całą konkurencję. W swojej najlepszej konfiguracji (wielomodelowej, z mieszanką GPT-5, Claude i innych jako sub-agentów) znalazł 9 unikalnych, potwierdzonych podatności i zajął 2. miejsce w ogólnym rankingu. Co istotne, przegonił 9 z 10 ludzkich uczestników – tylko jeden człowiek zdobył minimalnie lepszy wynik (odkrył 13 podatności). Pozostali pentesterzy znaleźli od 3 do 13 podatności każdy (łącznie 49 unikalnych błędów w całym badaniu). Agent ARTEMIS jakościowo dorównał najlepszym: zgłoszone przez niego błędy miały porównywalną złożoność techniczną i krytyczność jak znaleziska topowych pentesterów. Skuteczność (precision) jego raportów była wysoka – około 82% zgłoszeń okazało się prawdziwymi podatnościami (czyli współczynnik false positive ~18%). Dla porównania, niektóre inne agenty AI wypadły słabo: np. OpenAI Codex znalazł kilka i zakończył pracę już po ~20 minutach, a Claude czy MAPTA wręcz odmówiły wykonania ofensywnych kroków (mechanizmy bezpieczeństwa zadziałały).

Jednym z kluczowych parametrów była efektywność kosztowa. Tu AI błyszczy: uruchomienie ARTEMIS (zużycie mocy obliczeniowej modeli) oszacowano na około $18 na godzinę, podczas gdy godzina pracy profesjonalnego pentestera kosztuje w badaniu ~$60. Dla kontekstu – średnia pensja pentestera w USA to ok. $125k rocznie, co daje ~$60/h właśnie. Wychodzi na to, iż agent AI już dziś osiąga porównywalne wyniki za ułamek ceny. Jak ujęto w raporcie, stosunek koszt-do-wyniku jest po stronie AI. Oczywiście, test trwał krótko i w kontrolowanych warunkach – to nie to samo co pełnozakresowy, kreatywny red teaming trwający tygodniami. Jednak choćby z tym zastrzeżeniem sygnał jest jasny: autonomiczne AI może stać się poważnym graczem w pentestach pod względem opłacalności.

Mocne strony agentów AI w ofensywie

AI nie męczy się monotonnią zadań ani nie traci koncentracji – te cechy przekładają się na konkretne przewagi w testach penetracyjnych:

• Systematyczna enumeracja i automatyzacja ataków: Agent AI metodycznie skanuje i analizuje cały dostępny zakres IP, portów i usług, nie pomijając „nudnych” elementów. Tam gdzie człowiek pentester bywa selektywny (np. sprawdza tylko najciekawsze usługi), AI przeprowadza enumerację po kolei, wykrywając słabe punkty konfiguracji, ukryte endpointy API czy podatności typu SSRF, LDAP czy XSS, które łatwo przeoczyć. Badanie potwierdziło tę zaletę – AI wykazał się systematycznym przeszukiwaniem powierzchni ataku, co zostało wymienione jako jedna z głównych korzyści. W praktyce oznacza to, iż agent wygeneruje np. dziesiątki wariantów payloadów SQLi czy RCE i wyśle setki żądań typu fuzzing, podczas gdy człowiek zrobi ich kilka najbardziej obiecujących. Taka automatyzacja zwiększa szansę wychwycenia rzadkich błędów konfiguracyjnych – jak choćby nietypowy błąd w starym interfejsie iDRAC, opisany dalej.
• Równoległe exploitowanie wielu celów jednocześnie: Tam, gdzie człowiek działa sekwencyjnie, agent AI atakuje równolegle. ARTEMIS mógł jednocześnie uruchamiać choćby do 8 sub-agentów, każdy skupiony na innym wektorze ataku. Przykładowo, gdy skaner wykrył podatny serwer LDAP i jednocześnie otwarty panel administracyjny gdzie indziej, AI natychmiast rozdzielił zadania – jeden sub-agent zajął się testowaniem LDAP (np. próbował nieznanych loginów lub ataku przez niebezpieczne zapytania), drugi równolegle szukał exploita na panel. Ludzkim pentesterom brakuje takiego równoległego multitaskingu – w badaniu zaobserwowano np. eksperta, który co prawda zauważył otwarty port LDAP, ale pochłonięty innym tropem nigdy już do niego nie wrócił. AI nie „zapomina” – odkrycie każdej potencjalnej dziury skutkuje natychmiastowym podjęciem wątku. To jak posiadanie zespołu wielu testerów pracujących jednocześnie za cenę jednego.
• Skalowalność i ciągłość działania: 24/7 testy za ułamek kosztów: Agent AI się nie męczy, nie potrzebuje snu ani przerw – może teoretycznie prowadzić pentest non-stop 24/7. W praktyce badanie ograniczyło czas działania do kilkudziesięciu godzin, ale już pokazuje potencjał: większość konkurencyjnych agentów kończyła pracę znacznie przed upływem 10 godzin, podczas gdy ARTEMIS był zdolny kontynuować zadania dzięki mechanizmom odświeżania kontekstu. Wyobraźmy sobie teraz wdrożenie takiego agenta na stałe w firmowej sieci – może on ciągle testować nowe wdrożenia, skanować pojawiające się usługi i natychmiast alarmować o niepokojących znaleziskach. I to wszystko przy kosztach znacznie niższych niż praca ludzi. Skalowalność przejawia się też w tym, iż jednego agenta można gwałtownie „rozmnożyć” – odpalić kopię środowiska AI, by równolegle sprawdzał inną część systemu lub kolejny oddział firmy. Dla zespołów bezpieczeństwa oznacza to możliwość pokrycia większej powierzchni ataku bez proporcjonalnego zwiększania budżetu.

Ograniczenia i słabe strony agentów AI

Żaden system nie jest doskonały – AI również ma istotne słabości w roli pentestera:

• Problemy z interfejsami GUI i niestandardowymi środowiskami: Dzisiejsze agentowe AI to w gruncie rzeczy specjaliści od tekstu/CLI – świetnie radzą sobie z konsolą, HTTP i kodem, ale nie potrafią klikać po interfejsach graficznych. W badaniu wyszło to boleśnie na przykładzie systemu TinyPilot (interfejs KVM over IP). 80% pentesterów zidentyfikowało krytyczną podatność RCE na Windowsie udostępnionym przez TinyPilot (wymagało to interakcji przez przeglądarkę), podczas gdy ARTEMIS poległ na obsłudze GUI. AI zamiast wykonać czynności w web GUI, próbował znaleźć znane błędy TinyPilot w sieci – i owszem, znalazł tylko mniej istotne mis-k konfiguracje (np. wildcard w CORS, niebezpieczne flagi ciastek) i je zgłosił, przeoczając prawdziwą dziurę. Innymi słowy, tam gdzie potrzebna jest interakcja “jak człowiek” – kliknięcie w aplikacji, użycie nietypowego klienta (np. customowego protokołu, aplikacji desktopowej) – obecne AI są bezradne. choćby jeżeli istniałyby narzędzia automatyzujące GUI, model językowy musiałby być na nie przygotowany. Niestandardowe środowiska (np. systemy wbudowane, SCADA, protokoły przemysłowe) także mogą zbić AI z tropu, jeżeli w treningu nie pojawiło się nic podobnego. Wniosek: tam, gdzie atak wymaga kreatywnej interakcji z nietypowym systemem, człowiek przez cały czas ma przewagę.
• Fałszywe alarmy i brak kontekstu przy ocenie zagrożeń: AI bywa zbyt „ufne” w wyniki swoich skryptów, przez co częściej raportuje false positives. Przykład z testu: ARTEMIS próbował zalogować się z domyślnymi poświadczeniami (default credentials, np. admin/admin albo root/calvin na iDRAC) i otrzymał odpowiedź HTTP 200 OK. Uznał to za sukces – w raporcie stwierdził, iż hasło było prawidłowe. W rzeczywistości jednak serwer zwracał kod 200 choćby przy błędnym loginie, ładując ponownie stronę logowania z komunikatem błędu (redirect wewnętrzny). Człowiek oglądający GUI od razu zrozumiałby, iż login nie przeszedł – agent CLI zobaczył „200 OK” i ogłosił zwycięstwo. To pokazuje brak kontekstu: model nie „czuje”, co oznacza dana odpowiedź w szerszym flow aplikacji. False positives to poważny problem, bo zalew fałszywych alarmów może odwracać uwagę i marnować czas (znany bolączka narzędzi skanujących). Co więcej, AI ma ograniczone pojęcie o kontekście biznesowym – może nie odróżnić, które znalezisko jest krytyczne dla danej organizacji. Pentester potrafi ocenić: “OK, RCE na serwerze testowym to nie to samo co RCE na kontrolerze domeny”. Dla AI oba mogą wyglądać podobnie (np. dostęp do shelła), jeżeli nie ma w wiedzy domenowej, czym jest kontroler AD. Dlatego raporty AI trzeba traktować ostrożnie i weryfikować krytyczność znalezisk w kontekście środowiska.
• Granice kreatywności i adaptacji poza danymi treningowymi: Mimo imponujących zdolności, AI wciąż działa na podstawie wzorców, które widział w danych treningowych. Brakuje mu błyskotliwej improwizacji, którą czasem wykazują się ludzie. W praktyce zauważono to w podejściu do eksploitacji: topowi pentesterzy w badaniu po znalezieniu pierwszej podatności często pivotowali dalej – np. uzyskali dostęp low-level, a potem szukali przyczółków do eskalacji uprawnień lub penetracji kolejnych segmentów sieci. ARTEMIS tymczasem miał tendencję do “odhaczania” znaleziska i przechodzenia dalej. W efekcie przegapił pewne możliwości kombinacji ataków – np. gwałtownie zgłosił mniej groźny błąd CORS w interfejsie, nie wykorzystując go jako furtki do znalezienia głębszej podatności RCE. Taka liniowość to ograniczenie: scenariusze wykraczające poza typowe szablony (np. atak łańcuchowy wymagający kilku nietypowych kroków, social engineering połączony z exploitacją techniczną, itp.) mogą umknąć agentowi AI. Ponadto model może nie umieć się douczyć w trakcie testu – człowiek po nieudanej próbie pomyśli „a może spróbuję inaczej?”, AI częściej utknie w utartych schematach. To oczywiście będzie się zmieniać wraz z rozwojem few-shot learning i zdolności adaptacyjnych modeli, ale na dziś kreatywność ludzkiego umysłu w wychodzeniu poza schematy jest trudna do podrobienia.

Zanim przejdziemy do wniosków o przyszłości red teamingu, doprecyzujmy zakres tego eksperymentu.
Ważne doprecyzowanie: to badanie jest „Red Team / infra-first”, nie „WebApp-first”. W eksperymencie Stanforda ARTEMIS i ludzie testowali dużą, realną sieć (hosty, usługi, urządzenia, protokoły), a typowy workflow zaczynał się od enumeracji i skanowania (nmap/masscan/rustscan, później m.in. nuclei i gobuster) i dopiero potem przechodził do prób exploitacji.
Owszem — w wynikach pojawiają się klasyczne podatności webowe (np. SQL Injection, Stored XSS), ale to wciąż nie jest pełnoprawny pentest aplikacji webowej, gdzie najważniejsze są złożone przepływy w GUI, stan sesji, role/uprawnienia, logika biznesowa oraz manualna analiza w narzędziach typu Burp. I właśnie na takich „GUI-heavy” zadaniach agent ma dziś realne ograniczenia, co w badaniu widać na przykładzie TinyPilota (AI myliło się choćby na prostych flow logowania, bo bazowało na odpowiedziach HTTP zamiast na kontekście GUI).
To nie unieważnia wyniku ARTEMIS — tylko mówi wprost, iż przenoszenie tych liczb 1:1 na typowy pentest webaplikacji (OWASP WSTG) jest dziś ryzykowne.

AI a przyszłość red teamingu

Autonomiczne pentesty 24/7 – nowy standard czy dodatkowe ryzyko?

Wyniki eksperymentu wskazują, iż autonomiczne pentestery mogą niedługo stać się codziennością. Skoro agent AI potrafi skutecznie przeskanować dużą sieć i znaleźć w ciągu godzin solidny zestaw podatności, firmy mogą zechcieć korzystać z takich narzędzi na co dzień. Autonomiczne red-teamy 24/7 brzmią kusząco – ciągłe, proaktywne wyszukiwanie słabości zanim zrobią to źli aktorzy. Taki „bot pentester” mógłby np. co noc testować nasze aplikacje i serwery, raportując rano wyniki. Daje to szansę na wcześniejsze wykrycie błędów (zwłaszcza tych oczywistych, jak brak uwierzytelnień czy default credentials) bez czekania na coroczny audyt bezpieczeństwa.

Trzeba jednak zadać pytanie o ryzyko. Czy puszczenie AI samopas w naszą infrastrukturę nie przyniesie szkód ubocznych? Już w opisywanym teście trzeba było uważać – dział bezpieczeństwa na bieżąco monitorował poczynania agentów i ręcznie zatwierdzał niektóre groźne akcje, które normalnie systemy ochronne by zablokowały. To pokazuje, iż pełna automatyzacja bez nadzoru może być ryzykowna: AI może np. niechcący wywołać DoS (atak typu denial-of-service) generując zbyt duży ruch, albo spróbować exploitować podatność w sposób, który uszkodzi system (np. wykorzystując exploit zero-day, który destabilizuje usługę). Ponadto dochodzą kwestie etyczne i prawne – pentest to kontrolowany atak, za który ktoś odpowiada. jeżeli AI zrobi coś nieprzewidzianego (np. wykroczy poza zakres testu wskutek błędnej interpretacji poleceń), kto poniesie odpowiedzialność? Organizacje muszą zatem wypracować zasady bezpiecznego użycia takich agentów: sandboxy, ścisłe zakresy testów, mechanizmy „kill switch” zatrzymujące bota, gdy dzieje się coś niepożądanego.

Z drugiej strony, ignorowanie tematu też jest ryzykowne. Tak jak kiedyś pojawiły się automatyczne skanery (Nessus, Metasploit) i stały się standardowym narzędziem, tak autonomiczne AI mogą stać się nowym standardem w arsenale Red Teamu. Co więcej, wiemy już, iż przestępcy również rozwijają własne agentowe AI. jeżeli obrońcy nie będą korzystać z podobnych lub lepszych narzędzi, znajdą się w tyle. Zatem pytanie „standard czy ryzyko” ma prostą odpowiedź: nowy standard, ale wdrażany z rozwagą.

Człowiek + AI: kooperacja zamiast rywalizacji w ofensywie

Najbardziej prawdopodobny scenariusz na przyszłość to nie “AI vs człowiek”, ale AI wspomagający człowieka. Zamiast zastanawiać się, czy AI zastąpi pentesterów, lepiej myśleć, jak może zwiększyć ich efektywność. Już teraz wielu specjalistów korzysta z AI asystentów (np. ChatGPT) do generowania exploitów, tłumaczenia logów czy wyszukiwania znanych CVE. Kolejny krok to pełna symbioza w red teamie: agent AI robi za „młodszego stażem” – wykonuje żmudną robotę, zbiera dane, odpala znane ataki – a senior pentester (człowiek) analizuje wyniki, potwierdza incydenty i przeprowadza niestandardowe, kreatywne ataki tam, gdzie AI utknie.

Badanie Stanforda także sugeruje taki model. Choć ARTEMIS działał autonomicznie, autorzy podkreślają, iż udostępniają go społeczności aby „poszerzyć dostęp obrońców do narzędzi AI w bezpieczeństwie”. Można to odczytać jako zachętę: weźcie to narzędzie i użyjcie w praktyce. Wyobraźmy sobie ćwiczenie Red Team vs Blue Team, gdzie Red Team to kombinacja ludzi i AI. AI gwałtownie zdobywa parę drobnych wejść (np. znajduje otwarte udziały SMB z hasłami, używa MITRE ATT&CK T1078.001 do odszukania domyślnych kont na urządzeniach, wykonuje słownikowe ataki logowania itp.), a ludzie w tym czasie koncentrują się na projektowaniu bardziej wyrafinowanych ścieżek ataku. W efekcie zespół czerwony ma większe pokrycie ataku i tempo, ale przez cały czas jest sterowany i nadzorowany przez doświadczonych ekspertów, którzy filtrują false positive’y i popychają atak tam, gdzie potrzeba pomysłowości (np. kombinacja SSRF+RCE, social engineering, fizyczne obejście zabezpieczeń). Z kolei Blue Team uczy się rozróżniać w logach aktywność zautomatyzowaną od manualnej i doskonali swoje mechanizmy wykrywania obu typów.

Podsumowując, przyszłość pentestów to współpraca: AI da skalę i szybkość, człowiek – kontekst i kreatywność. Taka synergia może podnieść poprzeczkę zarówno dla atakujących, jak i obrońców. Jak mówi branżowe porzekadło: “AI nie zastąpi ekspertów bezpieczeństwa, ale ekspert, który z niej korzysta, zastąpi tego, który tego nie robi.”

Wnioski i rekomendacje dla Blue Team

Z perspektywy obrony (Blue Team) pojawienie się agentów pentestowych AI to sygnał, żeby przyspieszyć i uszczelnić własne procedury. Skoro ofensywa staje się szybsza i bardziej zautomatyzowana, obrona musi nadążyć. Poniżej krótkie podsumowanie działań, jakie zespoły bezpieczeństwa powinny rozważyć już teraz:

• Automatyzuj wykrywanie luk i łatanie systemów: Skoro atakujący (zarówno red team wewnętrzny, jak i realni agresorzy) mogą szybciej odnaleźć podatności, skanowanie podatności i błędów konfiguracji powinno być ciągłe. Wdróż regularne skany (np. cotygodniowe lub ciągłe skanery nasłuchujące zmian) i priorytetyzuj szybkie łatanie krytycznych dziur. Verizon odnotował, iż czas exploitacji 0-day przez napastników skrócił się średnio do 11 dni, a połowa organizacji wciąż nie łata takich błędów choćby w 32 dni – nie bądź w tej połowie. Automatyzacja (skrypty CI/CD, rozwiązania IDR do wymuszania update’ów) to teraz mus, inaczej AI znajdzie niezałataną podatność zanim zdążysz mrugnąć.
• Monitoruj nietypową aktywność i zwiększ czujność poza godzinami pracy: Autonomiczny agent atakującego może wygenerować masę nietypowego ruchu – np. seryjne skanowanie portów, setki prób logowania, równoległe zapytania do różnych usług. Upewnij się, iż wasze systemy wykrywania (SIEM, IDS/IPS) są dostrojone do wychwytywania takich wzorców. Warto zbudować reguły na MITRE ATT&CK techniki typowe dla automatycznych ataków (np. T1190 – Exploit Public-Facing Application, T1078 – nadużycie legalnych kont). Ponadto zapewnij monitoring 24/7 – czy to we własnym SOC, czy przez usługę MSSP. Ataki wykonywane przez AI mogą nastąpić o dowolnej porze, a raport Mandiant pokazał, iż brak stałego nadzoru nocą i w weekendy daje napastnikom ogromną przewagę
• Wyeliminuj „łatwe cele” i wzmocnij podstawy higieny security: Automatyczny agent z dużym prawdopodobieństwem najpierw wychwyci nisko wiszące owoce. Upewnij się, iż w twojej infrastrukturze nie ma oczywistych zaniedbań: wszystkie ważne usługi wymagają uwierzytelnienia, brak stron testowych dostępnych publicznie, wyłączone nieużywane porty. Absolute must to usunięcie domyślnych haseł i znanych kredencji. To ulubiony cel automatów – w badaniu agent AI masowo próbował logować się defaultowymi danymi i czasem trafiał. CTA: Sprawdź, czy twoje serwery iDRAC nie mają domyślnych loginów. Podstawowe urządzenia administracyjne (KVM, IPMI, drukarki sieciowe itp.) powinny mieć hasła zmienione na unikatowe – inaczej choćby średnio zaawansowany skrypt je znajdzie.
• Testuj swoją infrastrukturę mieszanym podejściem (manual + AI): Rozważ włączenie narzędzi AI do wewnętrznych testów bezpieczeństwa. Możesz np. użyć open-source’owego ARTEMIS lub innego agenta na ograniczonej sandboxowej kopii swojej sieci, by zobaczyć, co znajdzie. Wykorzystaj wyniki jako uzupełnienie tradycyjnych pentestów, nie ich zastępstwo. Część firm zaczyna też organizować ćwiczenia Red Team vs Blue Team, gdzie Red Team ma wsparcie AI – to świetny sposób, by Blue Team przećwiczył reagowanie na zautomatyzowany atak. Im wcześniej poznacie styl działania takiego agenta, tym lepiej dostosujecie wasze mechanizmy detekcji i obrony.
• Inwestuj w rozwój ludzi w kierunku współpracy z AI: Zadbaj o szkolenia dla swojego zespołu z obsługi narzędzi opartych na AI – zarówno ofensywnych, jak i defensywnych. Blue Team może korzystać z AI do automatyzacji reakcji (np. skryptów w SOAR), a Red Team do automatyzacji ataku. Twoi specjaliści powinni rozumieć, jak działa agent AI, jakie ślady zostawia w logach, gdzie się myli. Dzięki temu zamiast bać się zastąpienia przez AI, staną się jej operatorami i kontrolerami. kooperacja człowiek-AI to przyszłość, więc lepiej, by twój Blue Team i Red Team już teraz zdobywały doświadczenie w duecie z AI.
• Załóż, iż napastnik ma równoległość: kilka ‘sub-agentów’ skanuje i exploituje naraz — więc alerty będą wyglądały jak skoordynowana seria działań, nie jak pojedynczy manualny pentester.

Podsumowanie

Na naszych oczach ofensywne AI przechodzi drogę od ciekawostki do realnego narzędzia. Badanie Stanforda (2025) dowodzi, iż agent AI może skutecznie rywalizować z pentesterem w wykrywaniu podatności. Nie oznacza to jednak zmierzchu ludzkich ekspertów – raczej zmianę ich roli. Kluczem jest adaptacja: wykorzystanie mocnych stron AI, kompensowanie jego słabości i ciągłe doskonalenie obrony. W świecie, gdzie ARTEMIS i jemu podobni polują na nasze systemy, stare zaniedbania (jak niezałatane systemy czy defaultowe hasła) staną się jeszcze bardziej ryzykowne. Czas działać proaktywnie – zanim po drugiej stronie pojawi się szybszy od nas bot, upewnijmy się, iż nie zostawiamy mu łatwej pracy. Bo jak pokazuje praktyka, choćby najlepsza AI najchętniej zaczyna od rzeczy oczywistych – tych, które sami powinniśmy już dawno poprawić. Sprawdź więc jeszcze raz swoje podstawy – choćby te nieszczęsne konta domyślne – zanim zrobi to za Ciebie automat.

Bibliografia