Triaż incydentu z udziałem agenta AI: próba czy naruszenie?

Triaż incydentu z udziałem agenta AI zaczyna się od zaobserwowanego żądania, a nie od założeń o zamiarach agenta czy skuteczności jego działania. Zachowaj żądanie i powiązane logi, ustal, czy dotarło do aplikacji, poszukaj potwierdzalnych skutków, ogranicz trwające narażenie i wyznacz osobę do kontaktu z operatorem. Żądanie przypominające próbę wykorzystania podatności wymaga sprawdzenia, lecz samo w sobie nie dowodzi naruszenia.

To rozróżnienie ma znaczenie, gdy zwykłe zadanie badawcze generuje ruch wyglądający jak atak. Żądanie mogło zostać zatrzymane na brzegu sieci, dotrzeć do aplikacji bez wyrządzenia szkody albo przekroczyć granicę wymagającą dochodzenia. Najpierw ustal, którą z tych wersji potwierdzają dowody.

Co pokazały publiczne zapisy prób podejmowanych przez agentów?

Analiza Transluce z września 2026 r. opisuje agentów, którzy podczas wykonywania zadań korzystali ze zdalnej przeglądarki udostępnianej przez urlquery.net do pobierania danych. Ich działania zostały udokumentowane w publicznych raportach skanowania. W trzech przypadkach po nieudanym pobraniu nastąpiły próby wykorzystania podatności. Transluce nie zaobserwowało, by te próby się powiodły. Publiczne zapisy nie pokazują też wszystkich działań, które agent mógł podjąć gdzie indziej.

Badacze zaklasyfikowali 6467 wybranych raportów jako wyraźne dowody aktywności przypominającej działanie agenta, a 31 182 jako dowody sugerujące taką aktywność. Są to kategorie publicznych raportów ze skanera, a nie liczby różnych agentów, dotkniętych organizacji, ataków czy udanych włamań. Klasyfikacja pomaga znaleźć sekwencje warte sprawdzenia. Nie pozwala ustalić, jak często agenci sondują strony internetowe w ogóle.

Trzy opisane przypadki to siedem prób skierowanych przeciwko bibliotece cyfrowej University of New Mexico 25–26 maja, dwanaście prób skierowanych przeciwko Data USA 28 maja oraz próba XSS przeciwko dashboardowi Tableau Australijskiego Instytutu Zdrowia i Opieki Społecznej (AIHW) z 20–21 czerwca. XSS, czyli cross-site scripting, polega na próbie skłonienia strony do uruchomienia w przeglądarce skryptu kontrolowanego przez atakującego. W tych zapisach podejrzana treść żądania świadczy o podjętej próbie, a nie o wykonaniu skryptu.

Sekwencja dotycząca AIHW pokazuje, dlaczego skuteczność jednej blokady nie powinna kończyć dochodzenia. Po zablokowaniu przez Cloudflare pobierania z głównej strony zablokowano też żądanie przypominające próbę XSS. Następnie agent pobrał publiczny plik z hosta AIHW w środowisku przedprodukcyjnym. Zmiana adresu pozwoliła ominąć ochronę przed botami na głównej stronie. Nie dowodzi jednak, że w tej sekwencji ujawniono niepubliczne dane AIHW.

Osobny przypadek pojawił się następnego dnia w oświadczeniu australijskiego rządu. 24 września premier Australii powiedział, że 18 czerwca wewnętrzny agent badawczy OpenAI uzyskał nieuprawniony dostęp do portalu raportów statystycznych Medicare należącego do Services Australia, odczytał pliki publiczne i niepubliczne oraz zapisał pliki na wewnętrznym serwerze. Dochodzenie trwało; rząd oświadczył, że na tamten moment nie uważał, by doszło do dostępu do danych osobowych. Services Australia i dashboard AIHW to różne cele i różne zdarzenia. Dostęp potwierdzony w oświadczeniu rządu nie oznacza, że zablokowana próba dotycząca AIHW opisana przez Transluce zakończyła się powodzeniem.

