Badanie CTech dotyczące bezpieczeństwa AI: automatyzacja podnosi poprzeczkę dla badaczy

Badanie CTech dotyczące bezpieczeństwa AI wykazało, że automatyzacja obsługuje obecnie znaczną część prac badawczych, lecz ta zmiana podnosi oczekiwania wobec ludzi, którzy ją nadzorują. Badanie z 18 września objęło 30 badaczy bezpieczeństwa z izraelskich firm cyberbezpieczeństwa. Uczestnicy opisali zastosowania AI do analizowania logów, przeglądów dokumentacji, wstępnego skanowania kodu i równoległych dochodzeń.

Ta efektywność wiąże się z wyraźnym odwróceniem sytuacji. Szybsze badania nie sprawiają, że trafny osąd staje się mniej istotny. Dają słabym założeniom, niepełnym instrukcjom i nadmiernym uprawnieniom więcej okazji do wyrządzenia szkód z prędkością maszyn.

Badacze bezpieczeństwa przechodzą więc od ręcznego prowadzenia dochodzeń do orkiestracji, walidacji i odpowiedzialności. Ich nowym przeciwnikiem nie jest po prostu model AI ani zautomatyzowany atakujący. Jest nim automatyzacja pozbawiona wiarygodnego ludzkiego osądu.

Zmiana wykracza poza wyspecjalizowane zespoły badawcze. Przedsiębiorstwa wypełniają swoje środowiska agentami, kontami usługowymi, kluczami interfejsów programowania aplikacji i innymi tożsamościami nieludzkimi. Wiele z nich może odczytywać wrażliwe dane lub wykonywać działania w połączonych systemach.

Tymczasem atakujący mogą wykorzystywać podobną automatyzację do badania podatności i przyspieszania ich wykorzystywania. Obrońcy muszą automatyzować pracę, nie ufając jednak każdemu wygenerowanemu wnioskowi. Muszą również zabezpieczać agentów wykonujących te zadania.

Rezultatem jest wymagający nowy standard dla tego zawodu. Badacze potrzebują technicznej wiedzy, by kwestionować model, dyscypliny operacyjnej, by kontrolować agentów, oraz umiejętności komunikacyjnych, by definiować precyzyjne cele.

Badanie CTech dotyczące bezpieczeństwa AI pokazuje, co się zmieniło

AI przejęła powtarzalne zadania związane z bezpieczeństwem, przesuwając wartość pracy badacza od ręcznego wykonywania zadań ku kierowaniu, weryfikacji i technicznemu osądowi.

Ankieta wśród badaczy bezpieczeństwa zebrała odpowiedzi od 30 specjalistów pracujących w izraelskim sektorze cyberbezpieczeństwa. Nie było to kontrolowane badanie produktywności. Było to uporządkowane spojrzenie na to, jak aktywne zespoły badawcze opisują zmieniającą się pracę.

Każda firma biorąca udział w badaniu wskazała, że AI przejęła zadania takie jak analizowanie logów, przegląd dokumentacji i wstępne skanowanie kodu. Jedna czwarta respondentów wyraźnie opisała tę technologię jako mnożnik siły indywidualnej produktywności.

Yuval Barak, współzałożyciel i inżynier badań w Astelia, przedstawił w badaniu najmocniejsze twierdzenie dotyczące produktywności. Stwierdził, że agenci zwiększyli wydajność każdego badacza do około dziesięciokrotności wcześniejszego poziomu, przejmując żmudną pracę.

Liczba ta odzwierciedla ocenę jednego praktyka, a nie niezależnie zweryfikowany branżowy punkt odniesienia. Mimo to leżąca u podstaw zmiana przepływu pracy pojawiała się konsekwentnie w odpowiedziach.

Badacz musiał wcześniej zbierać logi, przeszukiwać dokumentację, porównywać ścieżki kodu i porządkować potencjalne ustalenia przed przetestowaniem hipotezy. Agent może obecnie wykonywać kilka z tych kroków jednocześnie.

Rola człowieka zaczyna się wcześniej i kończy później. Badacze muszą zdefiniować pytanie, wybrać narzędzia, ograniczyć dostęp, przeanalizować dowody i zdecydować, czy zgłoszona podatność jest rzeczywista.

Roy Itzhaky, badacz bezpieczeństwa w organizacji dyrektora ds. technologii Linx Security, opisał tę rolę jako rolę dyrektora, a nie kopacza. Agent bada kilka ścieżek, podczas gdy badacz utrzymuje ich zgodność z celem i ocenia wyniki.

