AISI: agenci AI znaleźli łańcuch ataku w chmurze

Brytyjski AI Security Institute zrobił coś znacznie ciekawszego niż kolejny test na sztucznym benchmarku. Przez dwa tygodnie pozwolił agentom AI badać odseparowane środowisko stagingowe AWS należące do instytutu. Jeden z modeli odnalazł wcześniej nieznany, pięcioetapowy łańcuch błędów konfiguracji: od konta zwykłego użytkownika, przez eskalację uprawnień i ruch boczny, aż do dostępu do workloadów innych użytkowników.

To nie było włamanie do produkcji brytyjskiego rządu. Nie wyciekły prawdziwe dane, a nazwy modeli nie zostały ujawnione. Mimo tych zastrzeżeń opisany 7 lipca eksperyment jest ważny, bo pokazuje realny koszt, użyteczność i ograniczenia agentów w testach chmury.

Jak wyglądał eksperyment AISI

Według studium przypadku AISI test objął kontrolowane środowisko stagingowe w AWS. Zespół wcześniej przygotował zasady działania, izolację, monitoring i proces przeglądu wyników. Agenci nie dostali swobodnego dostępu do produkcji ani danych obywateli.

Badano trzy rodzaje pracy: analizę dynamiczną środowiska, analizę kodu i konfiguracji oraz poszukiwanie ścieżek ataku łączących kilka pozornie drobnych słabości. Najcenniejszy wynik nie był prostym „otwartym portem”. Model połączył pięć kroków, które razem umożliwiały eskalację i dostęp między workloadami.

Jeden model znalazł tę ścieżkę za mniej niż 150 funtów w tokenach. Koszt całego projektu — wszystkich uruchomień, także nieudanych — pozostał poniżej 1000 funtów. To nie obejmuje jednak czasu ekspertów, przygotowania laboratorium, analizy false positives i napraw. Sam rachunek API nie jest pełnym kosztem testu bezpieczeństwa.

Najciekawszy wynik dotyczył detekcji

Podstawowy system alertowy używany w środowisku nie zauważył aktywności agenta. Bardziej zaawansowany monitoring wykrył jej część, ale nie całą sekwencję. To cenna lekcja również bez AI: pojedyncze wywołanie AssumeRole, zapytanie do metadanych czy połączenie sieciowe może wyglądać normalnie. Dopiero korelacja kolejnych kroków ujawnia ścieżkę eskalacji.

Zespół AISI wskazał też, że statyczna analiza kodu była najbardziej zaszumiona. Generowała wiele wyników wymagających pracy człowieka. W środowisku chmurowym kontekst jest kluczowy: ta sama polityka IAM może być bezpieczna lub krytyczna zależnie od relacji z rolami, siecią i danymi.

To potwierdza praktykę znaną z klasycznych testów penetracyjnych: liczba znalezisk nie jest miarą jakości. Liczy się odtwarzalna ścieżka, rzeczywisty wpływ i właściwy priorytet naprawy.

Co ten test udowadnia — a czego nie

Eksperyment pokazuje, że agent może niedrogo odkryć złożoną zależność, którą wcześniej przeoczyli ludzie i standardowe narzędzia. Nie dowodzi, że agent samodzielnie zastąpi pentestera ani że poradzi sobie w każdej architekturze.

AISI nie podał nazw modeli, więc nie da się porównać ich możliwości ani odtworzyć wyniku jeden do jednego. Środowisko było kontrolowane, a specjaliści nadzorowali test. Nie wiadomo też, ile analogicznych uruchomień nie dałoby użytecznego rezultatu w innych organizacjach.

Brytyjskie NCSC w materiale 10 pytań przed użyciem AI do szukania podatności zwraca uwagę m.in. na zakres, zgodę, ochronę danych, weryfikację znalezisk i plan reagowania. To właściwa rama: agent jest narzędziem o dużej skali, a nie automatycznym upoważnieniem do atakowania systemów.

Jak bezpiecznie prowadzić agentowy test chmury

1. Zacznij od stagingu. Środowisko powinno odwzorowywać kluczowe relacje IAM i sieciowe, ale nie zawierać produkcyjnych sekretów ani danych klientów.
2. Zapisz reguły zaangażowania. Określ konta, regiony, usługi, limity wywołań i zabronione działania. Agent nie może sam rozszerzać zakresu.
3. Użyj osobnej tożsamości. Wszystkie działania muszą być przypisane do dedykowanego konta z minimalnymi uprawnieniami i krótkotrwałymi poświadczeniami.
4. Monitoruj sekwencje. Koreluj CloudTrail, aktywność AssumeRole, zmiany polityk, ruch sieciowy i odczyty sekretów. Pojedynczy alert nie wystarczy.
5. Wymagaj dowodu. Znalezisko powinno zawierać warunki wejściowe, kolejne kroki, wpływ i bezpieczny sposób reprodukcji. Opis modelu bez potwierdzenia nie jest podatnością.
6. Zaplanuj triage i naprawy. Budżet na tokeny może być mały, ale setki wyników potrafią sparaliżować zespół. Przed startem ustal kryteria severity i właścicieli poprawek.
7. Zachowaj człowieka w pętli. Ekspert zatwierdza działania o większym wpływie, ocenia kontekst i decyduje, czy łańcuch jest realny.

Rządowe studium When AI leaves the lab podkreśla właśnie tę kombinację: realistyczne środowisko, kontrolowane uprawnienia i ocena człowieka.

Podsumowanie

AISI pokazał, że agent AI może znaleźć prawdziwą, wieloetapową ścieżkę ataku w chmurze przy zaskakująco niskim koszcie obliczeń. Równocześnie ujawnił dwa stare problemy w nowej skali: monitoring nie zawsze łączy pozornie poprawne działania, a statyczne wyniki bez kontekstu generują dużo szumu.

Warto eksperymentować, ale w laboratorium, z własną tożsamością agenta, limitem uprawnień, pełnymi logami i zaplanowanym triage. AI może zwiększyć zasięg zespołu bezpieczeństwa. Nie przejmuje od niego odpowiedzialności.

---

Źródła i dalsza lektura: AISI — Finding cloud misconfigurations with frontier AI, NCSC — 10 questions to ask, GOV.UK — When AI leaves the lab.