Według Google Threat Intelligence Group (GTIG) w drugim kwartale 2026 r. napastnicy przejęli zasób chmurowy, a następnie w mniej niż sześć godzin zaplanowali, zbudowali i uruchomili wspomaganą agentami kampanię zbierania danych logowania. Dla polskiej firmy rozwijającej AI płynie stąd zalecenie: scenariusz incydentu powinien obejmować odcięcie zasobów, unieważnienie tokenów i zatrzymanie automatyzacji.

Kto w firmie potrafi zatrzymać zadania agenta AI, jeśli napastnik przejmie wykorzystywany przez niego zasób? Odpowiedź „zespół techniczny” zostawia do ustalenia wykonawcę, zakres operacji i prawo do jej zatwierdzenia. Proponujemy zacząć od wskazania konkretnego zasobu oraz osoby, która odpowiada za jego odcięcie. Raport GTIG opublikowany 8 września daje punkt wyjścia do takiej rozmowy: opisuje sekwencję od przejęcia zasobu do uruchomienia kampanii. Wrześniowa data dotyczy publikacji; sama obserwacja pochodzi z drugiego kwartału. Na tej podstawie zbudujmy ćwiczenie dla własnego środowiska AI, w którym uczestnicy mają wskazać zasób, odebrać dostęp i potwierdzić zatrzymanie zadań.

Mniej niż sześć godzin obejmuje przygotowanie i start kampanii

W opisie GTIG po przejęciu zasobu nastąpiło planowanie, budowanie i uruchomienie kampanii zbierania danych logowania. Udział agentów w tej sekwencji jest ustaleniem badaczy. Nie dopisujmy do niego twierdzenia, że każdy etap odbył się bez człowieka, ani szacunku, o ile AI skróciła czas operacji. Przywołane fakty nie dają takiego porównania.

Czas poniżej sześciu godzin potraktujmy jako parametr zaobserwowanego zdarzenia. Nie wyznacza on bezpiecznego terminu reakcji w naszej firmie ani czasu potrzebnego do zakończenia każdego podobnego ataku. Nasz wniosek organizacyjny jest węższy. Przygotujmy sposób odcięcia przejętego zasobu, zanim trzeba będzie użyć go podczas incydentu.

Dla wybranego wdrożenia AI zapiszmy osobno, kto odcina zasób, kto unieważnia tokeny i kto zatrzymuje zadania. Poprośmy wykonawców o wskazanie sposobu sprawdzenia każdej operacji. W ćwiczeniu wymagajmy potwierdzenia odebrania dostępu oraz zatrzymania pracy automatyzacji, zamiast kończyć je na wysłaniu zgłoszenia do administratora.

Scenariusz incydentu AI powinien kończyć się potwierdzonym odcięciem zasobów, tokenów i zadań.

UNC6780 skłania do sprawdzenia roli asystenta i skanera

Według GTIG grupa UNC6780 podejmowała próby manipulowania asystentami kodowania i skanerami bezpieczeństwa opartymi na dużych modelach językowych (LLM) podczas kompromitowania otwartego oprogramowania. Ten drugi fakt również uwzględnijmy w przeglądzie firmowego AI. Nie przypisujmy jednak tej grupie opisanej wcześniej kampanii: przywołane ustalenia nie łączą obu obserwacji.

Wniosek dla procedur proponujemy sprawdzić na konkretnym zadaniu asystenta. Zestawmy zapisany zakres jego pracy z przyznanymi uprawnieniami. Jeśli korzystamy ze skanera opartego na LLM, ustalmy, kto oceni jego wynik podczas podejrzenia manipulacji. Przegląd zakończmy wskazaniem osoby uprawnionej do wstrzymania automatyzacji oraz warunku, przy którym ma zdecydować o wstrzymaniu.

Z przywołanych faktów nie znamy procedur zaatakowanych organizacji ani zachowania ich pracowników. Nie ma więc podstaw, by opisywać złamanie instrukcji lub zignorowanie ostrzeżenia. Zderzenie procedury z praktyką przeprowadźmy u siebie: poprośmy wskazanego wykonawcę, by podczas ćwiczenia pokazał, jak zatrzyma zadanie. Brak uprawnienia do wykonania tej czynności zapiszmy jako wynik ćwiczenia wymagający decyzji właściciela zasobu.

Właściciel zasobu musi zatwierdzić zakres uprawnień agenta