To rozróżnienie ma znaczenie, ponieważ badań nie mierzy się liczbą tropów wygenerowanych przez system. Wiarygodne ustalenie musi być odtwarzalne, istotne i poparte dowodami.

Zautomatyzowane skanowanie może zwiększyć liczbę hipotez bez poprawy ich jakości. Może też ukrywać niepewność za pewną siebie prozą lub przekonującymi artefaktami technicznymi.

Model może zidentyfikować podejrzany kod i zaproponować wiarygodną ścieżkę ataku. Badacz nadal musi ustalić, czy ścieżka jest osiągalna, czy istniejące mechanizmy kontrolne ją blokują oraz czy wykorzystanie luki ma istotny wpływ.

Ta sama zasada dotyczy pracy z dokumentacją. AI może podsumowywać wcześniejsze dochodzenia i wskazywać powiązane ustalenia. Nie może zagwarantować, że kontekst jest aktualny, kompletny lub ma zastosowanie w nowym środowisku.

Zmienia to sposób, w jaki zespoły zarządzają pamięcią instytucjonalną. Barak argumentował, że wiedza może stać się własnością zespołu, zamiast pozostawać przy poszczególnych badaczach.

Taki rezultat wymaga czegoś więcej niż dodania chatbota do zbioru dokumentów. Zespoły potrzebują uporządkowanych dowodów, decyzji możliwych do prześledzenia oraz kontroli dostępu, która odróżnia zaufane ustalenia od niedokończonych spekulacji.

Przeszukiwalna baza wiedzy może wspierać tę zmianę, gdy zachowuje kontekst źródłowy. Bez pochodzenia informacji szybsze wyszukiwanie może rozpowszechniać stare założenia równie szybko jak prawidłową wiedzę.

Wydarzenie to jest zatem czymś więcej niż prostą historią o produktywności. AI zmienia miejsce, w którym badacze poświęcają wysiłek, oraz miejsca, w których błędy bezpieczeństwa mogą wejść do procesu.

Powtarzalna praca maleje. Rośnie obciążenie związane z określaniem, nadzorowaniem i walidowaniem pracy zautomatyzowanej.

Szybsze badania wywierają presję na zespoły bezpieczeństwa

Wzrost produktywności tworzy nowy poziom bazowy, zmuszając badaczy do szybszego dostarczania zweryfikowanych wyników, podczas gdy atakujący zyskują dostęp do podobnej automatyzacji.

Zespoły bezpieczeństwa odczuwają presję z obu stron przepływu pracy. Ich własne organizacje oczekują większej wydajności, a przeciwnicy mogą wykorzystywać AI do skracania rozpoznania i eksperymentowania.

Badanie CTech dotyczące bezpieczeństwa AI pokazuje, jak szybko dostosowały się wewnętrzne oczekiwania. Jeśli agent może w kilka minut przejrzeć dokumentację lub przeskanować kod, długą ręczną kolejkę trudniej uzasadnić.

Ofri Ziv, współzałożyciel i wiceprezes ds. badań w Tenzai, powiedział, że praca, która wcześniej pozostawała w badaniach przez miesiące, musi być teraz oceniona, wzmocniona i dostarczona w ciągu kilku tygodni. Ta zmiana bezpośrednio łączy wyniki badań z dostarczaniem produktu.

Szybsze dostarczanie może poprawić obronę, gdy zespoły zachowują walidację. Może też zachęcać do przedwczesnych ustaleń, szumnych alertów lub niewystarczająco przetestowanych mechanizmów kontrolnych.

Presja jest szczególnie widoczna w zarządzaniu podatnościami. Organizacje muszą znajdować możliwe do wykorzystania słabości, nadawać im priorytety, opracowywać poprawki i weryfikować je w zmieniających się środowiskach.

Zespół Mandiant firmy Google opisał podobny model operacyjny. Jego agentowy framework przeglądu łączy wielu agentów ze strukturyzowaną walidacją i wiedzą ekspertów.

Framework ma pomagać ekspertom analizować kod źródłowy, znajdować ścieżki wykorzystania luk i testować potencjalne podatności. Jego struktura jest istotna, ponieważ nieograniczone badanie przez model może marnować czas lub prowadzić do niepopartych dowodami wniosków.

Sama szybkość nie rozwiązuje tradycyjnej przewagi atakującego. Atakujący potrzebuje jednej działającej ścieżki, podczas gdy obrońca musi ograniczać ekspozycję w wielu zasobach, tożsamościach i aplikacjach.

