AI odmawia analizy bezpieczeństwa? Nie zamykaj przeglądu

Odmowa analizy bezpieczeństwa przez AI oznacza, że zlecone badanie nie zostało ukończone. Nie dowodzi, że plik jest złośliwy ani że jest bezpieczny. Zachowaj oryginalny materiał, zapisz, czego asystent nie zdołał zbadać, i wyznacz osobę z odpowiednimi uprawnieniami, która zdecyduje o dalszej analizie. Nie zamykaj przeglądu, dopóki dowody nie pozwolą wyciągnąć wniosków.

To rozróżnienie ma znaczenie, jeśli przy obsłudze zgłoszeń bezpieczeństwa korzystasz z asystenta do wyjaśniania nieznanego kodu. Przekonująca odmowa może wyglądać jak wynik analizy: narzędzie wspomina o niebezpiecznych treściach, odmawia wykonania zadania i zwraca odpowiedź sprawiającą wrażenie kompletnej.

Nadal jednak potrzebujesz odpowiedzi na pierwotne pytanie o plik. Niedawna analiza skryptu do fingerprintingu dobrze ilustruje ten problem. Wniosek dla zespołu jest prosty: gdy narzędzie przerywa analizę, ktoś musi nadal odpowiadać za znalezienie odpowiedzi.

Co się wydarzyło podczas analizy skryptu do fingerprintingu?

Według relacji badacza niepokojący tekst w pliku JavaScript towarzyszył odmowom deobfuskacji ze strony niektórych asystentów. Inny asystent miał wykonać zadanie. To przykład różnych reakcji narzędzi, a nie dowód, że w ten sam sposób da się zatrzymać każde narzędzie AI do analizy bezpieczeństwa.

W opisie analizy opublikowanym 28 października 2026 r. veritas przedstawia mylące nazwy symboli i ukryte instrukcje znalezione w skrypcie służącym do identyfikowania przeglądarek metodą fingerprintingu. Jego zdaniem najprawdopodobniej chodzi o obfuskację wymierzoną w modele LLM, czyli treści mające utrudnić analizę wspomaganą przez AI.

Autor opisuje mechanizmy fingerprintingu, ale omawia też podejrzany kod powiązany z konkretnymi środowiskami. Jego relacja nie daje podstaw, by uznać cały plik za nieszkodliwy. Nie pobieraliśmy ani nie uruchamialiśmy tej próbki i nie przeprowadziliśmy jej niezależnej inżynierii wstecznej. Publikacja nie jest też kontrolowanym testem porównawczym modeli.

Nie trzeba rozstrzygać hipotezy autora o intencjach twórców kodu, żeby skorzystać z tego przykładu. Opisane odmowy pozostawiły zadanie niedokończone. Dalsza analiza powinna być częścią twojego postępowania wyjaśniającego, niezależnie od tego, dlaczego dany asystent się zatrzymał.

O czym właściwie świadczy odmowa AI?

Odmowa mówi coś o próbie skorzystania z narzędzia. Uznanie pliku za złośliwe oprogramowanie wymaga dowodów dotyczących jego zachowania lub możliwości. W zgłoszeniu zapisuj te ustalenia oddzielnie.

Nazwa funkcji może opisywać coś, czego program nigdy nie robi. Tekst umieszczony w pliku może być danymi, zmyłką, instrukcją skierowaną do czytelnika albo częścią wykonywanej logiki. Dopiero badanie pozwala ustalić, z czym mamy do czynienia. Odpowiedź odnosząca się do pozornej tematyki tekstu nie zastępuje tej pracy.

Równie słaby jest odwrotny wniosek: podejrzenie, że alarmujące treści umieszczono po to, by utrudnić analizę, nie wystarcza do uznania pliku za bezpieczny. Hipoteza o zmyłce nie wyjaśnia pozostałych części programu.

Obok niezależnie potwierdzonych ustaleń stosuj status opisujący postęp prac, na przykład analiza nieukończona. Nie sprowadzaj dostępności narzędzia, postępu badania i rozstrzygnięcia dotyczącego bezpieczeństwa do jednego zielonego lub czerwonego statusu.

Tabela to propozycja sposobu dokumentowania pracy, a nie system klasyfikacji zagrożeń. Pomaga kolejnej osobie zrozumieć, dlaczego przegląd nadal trwa, bez traktowania każdej nieudanej próby jako takiego samego zdarzenia.

To rozróżnienie przydaje się również przy ocenie zgłoszeń dotyczących sondowania zabezpieczeń przez agentów AI. Tutaj pytanie jest jednak bardziej konkretne: kto dokończy przerwane badanie?