Obserwacja GTIG uzasadnia pytanie zarządcze o odpowiedzialność za przejęty zasób. Dla każdego omawianego wdrożenia AI wyznaczmy właściciela zasobów i osobę prowadzącą reakcję na incydent. Ustalmy, kto może zatwierdzić odebranie dostępu, a kto wykona operację. Jeżeli te role pełnią różne osoby, zapiszmy sposób przekazania decyzji między nimi i sprawdźmy go w ćwiczeniu.

Ograniczenie uprawnień agentów zacznijmy od przypisania każdego dostępu do zatwierdzonego zadania. Przy uprawnieniu bez uzasadnienia wskażmy właściciela decyzji o jego odebraniu. Nie zakładajmy z góry, że wszystkie firmowe automatyzacje wymagają tego samego zakresu dostępu albo że samo zawężenie uprawnień zakończy przygotowania do incydentu.

Koszt zatrzymania zadań omówmy z właścicielem wybranego procesu AI: niech wskaże, które czynności trzeba będzie wstrzymać i kto zaakceptuje przerwę. Przywołane ustalenia nie podają kosztów incydentu, więc nie wyliczymy z nich strat ani oszczędności po zmianie konfiguracji. Do decyzji przygotujmy własną listę zależności od zasobu i warunki ponownego uruchomienia zadań po ćwiczeniu.

Uprawnienia agenta AI powinny wynikać z jego zadania, a odpowiedzialność za ich odebranie powinna być przypisana przed incydentem.

Polska firma może przećwiczyć odcięcie własnego wdrożenia AI

Przywołane ustalenia GTIG nie identyfikują polskiej ofiary. Nie pozwalają też oszacować, jak często podobny scenariusz występuje w polskich firmach. Dla organizacji rozwijającej AI punktem odniesienia powinien być jej własny zasób chmurowy, używane tokeny i uruchamiane zadania. Zalecenie przećwiczenia ich odcięcia nie wymaga przypisywania opisanego ataku lokalnej firmie.

Na początek wybierzmy jedno wdrożenie AI i przygotujmy jego właścicielowi listę zasobów, uprawnień oraz automatyzacji objętych ćwiczeniem. Przy brakującej informacji wpiszmy osobę, która ma ją ustalić. Oddzielmy potwierdzony dostęp od założenia o dostępie; dopiero sprawdzenie konfiguracji pozwoli zamknąć tę część przygotowań.

Wynik ćwiczenia przekażmy zarządowi jako zapis wykonanych operacji i niewyjaśnionych zależności. Jeśli udało się unieważnić token, ale nie potwierdzono zatrzymania zadania, pozostawmy tę czynność otwartą. Gotowość wybranego wdrożenia AI oceniajmy przez możliwość wykonania uzgodnionego odcięcia, z nazwanym wykonawcą i potwierdzeniem wyniku.

Co z tym zrobić w poniedziałek

  1. Przypisz odpowiedzialność za wybrany zasób AI. W 30 minut zapisz jego właściciela, osobę prowadzącą incydent i wykonawców odcięcia dostępu oraz zatrzymania zadań. Potwierdź przypisania z tymi osobami; brak potwierdzenia oznacz jako sprawę do rozstrzygnięcia, z nazwanym odpowiedzialnym.
  2. Sprawdź uprawnienia jednego agenta. Przeznacz 30 minut na porównanie jego zatwierdzonego zadania z konfiguracją dostępu do wybranego zasobu. Wskaż uprawnienia bez uzasadnienia i przekaż właścicielowi konkretną decyzję o ich ograniczeniu. Odnotuj, kto wykona zmianę i potwierdzi jej wynik.
  3. Przećwicz odcięcie na przygotowanym środowisku testowym. W 30 minut unieważnij przeznaczony do próby token i zatrzymaj powiązane zadanie automatyzacji. Sprawdź odmowę dostępu tym tokenem oraz stan zadania. Zapisz wynik obu operacji i przypisz wykonawcę poprawki, jeśli którejś nie udało się potwierdzić.

Scenariusz incydentu AI uznajmy za przećwiczony dopiero po sprawdzeniu odcięcia zasobu, odebrania dostępu i zatrzymania zadań. Właściciel wdrożenia powinien umieć wskazać wykonawców tych operacji oraz potwierdzić ich rezultat. Obserwacja GTIG daje powód, by taką zdolność sprawdzić przed przejęciem firmowej chmury.

Źródła

Redakcja cyberinsight.pl.