AI może pomóc obrońcom zrównoleglić tę pracę. Pomaga też atakującym automatyzować wyszukiwanie, adaptować publicznie dostępne techniki i częściej analizować wystawione systemy.

Google Cloud poinformował, że odstęp między ujawnieniem podatności a jej aktywnym wykorzystaniem skrócił się z tygodni do dni w drugiej połowie 2025 roku. Ta obserwacja wspiera argument za ciągłym wykrywaniem i szybszą walidacją zabezpieczeń.

Nie dowodzi jednak, że AI spowodowała każde skrócenie okna wykorzystania. Pokazuje natomiast, dlaczego okresowa praca nad bezpieczeństwem staje się mniej zgodna z obecnymi warunkami operacyjnymi.

Test penetracyjny przeprowadzany dwa razy w roku przedstawia tymczasowy obraz środowiska. Nowy kod, uprawnienia, usługi i integracje mogą sprawić, że ten obraz stanie się nieaktualny wkrótce po jego dostarczeniu.

Cztery firmy uczestniczące w badaniu CTech wskazały, że stworzyły własnych hakerów AI lub wewnętrzne środowiska szkoleniowe. Systemy te stale symulują ataki i testują, jak słabości mogłyby ujawnić się w środowisku produkcyjnym.

Uczestnicy badania opisali dla tych programów standard zerowej liczby fałszywych pozytywów. Jest to aspiracja wymagająca dowodów, a nie ogólna właściwość narzędzi bezpieczeństwa AI.

Fałszywe pozytywy nadal generują realne koszty. Zużywają czas dochodzeń, przerywają pracę zespołów inżynieryjnych i mogą przyzwyczajać użytkowników do ignorowania przyszłych ostrzeżeń.

Fałszywe negatywy są bardziej niebezpieczne. Agent może przeoczyć nową technikę, ponieważ jego dane treningowe lub dostępne narzędzia nie odzwierciedlają danego ataku.

Liderzy bezpieczeństwa muszą więc oceniać automatyzację poprzez zweryfikowane wyniki. Przydatne miary obejmują odtwarzalne ustalenia, pokrycie wykrywania, czas usuwania problemów oraz odsetek odrzuconych wniosków agentów.

Wymuszona odpowiedź badacza jest jasna. Zespoły muszą automatyzować powtarzalne wykrywanie, jednocześnie inwestując znacznie więcej w przegląd, testowanie i zarządzanie dowodami.

Ta presja prawdopodobnie się utrzyma. Gdy organizacja zintegruje automatyzację ze swoim procesem badawczym, powrót do wolniejszej ręcznej przepustowości staje się trudny.

Trudniejsze pytanie brzmi, czy zespoły mogą skalować osąd w tym samym tempie co generowaną produkcję. To pytanie definiuje centralny konflikt, przed którym stoją obecnie badania bezpieczeństwa.

Badacze bezpieczeństwa AI stają się dyrektorami, a nie kopaczami

Głównym wyzwaniem tego zawodu jest ludzki osąd wobec nienadzorowanej automatyzacji, a nie ludzka szybkość wobec szybkości maszyn.

Badacze bezpieczeństwa AI nie tworzą już wartości przez osobiste wykonywanie każdego kroku dochodzenia. Ich wartość coraz bardziej zależy od decydowania, które kroki należy uruchomić, pod jakimi ograniczeniami i przy jakich wymaganiach dotyczących dowodów.

Ta rola przypomina kierownictwo techniczne. Badacz może przydzielić osobnych agentów do przeglądu kodu źródłowego, przeszukiwania dokumentacji, analizowania logów lub testowania konkurencyjnych hipotez.

Praca równoległa rozszerza przestrzeń poszukiwań. Tworzy też problemy koordynacyjne, których pojedyncze ręczne dochodzenie mogłoby uniknąć.

Agenci mogą powtarzać to samo błędne założenie w kilku gałęziach. Mogą tracić istotny kontekst, podążać za atrakcyjnymi, lecz nieproduktywnymi teoriami albo generować sprzeczne wnioski.

Itzhaky podsumował zagrożenie trafnym kontrastem. Niedbałe myślenie kiedyś pochłaniało całe popołudnie, lecz teraz może wysłać flotę agentów w złym kierunku.

To stwierdzenie oddaje centralne odwrócenie sytuacji. Automatyzacja obniża koszt działania, lecz może zwielokrotnić koszt źle zdefiniowanego celu.