Co zachować przed przekazaniem materiału do dalszej analizy?

Zanim zmodyfikujesz kopię roboczą, zabezpiecz otrzymany materiał i informacje o jego pozyskaniu. Kolejna osoba analizująca sprawę powinna móc ustalić, co otrzymano, co zbadano i jakie przekształcenia wykonano.

Opublikowany w 2006 r. dokument NIST SP 800-86 zaleca badanie kopii i sprawdzanie integralności za pomocą skrótów kryptograficznych. Te zasady postępowania z materiałem dowodowym nadal są przydatne. Ze względu na wiek dokumentu nie warto jednak opierać na nim wyboru współczesnych narzędzi analitycznych.

Przy przekazywaniu sprawy zachowaj oryginał w zabezpieczonym miejscu, którego zespół już używa do przechowywania dowodów. Zapisz źródło materiału, datę jego pozyskania oraz związek kopii roboczej z oryginałem. Jeśli w waszym procesie stosujecie wartość referencyjną do kontroli integralności, dołącz ją do dokumentacji.

Nie zastępuj otrzymanego pliku uporządkowaną wersją. Kopia po normalizacji lub z adnotacjami może ułatwić lekturę, ale oznacz ją jako materiał pochodny. W przeciwnym razie ktoś z zespołu może uznać twoje zmiany za treść dostarczoną przez osobę zgłaszającą.

Takiej samej staranności wymaga odpowiedź asystenta. Zachowaj kontekst wystarczający do wyjaśnienia ograniczenia: zlecone zadanie, zatwierdzone narzędzie i jego wersję, jeśli jest znana, oraz zaobserwowaną odpowiedź lub błąd.

Nie musisz kopiować poufnych treści do każdego komentarza, by dokumentacja była użyteczna. Udostępnij uprawnionym recenzentom odnośnik do miejsca z kontrolą dostępu.

Tak proponujemy zastosować zasady postępowania z dowodami do odmowy AI. Nie twierdzimy, że NIST przewiduje specjalną procedurę na taką sytuację ani że zapisanie rozmowy zapewnia udokumentowany łańcuch przechowywania materiału dowodowego.

Kto odpowiada za przegląd, gdy analiza AI się zatrzyma?

Konkretna osoba powinna odpowiadać za nierozstrzygnięte pytanie i wybrać kolejny dozwolony krok analizy. Odmowa asystenta powinna zmienić plan pracy, ale nie może niezauważenie zamknąć zgłoszenia ani przesądzić o jego poziomie ważności.

Zacznij od uprawnień, które już masz. Zgłoszenie dotyczące twojego systemu nie daje automatycznie prawa do sondowania systemów podmiotu trzeciego, przesyłania poufnego kodu do innej usługi ani uruchamiania nieznanej próbki na służbowym komputerze. Osoba prowadząca przegląd powinna dobrać narzędzia i środowisko do materiału oraz uzgodnionego zakresu prac.

Może to być ręczna analiza statyczna, czyli badanie kodu bez jego uruchamiania. Inne możliwości to tradycyjne narzędzia analityczne w odizolowanym środowisku lub konsultacja ze specjalistą uprawnionym do dostępu do materiału. Wybór zależy od pytania, na które trzeba odpowiedzieć, oraz możliwości zespołu.

Nie formułuj zadania jako „znajdź prompt, który pozwoli uzyskać odpowiedź”. Określ je konkretnie: ustal, jakie dane zbiera skrypt, sprawdź zgłoszone zachowanie w ramach testu objętego uprawnieniami lub wyjaśnij podejrzaną gałąź kodu. Jasne pytanie daje recenzentowi użyteczny punkt wyjścia.

Oprócz osoby odpowiedzialnej wyznacz termin kolejnego przeglądu. Samo przypisanie kogoś do sprawy, bez uzgodnionej czynności, może pozostawić ją w takim samym zastoju jak zgłoszenie bez opiekuna.

Jeśli zespół nie ma potrzebnych kompetencji lub narzędzi, zapisz to ograniczenie i ustal, jak je uzupełnić. Nie uznawaj po cichu przeglądu za zakończony.

Wytyczne NIST dotyczące reagowania na incydenty z kwietnia 2025 r. opisują szerszy kontekst takich działań. Zastosowanie tego podejścia oznacza tu zadbanie, by nierozwiązane zadanie pozostawało widoczne i miało osobę odpowiedzialną. Nie oznacza to, że każda odmowa badania jest incydentem.