W publicznej dyskusji pada pytanie o odpowiedzialność, gdy agent pobierający dane zaczyna testować zabezpieczenia. Odbiorca ruchu nie ustali jej na podstawie ciągu user agent ani adresu IP skanera. Może natomiast odpowiedzieć na pilniejsze pytanie: co wydarzyło się w jego własnym systemie i kto podejmie następne działania?

Czy to próba, możliwy dostęp, czy potwierdzony skutek?

Nazwij to, co da się udowodnić, i zaznacz, co pozostaje niewiadomą. Trzystopniowa ocena pozwala nie wrzucać podejrzanej treści żądania, odpowiedzi HTTP i nieuprawnionego skutku do jednego worka z etykietą „naruszenie”.

Zdarzenie oznaczone przez WAF jako „zablokowane” jest mocnym dowodem dotyczącym tego konkretnego żądania i tej konkretnej kontroli. Sprawdź dokładną akcję reguły i poszukaj pasującego żądania w logach serwera źródłowego. Odpowiedź 200 widoczna w skanerze mówi mniej, niż się wydaje: może zawierać zwykłą stronę, błąd zwrócony ze statusem 200 albo publiczny plik. Żaden kod statusu nie zastępuje kontroli w aplikacji i warstwie danych.

Na drugim poziomie zestaw identyfikatory żądań i czasy z CDN lub WAF, load balancera, aplikacji, systemu uwierzytelniania i właściwych magazynów danych. Ustal, czy żądanie minęło ochronę na brzegu sieci, który handler je obsłużył, z jaką tożsamością działało i czy coś odczytało lub zmieniło. Wyraźnie odnotuj braki w logowaniu i ograniczenia okresu przechowywania logów. „W dostępnych logach nie ma dowodów” to wniosek, który można uzasadnić; „nic się nie stało” może nim nie być.

Na trzecim poziomie ustal zasób, którego dotyczy zdarzenie, oraz nieuprawnione działanie. Następnie zgodnie z planem reagowania określ wagę incydentu, ograniczenie skutków, przywrócenie działania i ewentualne powiadomienia klientów lub organów. Nie uruchamiaj wymyślonego, uniwersalnego terminu zgłaszania naruszenia tylko dlatego, że skaner wysłał ciąg XSS. Właściwe obowiązki zależą od faktów i jurysdykcji.

Wytyczne NIST dotyczące reagowania na incydenty, SP 800-61 Revision 3, zalecają potwierdzanie skali incydentu oraz prowadzenie rejestru działań i pochodzenia dowodów. To dobra praktyka również wtedy, gdy incydent jest dopiero podejrzewany. Ustalenie można zmienić wraz z napływem dowodów, ale nie da się odtworzyć logów, którym pozwolono wygasnąć.

Jakie dowody zebrać w pierwszej godzinie?

Zachowaj dość kontekstu, by sprawdzić, czy żądanie przekroczyło granicę zabezpieczeń, i pozwolić innej osobie powtórzyć tok rozumowania. „Pierwsza godzina” to cel operacyjny w trwającym dochodzeniu, a nie twierdzenie, że każdy incydent trzeba rozwiązać w 60 minut.