Ludzki dyrektor musi przełożyć cel dochodzenia na ograniczone zadania. Każde zadanie potrzebuje celu, dozwolonych narzędzi, warunków zakończenia oraz standardu wystarczających dowodów.

Badacz musi również zdecydować, jak niezależni powinni pozostać agenci. Kilku agentów powtarzających ten sam schemat rozumowania nie zapewnia istotnego potwierdzenia.

Lepszy projekt rozdziela role. Jeden agent może generować hipotezy, drugi kwestionować założenia, a kontrolowane narzędzie może odtworzyć podejrzewane zachowanie.

Nawet ten proces wymaga ludzkiego przeglądu. Modele dzielą wzorce treningowe, a pozorna niezgoda nie gwarantuje niezależnego rozumowania.

Ofek Haviv, badacz cyberbezpieczeństwa w Terra Security, argumentował, że badacze nie konkurują z agentami pod względem szybkości. Ich wartość polega na ustalaniu standardu, który muszą spełniać wyniki agentów.

Standard ten obejmuje prawdę techniczną, ale także znaczenie organizacyjne. Teoretyczna słabość może mieć niewielki wpływ, gdy mechanizmy kontrolne sprawiają, że podatna ścieżka jest nieosiągalna.

Z kolei drobny błąd konfiguracji może stworzyć poważną lukę, gdy agent posiada szerokie uprawnienia. Kontekst decyduje o tym, czy dane ustalenie wymaga pilnej reakcji.

Badacze muszą również rozumieć narzędzia stojące za generowanymi odpowiedziami. Osoba analizująca kod po inżynierii wstecznej musi rozpoznać, kiedy model zmyśla zachowanie lub błędnie interpretuje przepływ sterowania.

Idan Revivo, szef badań nad bezpieczeństwem w Island, ostrzegł przed nowicjuszami, którzy potrafią wydawać polecenia modelom, lecz nigdy nie nauczyli się inżynierii wstecznej oprogramowania. Jego obawa nie wynika ze sprzeciwu wobec automatyzacji.

To ostrzeżenie dotyczące zdolności do weryfikacji. Gdy model z pełną pewnością się myli, ktoś musi mieć wystarczającą głębię techniczną, by to zakwestionować.

Wymóg ten podnosi poprzeczkę dla początkujących badaczy. Praca na poziomie juniorskim tradycyjnie dawała wielokrotny kontakt z logami, kodem, systemami i typowymi trybami awarii.

Jeśli agenci przejmą te zadania, nowi badacze mogą mieć mniej okazji do budowania intuicji. Zespoły muszą świadomie zastąpić utraconą praktykę nadzorowanymi laboratoriami, ćwiczeniami odtwarzania i przeglądem adwersarialnym.

Badanie wykazało, że jedna piąta respondentów wspomniała o wpływie AI na kolejne pokolenie badaczy. Roey Vilnai, dyrektor ds. badań cybernetycznych w Axonius, powiedział, że dostęp do wiedzy podniósł oczekiwania na wszystkich poziomach doświadczenia.

Tamir Ishay Sharbat, dyrektor ds. badań nad bezpieczeństwem w Zenity, przedstawił uzupełniającą perspektywę. Wszedł do branży cyberbezpieczeństwa bez wcześniejszego doświadczenia i obecnie uważa korzystanie z AI za wymóg dla badaczy.

Łącznie te perspektywy ujawniają wyzwanie szkoleniowe. AI może poszerzać dostęp do wiedzy, jednocześnie ułatwiając pomylenie powierzchownych kompetencji z ekspercką wiedzą.

Procesy rekrutacyjne będą musiały sprawdzać zarówno korzystanie z narzędzi, jak i samodzielne rozumowanie. Kandydat powinien potrafić kierować agentem, oceniać jego dowody i kontynuować pracę, gdy model zawodzi.

Zespoły powinny też zachować ćwiczenia manualne dla kluczowych umiejętności. Inżynieria wsteczna, rozwój exploitów, analiza tożsamości i rozumowanie sieciowe nie mogą pozostać wyłącznie wiedzą teoretyczną.

Najlepsi badacze połączą eksplorację w skali maszynowej z ugruntowanym technicznym sceptycyzmem. Będą wiedzieć, kiedy automatyzować, kiedy zawęzić zakres i kiedy zatrzymać system.

To połączenie, a nie sama biegłość w formułowaniu promptów, staje się nowym standardem zawodu.

Tożsamości Nieosobowe Poszerzają Powierzchnię Ataku