Co uwzględnić przy przekazywaniu zgłoszenia?

Dokumentacja powinna umożliwić kolejnej uprawnionej osobie wznowienie pracy bez zgadywania, co się wydarzyło. Dodaj odnośnik do materiału, pytanie, na które próbowano odpowiedzieć, zaobserwowane ograniczenie i osobę odpowiedzialną za kolejny krok.

Poniższy wymyślony przykład można dostosować do własnego procesu. To nasza propozycja pól, a nie standard branżowy ani formularz Kit:

Materiał: Oryginalny plik JavaScript w repozytorium dowodów zespołu z ograniczonym dostępem; w tym samym miejscu zapisano kontekst pozyskania i wartość referencyjną do kontroli integralności.

Podjęte zadanie: Analiza statyczna mechanizmów zbierania danych i komunikacji wychodzącej w pliku.

Zaobserwowane ograniczenie: Zatwierdzony asystent odmówił badania. Odnośnik do jego odpowiedzi znajduje się w dokumentacji analizy.

Wykonana praca: Materiał został zabezpieczony. Ta próba nie pozwoliła wyciągnąć wniosków o jego zachowaniu.

Nierozstrzygnięte pytanie: Jakie informacje zbiera skrypt i dokąd może je wysyłać?

Osoba odpowiedzialna i kolejna czynność: Wyznaczony analityk wybierze metodę zgodną z posiadanymi uprawnieniami i zaktualizuje zgłoszenie w uzgodnionym terminie przeglądu.

Pisz precyzyjnie. „Asystent odmówił” to obserwacja. „Plik pokonał nasze zabezpieczenia” jest szerszym twierdzeniem, którego ten zapis nie potwierdza. „Nie znaleziono problemu” również błędnie opisywałoby badanie, które nigdy się nie zakończyło.

Gdy recenzent dojdzie do wniosków, powinien wskazać, jakiego materiału i środowiska one dotyczą. Jeśli zbadał tylko jedną ścieżkę wykonania kodu, trzeba to zaznaczyć. Jeśli dowody nadal nie pozwalają na rozstrzygnięcie, pozostaw tę niepewność w dokumentacji zamiast tworzyć pozornie ostateczną odpowiedź.

Potrzeba dokumentacji użytecznej dla człowieka wiąże się też z obsługą dużej liczby zgłoszeń generowanych przez AI. W obu przypadkach dopracowana odpowiedź nie wystarcza, jeśli nie pomaga komuś podjąć kolejnej decyzji. Zgłoszenie powinno pokazywać, co wiadomo i jaka praca pozostała do wykonania.

Jak Kit może wspierać ten proces?

Proces obsługi zgłoszeń pozwala zachować widoczność niedokończonego przeglądu, gdy zespół analizuje materiał przy użyciu narzędzi, z których ma prawo korzystać. Przyjęcie zgłoszenia, analiza i rozstrzygnięcie to osobne czynności. Niepowodzenie na etapie analizy powinno pozostać widoczne w dokumentacji.

Obsługa zgłoszeń podatności w Kit obejmuje przypisanie osoby odpowiedzialnej, dyskusję i oś czasu. Screening AI udostępnia też status nieudanej weryfikacji, który wymaga uwagi człowieka. Dzięki temu zespół może zauważyć niedokończoną pracę i zapisać dalsze działania.

Screening AI w Kit dotyczy jakości zgłoszenia, a nie analizy exploitów. Widoczny błąd screeningu nie oznacza, że Kit wykrył obfuskację wymierzoną w modele LLM lub rozpoznał celowo wywołaną odmowę modelu. Nie kieruje też automatycznie podejrzanego materiału do specjalisty.

Wybór i wykonanie analizy nadal należą do zespołu. Kit nie uruchamia ani nie deobfuskuje takich próbek, nie oblicza opisanych wyżej skrótów materiału dowodowego i nie wymusza stosowania proponowanych pól przy przekazaniu sprawy. Zabezpieczaj materiał i przeprowadzaj badanie techniczne w zatwierdzonych systemach, a w zgłoszeniu dokumentuj odpowiedzialność i postęp prac.

Odmowa AI pozostawia pytanie bez odpowiedzi. Zachowaj otrzymany materiał, opisz ograniczenie i powierz osobie z odpowiednimi uprawnieniami konkretne zadanie. Jeśli potrzebujesz wspólnego miejsca, w którym zgłoszenie, osoba odpowiedzialna i dalsze działania będą widoczne, poznaj obsługę zgłoszeń podatności w Kit.