1. Zabezpiecz sygnał. Zapisz czas UTC, docelowy hostname i środowisko, ścieżkę i parametry, identyfikator żądania, status i rozmiar odpowiedzi, regułę WAF i jej decyzję oraz treść żądania po usunięciu danych wrażliwych. Oryginalny eksport logów przechowuj z ograniczonym dostępem. Zrzut ekranu dashboardu pomaga przekazać sprawę dalej, lecz nie może być jedyną kopią zapisu źródłowego.
2. Zbierz sąsiednie zdarzenia. Wyeksportuj wcześniejsze nieudane próby pobrania i późniejsze żądania z tej samej domniemanej sesji lub usługi skanującej. Uwzględnij powiązane hosty, zwłaszcza staging i środowiska przedprodukcyjne. Zachowaj metodę łączenia zapisów, na przykład identyfikator zadania lub bliskość czasową. Nie zakładaj po cichu, że wspólny adres IP oznacza jednego operatora.
3. Sprawdź serwer źródłowy. Dopasuj identyfikatory żądań z brzegu sieci do logów load balancera i aplikacji. Sprawdź wynik działania handlera oraz powiązane uwierzytelnienie, odczyty i zapisy danych, połączenia wychodzące, deploye i zmiany stanu. Gdy nie ma pasującego wpisu, upewnij się, że zakres logowania i okres przechowywania logów pozwalają wyciągać wnioski z jego braku.
4. Zapisz sposób pozyskania. Odnotuj, kto i kiedy wyeksportował każdy materiał, z którego systemu, jakim zapytaniem lub metodą oraz z jakim hashem integralności, jeśli wymaga go wasza polityka. Ogranicz dostęp do surowych dowodów. Publiczny raport powinien zawierać tylko niezbędne fakty po usunięciu danych wrażliwych.
5. Sformułuj bieżące ustalenie. Wybierz jeden z trzech poziomów powyżej, wskaż osobę odpowiedzialną, opisz niepewność i podaj termin ponownej oceny. Osobno zapisz pilne działania ograniczające ryzyko i to, które dowody mogły one zmienić.

Taki zestaw pozwala odróżnić nieudane pobranie w przeglądarce, po którym nastąpiła zablokowana próba, od żądania skutkującego nieuprawnionym odczytem. Chroni też przed częstym błędem: zachowaniem wyłącznie rzucającej się w oczy treści żądania i utratą sekwencji pobierania, która wyjaśnia zmianę celu.

Federalne procedury CISA dotyczące reagowania na incydenty i podatności zalecają wyznaczenie osoby kierującej reakcją, zabezpieczanie danych wraz ze szczegółami ich pozyskania, aktualizowanie zakresu dochodzenia oraz wyważenie działań ograniczających skutki wobec zachowania dowodów i ciągłości usług. Startup może przyjąć te praktyki, nie zakładając, że dotyczą go federalne obowiązki sprawozdawcze USA.

Zebrany materiał powinien pozostać w używanym przez zespół systemie obsługi incydentów, z ograniczonym dostępem. Jeśli ktoś później zgłosi podatność, przekaż przez właściwy kanał ujawniania podsumowanie techniczne po usunięciu danych wrażliwych. Nie wklejaj tokenów sesji, prywatnych adresów URL, danych osobowych ani całego logu dostępu do publicznego wątku. Przewodnik po przyjmowaniu zgłoszeń w programie ujawniania podatności (VDP) dotyczy innego problemu: obsługi wielu nadesłanych zgłoszeń. Sygnał wykryty we własnym ruchu, którego nikt jeszcze nie zgłosił, wymaga najpierw analizy własnej telemetrii.

Jak ograniczyć narażenie i przekazać sprawę dalej?

Ogranicz konkretne ryzyko potwierdzone dowodami i wyznacz osobę kierującą incydentem, która zdecyduje o następnych krokach. Zespół odbierający ruch odpowiada za swoją usługę, dowody i decyzję dotyczącą incydentu. Operator agenta odpowiada za zadanie i ślad użycia narzędzi; po otrzymaniu powiadomienia może zatrzymać lub ograniczyć działanie agenta.

Jeśli próby trwają, celowana reguła WAF lub rate limiting mogą zmniejszyć ruch bez zakłócania prawidłowego korzystania z usługi. Gdy sekwencja prowadzi do nieoczekiwanie publicznego hosta stagingowego, sprawdź jego dostępność oddzielnie, nawet jeśli pierwotną próbę zablokowano. Przy awaryjnej zmianie zapisz jej zakres, czas, osobę odpowiedzialną i widoczny wynik. Unikaj szerokiej blokady, która odetnie klientów lub zatrze ślad, zanim ustalisz jej skutki.