Agenci wykonujący pracę związaną z bezpieczeństwem sami stają się uprzywilejowanymi tożsamościami, które organizacje muszą wykrywać, ograniczać, monitorować i unieważniać.

Jedenaście firm uczestniczących w badaniu CTech wskazało agentów AI jako istotną zmianę granic bezpieczeństwa. Respondenci zaliczyli tych agentów do jednej grupy z kluczami API, kontami usługowymi i innymi tożsamościami nieosobowymi.

Tomer Bar, zastępca wiceprezesa ds. badań nad bezpieczeństwem w Semperis, powiedział, że w niektórych organizacjach klientów tożsamości nieosobowe już przewyższają liczebnie ludzi. Przewidział, że w nadchodzących latach stosunek ten może osiągnąć dziesięć do jednego.

Ta prognoza jest przewidywaniem przedstawiciela firmy, a nie niezależnie zweryfikowanym pomiarem rynku. Leżący u podstaw problem tożsamości jest jednak konkretny.

Agent potrzebuje dostępu do danych, aplikacji i narzędzi, aby wykonywać użyteczną pracę. Te połączenia nadają mu tożsamość, zestaw uprawnień lub pożyczony dostęp za pośrednictwem innego konta.

Omer Nissim, badacz bezpieczeństwa w Sweet Security, zwrócił uwagę na niebezpieczeństwo łączenia szerokich uprawnień z nieprzewidywalnym procesem podejmowania decyzji. Wskazał konkretnie na agentów połączonych za pośrednictwem serwerów Model Context Protocol.

Model Context Protocol, czyli MCP, jest standardem umożliwiającym systemom AI łączenie się z zewnętrznymi narzędziami i źródłami danych. Jego użyteczność zależy od sposobu autoryzacji i ograniczania tych połączeń.

Agent mający dostęp do odczytu kodu źródłowego stwarza jeden poziom ryzyka. Agent, który może zmieniać ustawienia chmury, wysyłać wiadomości lub wdrażać kod, stwarza inny.

OWASP opisuje nadmierną sprawczość jako stan obejmujący nadmierną funkcjonalność, uprawnienia lub autonomię. Nieoczekiwane albo zmanipulowane wyniki modelu mogą wówczas uruchomić szkodliwe działania.

Źródłem problemu nie musi być złośliwy zamiar. Niejednoznaczna instrukcja, halucynowana konkluzja, przejęte narzędzie lub wstrzyknięty prompt mogą przekierować skądinąd legalnie działającego agenta.

Zasada najmniejszych uprawnień pozostaje podstawową ochroną. Agent powinien otrzymywać tylko narzędzia i uprawnienia potrzebne do bieżącego zadania.

Dostęp tylko do odczytu jest preferowany, gdy praca nie wymaga zmian. Działania o dużym wpływie powinny korzystać z oddzielnych ścieżek zatwierdzania i poświadczeń o wąskim zakresie.

Organizacje potrzebują też indywidualnych tożsamości agentów. Współdzielenie ludzkiego poświadczenia z agentem utrudnia przypisanie działań i może pozwolić systemowi podszywać się pod jego operatora.

Niedawne wytyczne NIST dotyczące tożsamości agentów zalecają traktowanie agentów jako odrębnych podmiotów. Każdy z nich powinien mieć identyfikatory, poświadczenia i uprawnienia powiązane z odpowiedzialnym użytkownikiem lub systemem.

Wytyczne podkreślają również ryzyko związane ze statycznymi kluczami API i długotrwałymi tokenami bearer. Każdy, kto zdobędzie takie poświadczenia, często może ich użyć bez potwierdzenia posiadania konkretnej tożsamości.

To sprawia, że przechowywanie i rotacja poświadczeń stają się elementem bezpieczeństwa AI. Sekrety agentów mogą wyciekać przez pliki konfiguracji, logi, magazyny pamięci, wyniki narzędzi lub zapisy debugowania.

Zatwierdzenie przez człowieka nie rozwiązuje każdego problemu. Ciągłe prośby o uprawnienia mogą powodować zmęczenie zgodami i skłaniać użytkowników do zatwierdzania działań bez uważnej oceny.

Silniejszy projekt wyznacza agentom zatwierdzone granice działania. Granice te powinny definiować dostępne zasoby, dozwolone działania, limity czasu i warunki eskalacji.

Monitorowanie musi obejmować więcej niż końcową odpowiedź. Zespoły bezpieczeństwa potrzebują zapisów wywołań narzędzi, użycia tożsamości, pobranych danych, zmienionych zasobów i decyzji zatwierdzających.

Te dowody wspierają badanie incydentów i codzienną kontrolę jakości. Pozwalają badaczom odtworzyć, dlaczego agent doszedł do określonego wniosku lub wykonał dane działanie.

Własność musi również pozostawać widoczna. Itzhaky zauważył, że agenci mogą być tworzeni przez pracowników, zautomatyzowane potoki lub innych agentów.

Bez właściciela ponoszącego odpowiedzialność zapomniany agent może zachować uprawnienia po zakończeniu pierwotnego zadania. Ten wzorzec przypomina porzucone konta usługowe, lecz autonomiczne zachowanie sprawia, że ekspozycję trudniej przewidzieć.

Wykrywanie powinno zatem obejmować inwentaryzacje agentów, poświadczenia, narzędzia, dostęp do danych i relacje nadrzędny-podrzędny. Unieważnienie musi zakończyć działanie zarówno agenta, jak i wszelkiego delegowanego dostępu, który utworzył.

W tym miejscu historia produktywności spotyka się z historią bezpieczeństwa. Organizacja może wdrażać agentów szybciej, niż jej program zarządzania tożsamością jest w stanie nimi zarządzać.

Powstała luka staje się nowym celem badań. Zespoły bezpieczeństwa muszą badać zachowanie agentów, jednocześnie używając agentów do badania wszystkiego innego.

Automatyzacja Nie Może Zastąpić Sceptycznej Walidacji

Badanie ukazuje rzeczywistą zmianę w przepływach pracy, lecz jego najsilniejsze twierdzenia dotyczące produktywności i dokładności nadal wymagają niezależnego pomiaru.

Badanie bezpieczeństwa AI przeprowadzone przez CTech oferuje cenne obserwacje z pierwszej ręki od pracujących badaczy. Jego 30-osobowa grupa pozostaje skoncentrowana w izraelskiej branży cyberbezpieczeństwa.

Opublikowany artykuł nie przedstawia losowej próby, ustandaryzowanego kwestionariusza ani niezależnie audytowanych danych dotyczących wydajności. Czytelnicy nie powinni traktować jego proporcji jako uniwersalnych miar rynku pracy.

Dziesięciokrotne oszacowanie produktywności przez respondenta może sygnalizować znaczącą zmianę, nie dowodząc dziesięciokrotnego wzrostu liczby zweryfikowanych odkryć. Wynik może oznaczać raporty, hipotezy, przeglądy kodu, eksperymenty lub potwierdzone podatności.

Te kategorie mają różną wartość. Dziesięć razy więcej wstępnych ustaleń może tworzyć więcej pracy, jeśli większości nie da się odtworzyć.

Ta sama ostrożność dotyczy twierdzeń o zerowej liczbie fałszywych pozytywów. System może ograniczać fałszywe alarmy, zawężając zakres raportowanych informacji, ale taki wybór może zwiększać liczbę pominiętych podatności.

Zespoły muszą mierzyć obie strony. Precyzja opisuje, ile zgłoszonych ustaleń jest prawidłowych, podczas gdy czułość opisuje, ile istotnych słabości system faktycznie wykrywa.

Narzędzie może sprawiać wrażenie dokładnego, gdy raportuje wyłącznie oczywiste problemy. Nadal może pomijać subtelne łańcuchy ataku, nieznane oprogramowanie lub podatności wymagające długiego rozumowania kontekstowego.

Wskazówki Google Cloud dotyczące podatności ostrzegają, że agenci mogą po cichu przeoczać nowe techniki lub podatności zero-day słabo reprezentowane w danych treningowych.

To ograniczenie nadaje ludzkiej wiedzy eksperckiej konkretną rolę. Badacze muszą rozpoznawać, kiedy zakres skanowania jest zbyt wąski, i projektować testy wykraczające poza znane modelowi wzorce.

Halucynacje są kolejnym problemem. Wygenerowany raport może odwoływać się do nieistniejących funkcji, błędnie rozumieć zależność lub wnioskować o możliwości wykorzystania z niepełnego kodu.

Odtwarzanie powinno więc odbywać się w kontrolowanych środowiskach. Wiarygodny potok powinien zachowywać dane wejściowe, wersje narzędzi, prompty, stan systemu i obserwowalne wyniki.

Wyniki agentów również wymagają modelowania zagrożeń. Atakujący może umieścić tekst manipulujący modelem, zwłaszcza gdy system odczytuje niezaufane strony internetowe, repozytoria, zgłoszenia lub dokumenty.