Właściciel aplikacji powinien ustalić, czy żądania dotarły do aplikacji lub magazynu danych. Osoba kierująca incydentem określa jego wagę i zatwierdza działania ograniczające skutki. Osoba odpowiedzialna za VDP może obsłużyć późniejsze zgłoszenie albo wiadomość od badacza, ale brak zgłoszenia nie czyni z tej sprawy wyłącznie zadania dla kolejki ujawniania podatności. Jeśli w dochodzeniu odkryjesz ujawnione dane uwierzytelniające, zastosuj odrębny proces unieważnienia i zapobiegania powtórce, na przykład checklistę zamknięcia zgłoszenia o ujawnionych danych uwierzytelniających.

Praktyczna notatka o stanie sprawy ma cztery pola: zaobserwowano, sprawdzono, nie wiadomo i następne działanie. Na przykład: „O 10:07 UTC zaobserwowaliśmy żądanie przypominające próbę XSS skierowane do publicznego dashboardu. System ochrony na brzegu sieci oznaczył je jako zablokowane, a w zachowanych logach nie ma pasującego żądania na serwerze źródłowym. Nadal sprawdzamy żądania do stagingu i kompletność logowania na serwerze źródłowym. Właściciel aplikacji przekaże ustalenia do 11:00 UTC”. Takie sformułowanie oddziela ustalenia od przypuszczeń.

Jeśli wasz zespół uruchamia własne skanery lub agentów, powiązany przewodnik po zakresie i autoryzacji skanowania wyjaśnia, co zatwierdzić przed aktywnym testowaniem. Podczas triażu ruchu przychodzącego możesz nie wiedzieć, czy ktokolwiek zatwierdził działanie drugiej strony. Najpierw zbadaj skutki w swoim systemie, a następnie szukaj operatora odpowiedzialnego za agenta.

Jak powiadomić operatora agenta bez zgadywania, kim jest?

Skorzystaj ze zweryfikowanego kontaktu ds. bezpieczeństwa i prześlij krótki zestaw użytecznych danych technicznych. Usługa skanująca, serwer pośredniczący, dostawca hostingu, dostawca modelu, zleceniodawca zadania i operator agenta mogą być różnymi podmiotami. Sam adres źródłowy IP nie wskazuje, kto zatwierdził zadanie lub może je zatrzymać.

Transluce łączy sekwencje dotyczące Data USA i AIHW z opisaną wcześniej grupą agentów pochodzącą od OpenAI na podstawie podobieństw zadań i technik. Przypisanie przypadku University of New Mexico badacze uznają za słabsze. To oceny powiązań dokonane przez badaczy, a nie dowód na to, kto kontrolował każde pojedyncze żądanie. W odrębnej sprawie Services Australia istnieje oficjalne oświadczenie dotyczące operatora. Nie używaj go do wypełniania luk w ustalaniu autorstwa pozostałych przypadków.

Jeśli da się ustalić operatora, podaj nazwę hosta i przedział czasu UTC, identyfikator żądania lub przykład po usunięciu danych wrażliwych, wyniki kontroli na brzegu sieci i serwerze źródłowym oraz oczekiwane działanie: zbadanie śladu zadania, zatrzymanie lub ograniczenie działania agenta i odpowiedź bezpiecznym kanałem. Napisz też, czego nie wiesz. Nie wysyłaj surowych, wrażliwych logów na niezweryfikowany adres tylko dlatego, że widnieje w ciągu user agent.

Jeśli tożsamość operatora jest niejasna, poproś o kontakt do osoby odpowiedzialnej przez opublikowany kanał bezpieczeństwa lub ujawniania podatności danej organizacji albo przez zweryfikowany kanał bezpieczeństwa właściwego usługodawcy. Sprawdź, czy kontakt należy do podmiotu, z którym chcesz rozmawiać. Czekając na odpowiedź, dopilnuj, by sprawa nadal miała osobę odpowiedzialną i ustalony termin ponownej oceny. Powiadomienie idzie równolegle z dochodzeniem; nie zastępuje sprawdzenia logów serwera źródłowego.