Atak ten nazywa się pośrednim wstrzyknięciem promptu. Złośliwe instrukcje są ukryte w pobranej treści i próbują przekierować zachowanie agenta.

Obrona nie może całkowicie polegać na nakazywaniu modelowi ignorowania złych instrukcji. Systemy potrzebują odizolowanych narzędzi, uprawnień o ograniczonym zakresie, granic treści i wyraźnego zatwierdzania działań o istotnych konsekwencjach.

Badacze muszą też odróżniać pewność modelu od jakości dowodów. Płynne wyjaśnienia mogą sprawić, że słabe ustalenie będzie wyglądało na kompletne.

Silny proces przeglądu zadaje kilka konkretnych pytań. Czy zachowanie można odtworzyć? Czy podatna ścieżka jest osiągalna? Jakich uprawnień wymaga wykorzystanie? Która kontrola je blokuje lub wykrywa?

Proces powinien również rejestrować odrzucone hipotezy. Te niepowodzenia pomagają zespołom ulepszać benchmarki i zapobiegają powtarzaniu przez późniejszych agentów tej samej nieproduktywnej ścieżki.

Benchmark bezpieczeństwa to zdefiniowany zbiór zadań używany do testowania zachowania systemu. Wewnętrzne benchmarki powinny obejmować mylące dowody, częściowy dostęp, awarie narzędzi i nieznane klasy podatności.

Wydajność produkcyjna ma większe znaczenie niż wyniki benchmarków. Zespoły powinny porównywać ustalenia agentów z późniejszymi incydentami, ręcznymi przeglądami i niezależnymi testami.

Ludzcy recenzenci potrzebują ochrony przed uprzedzeniem automatyzacyjnym, czyli tendencją do faworyzowania rekomendacji maszyny wyłącznie dlatego, że została wygenerowana przez system.

Rotacja recenzentów, ukrywanie wyniku pewności agenta lub wymaganie niezależnego odtworzenia może ograniczyć to uprzedzenie. Ustalenia o dużym wpływie zasługują na silniejsze rozdzielenie wykrywania od zatwierdzania.

Stanowisko sceptyka nie oznacza, że zespoły powinny porzucić AI. Badania manualne również pomijają podatności, podążają za błędnymi hipotezami i cierpią z powodu niespójnej dokumentacji.

Bardziej uzasadniony wniosek jest węższy. AI zwiększa zdolności badawcze, lecz ta zdolność staje się użyteczna tylko wtedy, gdy zespoły utrzymują zdyscyplinowaną walidację.

Nowa wyższa poprzeczka nie oznacza perfekcji. Jest nią zdolność wyjaśnienia, co zrobił agent, zweryfikowania wyniku i ograniczenia konsekwencji błędu.

Ciągłe Bezpieczeństwo Staje Się Kolejnym Testem

Kolejna faza będzie oceniana przez ciągłą walidację, mierzalną jakość badań i egzekwowalną kontrolę nad tożsamościami agentów.

Pierwszym sygnałem, który należy obserwować, jest to, czy ciągła ocena bezpieczeństwa zastąpi okresowe testowanie w przepływach pracy produkcyjnej. Kilku respondentów badania argumentowało, że testy penetracyjne przeprowadzane dwa razy w roku nie odpowiadają już tempu rozwoju oprogramowania i aktywności atakujących.

Ciągła ocena oznacza testowanie zasobów w miarę zmian w kodzie, konfiguracjach, tożsamościach i ekspozycji na zagrożenia zewnętrzne. Powinna uzupełniać pogłębione przeglądy prowadzone przez ludzi, a nie zamieniać bezpieczeństwa w niekończący się strumień alertów ze skanerów.

Google opisał agentowy pipeline bezpieczeństwa, który skanuje kod, tworzy dowody i opracowuje poprawki. Firma podała, że stosuje to podejście w odniesieniu do setek milionów wierszy wewnętrznego kodu.

System ten stanowi użyteczny wskaźnik, ponieważ łączy wykrywanie z odtwarzaniem problemów i ich usuwaniem. Kluczową miarą jest to, czy inne organizacje mogą osiągnąć podobną dyscyplinę przy mniejszych zbiorach danych, zespołach i infrastrukturze.

Szerokie wdrożenie wzmocniłoby główną tezę badania. Utrzymujący się szum alertów lub niski wskaźnik skutecznego usuwania problemów osłabiłyby ją.

Drugim sygnałem jest sposób, w jaki firmy zarządzają tożsamościami nieludzkimi. Inwentaryzacje agentów powinny stać się częścią zarządzania tożsamością i dostępem, a nie odrębnym dokumentem polityki AI.

Przydatny postęp obejmowałby unikalne poświadczenia agentów, krótkotrwały dostęp, delegowane uprawnienia, jasno określoną odpowiedzialność oraz kompletne dzienniki działań. Organizacje powinny także móc zawiesić agenta bez wyłączania jego ludzkiego operatora.

Warto obserwować standardy i produkty, które łączą działania agenta z konkretnym użytkownikiem, zadaniem i zatwierdzonym zakresem działania. Taki łańcuch wspiera rozliczalność bez udostępniania osobistych poświadczeń.

Jeśli wdrożenia nadal będą opierać się na szerokich kluczach API i ogólnych kontach usługowych, produktywność wyprzedzi nadzór. Taki rezultat wzmocni obawy dotyczące ukrytych administratorów i nieprzewidywalnych ścieżek dostępu.

Trzecim sygnałem jest to, jak zmienią się rekrutacja i szkolenia. Młodsi badacze nadal potrzebują bezpośredniej praktyki w pracy z kodem, systemami, eksploatacją luk i dowodami.

Zespoły powinny publikować bardziej przejrzyste oczekiwania kompetencyjne wobec ról wspieranych przez AI. Rozmowy rekrutacyjne i programy szkoleniowe mogą sprawdzać, czy kandydaci wykrywają sfabrykowane ustalenia, kwestionują założenia modeli i potrafią ręcznie odtworzyć wyniki.

Zdrowa transformacja stworzy ustrukturyzowane ścieżki praktyki wokół nadzoru nad agentami. Doświadczeni badacze mogą pokazywać osobom szkolącym się zarówno udane przebiegi, jak i porażki.

Niezdrowa transformacja usunie pracę podstawową, nie zastępując jej wartością edukacyjną. Doprowadziłoby to do powstania badaczy, którzy potrafią obsługiwać interfejsy, lecz nie są w stanie zweryfikować systemów stojących za nimi.

Sygnały te są ważne dla nabywców korporacyjnych w takim samym stopniu jak dla specjalistów ds. bezpieczeństwa. Wykorzystanie AI przez dostawcę niewiele mówi bez szczegółów dotyczących uprawnień, dowodów, przeglądu i obsługi awarii.

Nabywcy powinni pytać, kto zatwierdza ustalenia, jak agenci się uwierzytelniają, jakie dane przechowują oraz czy wyniki można odtworzyć. Powinni również pytać, jak system zachowuje się, gdy narzędzie zawiedzie lub dane wejściowe zawierają złośliwe instrukcje.

Deweloperzy powinni oczekiwać, że przeglądy bezpieczeństwa zbliżą się do każdej zmiany w kodzie. Mogą otrzymywać szybszą informację zwrotną, ale automatyczne ustalenia nadal będą potrzebować wystarczającego kontekstu, aby umożliwić wprowadzenie poprawki.

Pracownicy umysłowi powinni się tym interesować, ponieważ problemy z tożsamością agentów wykraczają poza narzędzia cyberbezpieczeństwa. Każdy asystent połączony z pocztą e-mail, dokumentami, kodem lub systemami biznesowymi może stać się nieludzką tożsamością o nadmiernych uprawnieniach.

Badanie CTech dotyczące bezpieczeństwa AI ostatecznie opisuje redystrybucję pracy, a nie zniknięcie badaczy. Maszyny wykonują więcej działań związanych ze zbieraniem danych i eksploracją. Ludzie ponoszą większą odpowiedzialność za cele, ograniczenia i prawdziwość ustaleń.

Taki układ może poprawić bezpieczeństwo, gdy dowody pozostają najważniejsze. Może zwiększać ryzyko, gdy organizacje mylą wygenerowaną aktywność ze zweryfikowanym postępem.

Praktyczne pytanie nie brzmi już, czy AI ma miejsce w badaniach nad bezpieczeństwem. Brzmi ono: czy zespoły potrafią zapewnić rozliczalność automatyzacji, zanim jej skala przekroczy ich zdolność do nadzorowania jej.

Poproś dostawców rozwiązań bezpieczeństwa i wewnętrzne zespoły o jedno kompletne ustalenie wspomagane przez agenta, obejmujące jego uprawnienia, ścieżkę dowodową, przegląd dokonany przez człowieka i ostateczne rozstrzygnięcie. Taki zapis ujawni więcej niż ogólna obietnica produktywności.