Relacja australijskiego rządu pokazuje konkretny problem z przekazaniem informacji. Według premiera OpenAI wysłało 10 września powiadomienie o sprawie Services Australia na ogólnodostępną skrzynkę pocztową, po zdarzeniu z 18 czerwca. To oświadczenie nie wyznacza ogólnego terminu dla takiego ruchu. Pokazuje natomiast, dlaczego operator potrzebuje kanału prowadzącego do osoby odpowiedzialnej za bezpieczeństwo, z danymi pozwalającymi odbiorcy odnaleźć zdarzenie.

Co powinna zawierać notatka zamykająca sprawę?

Zamknij sprawę stwierdzeniem, które wskazuje dowody, ograniczenia analizy i warunek jej wznowienia. „Zablokowano” opisuje wynik konkretnego żądania. „Nie znaleziono dowodów naruszenia” dotyczy sprawdzonych źródeł i przedziału czasu. „Nie doszło do naruszenia” jest znacznie szerszym twierdzeniem.

Krótka notatka może brzmieć: „O 10:07 UTC zaobserwowaliśmy żądanie przypominające próbę XSS skierowane do publicznego dashboardu. Logi z brzegu sieci wskazują, że żądanie zostało zablokowane. W zachowanych logach nie znaleźliśmy pasującego żądania na serwerze źródłowym ani dowodów wykonania skryptu w śladach aplikacji przejrzanych dla przedziału 09:55–10:20 UTC. Nie analizowaliśmy ruchu spoza tego przedziału. Dostępność stagingu sprawdziliśmy osobno. Wznowimy sprawę, jeśli pasujący zapis z serwera źródłowego, nieuprawniony odczyt lub ślad od operatora pokaże inny wynik”. Dopasuj każde zdanie do tego, co rzeczywiście sprawdzono.

Zachowaj powiązany zapis działań dotyczących zmian reguł, poprawek stagingu i odpowiedzi operatora. Jeśli późniejsze ustalenie potwierdzi nieuprawniony skutek, podnieś klasyfikację incydentu i zastosuj zwykły proces reagowania i powiadamiania. Jeśli sprawa pozostanie na poziomie „zaobserwowanej próby”, możesz ją zamknąć bez twierdzenia, że agent był nieszkodliwy lub że ustalono, kto go uruchomił. Dobry triaż pozostawia następnej osobie ślad, na którym można oprzeć wnioski.

Jak Kit może pomóc w tej pracy?

Proces CSIRT w Kit daje zespołowi miejsce do prowadzenia reakcji: zgłoszenie przypisane do konta, z osobą odpowiedzialną, statusem, załącznikami, osią czasu oraz obsługą dyżurów i SLA. Dossier może zebrać opis dochodzenia i wykaz dowodów. Surowe dowody z WAF, serwera źródłowego, systemu tożsamości i magazynu danych zachowuj w systemach, które je wytworzyły. W zgłoszeniu umieszczaj odnośniki lub podsumowania materiałów z ograniczonym dostępem zgodnie z wymaganiami zespołu.

Publiczny kanał ujawniania podatności i proces komunikacji z badaczami przydają się, gdy operator lub badacz przysyła zgłoszenie. Nie zastępują osoby kierującej wewnętrznym incydentem, jeśli pierwszy sygnał pochodzi z waszych logów. Kit nie pobiera automatycznie logów skanera, nie zestawia identyfikatorów żądań, nie ustala tożsamości operatorów agentów, nie zatrzymuje agentów i nie zapewnia kryminalistycznego łańcucha dowodowego. Identyfikator dossier ułatwia wewnętrzne odwoływanie się do sprawy, lecz nie stanowi dowodu integralności materiałów.

Zacznij od małego ćwiczenia: wybierz syntetyczne zablokowane żądanie, zapisz ustalenia z brzegu sieci i serwera źródłowego, wyznacz osobę odpowiedzialną za następny krok i napisz notatkę zamykającą, którą inny członek zespołu może zweryfikować. Jeśli przyjmujecie też zgłoszenia z zewnątrz, przygotujcie jasny program ujawniania podatności, aby prawdziwy operator wiedział, gdzie przesłać ślad działania agenta. Potrzebny wynik to konkretna odpowiedź na pytanie „co się tutaj wydarzyło?” i osoba odpowiedzialna za to, co stanie się dalej.