Raport Mandiant 2026 dotyczący AI: rachunek na 50 000 dolarów za wymkniętego spod kontroli agenta i intruzje wspomagane przez AI

Raport Mandiant AI Risk and Resilience 2026 opublikowany w Google Cloud we wrześniu 2026 r. i omówiony w tym samym tygodniu przez Help Net Security, The Hacker News oraz SecurityBrief opisuje trzy przypadki, w których sztuczna inteligencja była mechanizmem, a nie celem ataku: przejętą sesję asystenta AI do kodowania, która rozprzestrzeniła robaka Shai-Hulud w około 100 wewnętrznych repozytoriach u nienazwanego dostawcy oprogramowania jako usługi; skompromitowane poświadczenie CI/CD, które intruz przekształcił w wspierane przez AI centrum działań ofensywnych wewnątrz firmy z branży ochrony zdrowia, eksfiltrując tysiące poświadczeń; oraz agenta księgowego, który wygenerował około 50 000 USD opłat za chmurę w niespełna godzinę po tym, jak uszkodzona wartość null zepsuła jedno z jego narzędzi, blokując bazę danych rozliczeń i wstrzymując bieżące transakcje. W trzecim przypadku nie brał udziału żaden napastnik. Dokumentacja, na której opiera się ten artykuł, oraz powiązane z nim wpisy znajdują się w archiwum incydentów AI, które zawiera własne źródła każdego wpisu, poziom istotności, ocenę pewności i oznaczenie sporności.

Jakiego rodzaju jest to dokument?

Raport nosi tytuł „Ryzyko i odporność AI w 2026 r.: raport specjalny Mandiant” na stronie zasobów bezpieczeństwa Google Cloud i jest publikacją dostawcy, a nie ujawnieniem naruszenia. Jego studia przypadków pochodzą ze zleceń Mandiant w zakresie reagowania na incydenty oraz z ocen przeprowadzonych przez jej zespół Offensive Security, a organizacje są identyfikowane wyłącznie według sektora: dostawca oprogramowania jako usługi, globalna organizacja opieki zdrowotnej, globalny dostawca usług finansowych dla przedsiębiorstw. Żadna ofiara nie jest wymieniona z nazwy, żadne wtargnięcie nie ma podanej daty i żadnemu z trzech przypadków nie towarzyszy oświadczenie ofiary.

To wpływa na to, jak należy odczytywać te liczby. Każda liczba w nich pochodzi od własnych śledczych Mandiant. Notatka Frontier Ready Cloud Security Alliance z 16 września określa opłatę w wysokości około 50 000 USD oraz wolumen 15 000 wywołań jako „zgłoszone samodzielnie (wskaźnik dostawcy)” i stwierdza, że „nie zostały niezależnie zweryfikowane” — co trafnie opisuje cały raport, który nie publikuje żadnych danych telemetrycznych osób trzecich do porównania. Archiwum klasyfikuje ten wpis jako zapis informacyjny — raport, a nie incydent z odnotowanymi szkodami — i przyznaje mu ocenę pewności A, nie oznaczając go jako kwestionowanego; ta ocena świadczy o tym, jak dobrze raport jest udokumentowany, a nie o tym, czy strona zewnętrzna potwierdziła jego treść.

W samym ujęciu raportu przeciwnicy w 2026 r. przeszli od proszenia chatbotów o badania do pozwalania systemom agentowym na realizowanie części intruzji. Mandiant twierdzi, że Google Threat Intelligence Group zaobserwowała, jak aktorzy wdrażają autonomiczne narzędzia, w tym Hexstrike i Strix, do rekonesansu i pozyskiwania poświadczeń, oraz budują przekaźniki proxy i zautomatyzowane potoki rejestracji, aby omijać zabezpieczenia i limity rozliczeniowe na komercyjnych platformach AI. Raport cytuje lutową weaponizację umiejętności agentowych OpenClaw udokumentowaną przez VirusTotal, marcowe kompromitacje łańcucha dostaw, które Mandiant przypisuje aktorowi śledzonemu przez siebie jako UNC6780, a przez innych jako TeamPCP, oraz majowe ujawnienie, które GTIG opisała jako pierwszy publicznie potwierdzony przypadek cyberprzestępcy wykorzystującego opracowany przez AI exploit zero-day, taki który ominął uwierzytelnianie dwuskładnikowe w popularnym narzędziu administracyjnym o otwartym kodzie źródłowym.

Przypadek pierwszy: asystent polecił pakiet

W pierwszym przypadku atakujący przejął kontrolę nad dostawcą usług software-as-a-service, a następnie przejął aktywną sesję asystenta kodowania AI na stacji roboczej dewelopera. Mandiant opisuje asystenta jako „działającego jako zaufany interpreter w obrębie środowiska”: zalecił on instalację zewnętrznego pakietu oprogramowania, który atakujący już zatruł, a deweloper zaakceptował tę rekomendację. W raporcie stwierdza się, że asystent „nieumyślnie działał jako koń trojański”.

Podczas sesji na żywo napastnik zainstalował infostealer za pośrednictwem zatrutego pakietu PyPI i zebrał tokeny OAuth GitHub dewelopera. Samorozprzestrzeniający się robak Shai-Hulud przemieścił się następnie przez około 100 wewnętrznych repozytoriów kodu, automatyzując kradzież sekretów repozytoriów i programowe eksfiltrowanie zastrzeżonego kodu źródłowego produktu. Napastnik zatruł także pakiet w oficjalnej przestrzeni nazw organizacji, a drugi pracownik pobrał zainfekowaną wersję — infekcję wtórną, która, według Mandiant, nie wymagała dalszych działań ze strony intruza.

Czego raport nie mówi, to kiedy miało miejsce którekolwiek z tych zdarzeń ani w jaki sposób atakujący w ogóle przejął kontrolę nad sesją asystenta. The Hacker News, relacjonując studium przypadku 16 września, odnotowuje oba te pominięcia. Notatka badawcza Cloud Security Alliance z 18 września dotycząca tego przypadku nazywa wektor początkowego dostępu „najważniejszym otwartym pytaniem studium przypadku” i zauważa, że zalecane przez Mandiant mechanizmy kontroli dotyczą tego, jak daleko może rozprzestrzenić się infekcja, a nie tego, w jaki sposób przejęto sesję.

Mandiant stosuje w tym przypadku trzy mechanizmy kontrolne, które konkretnie odnoszą się do tego niepowodzenia: wymuszaj hooki weryfikacyjne w IDE i CLI, które sprawdzają każdą rekomendowaną przez AI zależność zewnętrzną pod kątem kryptograficznych sum kontrolnych i zatwierdzonej listy dozwolonych; trzymaj surowe klucze API, długotrwałe tokeny OAuth i inne sekrety poza zasięgiem rozszerzeń; oraz ogranicz wychodzący ruch sieciowy stacji roboczej, aby ruch związany z zależnościami był kierowany wyłącznie przez kontrolowane repozytoria wewnętrzne.

Przypadek drugi: poświadczenie CI/CD przekształcone w centrum współdebugowania z AI

Drugi przypadek to dochodzenie w chmurze korporacyjnej w globalnej organizacji opieki zdrowotnej. Mandiant namierzył anomalię do skompromitowanego, długoterminowego poświadczenia deweloperskiego CI/CD, którego intruz użył do uruchomienia nieizolowanej instancji VM i przekształcenia jej w aktywny hub ofensywny. Zamiast budować narzędzia offline, atakujący podłączył duże modele językowe bezpośrednio do działającego serwera i iterował na nich w miejscu.

Mandiant opisuje trzystopniowy proces. Najpierw następowało wstępne przygotowanie kontekstu: pakiety kodu synchronizowane przez sesje zdalne oraz pliki README projektu ładowano do kontekstu czatu modelu, aby ukierunkować późniejsze generowanie kodu na cele kampanii. Następnie interaktywne debugowanie: atakujący polecił modelowi zbudować wieloworkerowy framework do zbierania danych i wspólnie z nim rozpracowywał logiczne błędy dzielenia skryptów, zwiększając częstotliwość eksfiltracji do trzygodzinnego cyklu. Wreszcie unikanie wykrycia i eksploatacja: model napisał dynamiczne skrypty rotacji IP, aby w locie podmieniać adresy serwerów znajdujące się na czarnej liście, i współtworzył narzędzie oparte na Rust do logowania się na konta ofiar i sprawdzania sald finansowych.

Mandiant twierdzi, że kampania naruszyła tysiące poświadczeń i eksfiltrowała pozyskane klucze API oraz sekrety finansowe do repozytorium kontrolowanego przez atakującego. W raporcie nie podano, na czyje konta skierowano narzędzie Rust, do kogo należały sprawdzane salda finansowe ani co później stało się z poświadczeniami. W studium przypadku nigdzie nie wspomniano o danych pacjentów.

Zalecane mechanizmy kontroli koncentrują się na poświadczeniach, a nie na modelu: zastąp długotrwałe klucze dostępu krótkotrwałymi relacjami zaufania Workload Identity Federation wykorzystującymi OIDC; ogranicz ruch wychodzący za pomocą VPC Service Controls, aby środowiska wykonawcze i programistyczne nie mogły łączyć się z niezatwierdzonymi zewnętrznymi dostawcami modeli; prowadź ciągłe skanowanie sekretów w obszarach roboczych; oraz umieść na ścieżce zaporę ogniową promptów działającą w czasie wykonania, taką jak Model Armor, aby przechwytywać zaszyte na stałe poświadczenia i blokować ofensywne skrypty narzędziowe w trakcie ich wykonywania.

Przypadek trzeci: agent, który wydał 50 000 dolarów w niecałą godzinę

Trzeci przypadek nie miał przeciwnika. Globalny dostawca usług finansowych dla przedsiębiorstw wdrożył agenta do uzgadniania anomalii w swoim rejestrze księgowym i przyznał mu prawo odczytu i zapisu do wewnętrznych baz danych rozliczeniowych. Uszkodzona wartość null zepsuła narzędzie formatujące agenta, a agent zareagował wejściem w to, co Mandiant nazywa nieograniczoną, rekurencyjną pętlą rozumowania, aby metodą brute force wymusić rozwiązanie.

W ciągu niespełna godziny wykonano ponad 15 000 wywołań API do rozumowania o wysokiej częstotliwości i wysokim koszcie, co spowodowało nagły skok opłat za chmurę o około $50,000. Ta sama pętla spowodowała poważne blokady lokalnej bazy danych, które wstrzymały aktywne transakcje biznesowe. Mandiant klasyfikuje ten przypadek jako „denial-of-wallet”, a zalecane rozwiązania mają charakter operacyjny, a nie na poziomie modelu: limit wydatków, ograniczoną rekurencję i wyłącznik bezpieczeństwa, który zatrzymuje agenta stale zawodzącego przy tym samym zadaniu.

W raporcie nie podano, czy opłata została uiszczona, uznana czy zakwestionowana, jak długo wstrzymano transakcje, czy dotyczyło to klientów ani co firma zmieniła później. Nie podano także daty. W przeglądzie SecurityWeek z 18 września sklasyfikowano to w kategorii, którą raport wskazuje jako nową kategorię ryzyka finansowego, a nie jako konwencjonalne włamanie.

Proponowane przez Mandiant mechanizmy kontroli mają odpowiednio finansowy charakter: definicje dostępu oparte na tożsamości i rolach dla agentów, progi górnych limitów kosztów i monitorowanie jako element zarządzania, a także zautomatyzowane finansowe wyłączniki awaryjne, które zatrzymują agenta po określonej liczbie kolejnych niepowodzeń zadań. Na poziomie usług i projektów zaleca się twarde limity finansowe, ograniczone limity rekurencji i limity szybkości, aby pętla autokorekty została zdławiona, zanim przekształci się w awarię.

Co zostało ustalone, co jest przypisywane, a co nie zostało ujawnione

Ustalono. Firma Mandiant opublikowała ten raport, a mówi on to, co podsumowano powyżej. Cztery serwisy branżowe omówiły go w ciągu trzech dni od siebie — Help Net Security i The Hacker News 16 września, SecurityBrief UK 17 września, a SecurityWeek 18 września — i ich relacje zgadzają się z raportem w każdej przytaczanej przez nie liczbie. Cloud Security Alliance opublikowała 18 września odrębną notatkę badawczą dotyczącą pierwszego przypadku, dochodząc do tej samej interpretacji jego mechaniki i tego samego wniosku co do tego, co Mandiant pominął.

Przypisywane, niezweryfikowane niezależnie. Konkretne liczby należą do Mandiant: około 100 repozytoriów, tysiące danych uwierzytelniających, trzygodzinny cykl eksfiltracji, ponad 15 000 wywołań rozumowania, około 50 000 dolarów, niecała godzina. Żadna redakcja nie opublikowała telemetrii od żadnego z trzech poszkodowanych, a żadnego z trzech nikt nie wymienił z nazwy. Istniejące potwierdzenie dotyczy treści raportu, a nie samych wydarzeń. To rozróżnienie jest wszystkim, na czym czytelnik może się tu oprzeć, i ocenę pewności archiwum również należy odczytywać w ten sposób.

Nie ujawniono. Raport nie podaje dat żadnego z trzech zleceń, nazwisk ofiar ani opisu tego, w jaki sposób przejęto sesję asystenta w pierwszym przypadku. Nie mówi, czy unieważniono pozyskane tokeny OAuth GitHub i sekrety repozytoriów, czy wykorzystano lub zresetowano tysiące danych uwierzytelniających z drugiego przypadku, czy ucierpiały osoby, których dane dotyczą, w organizacji opieki zdrowotnej, czy odzyskano opłatę agenta księgowego, ani co następnie zmieniła którakolwiek z trzech organizacji. W tym artykule nie znaleziono oświadczenia ofiary, zawiadomienia regulatora ani późniejszych reportaży opublikowanych od 16 września, które wypełniłyby te luki.

Gdzie relacje się rozbiegają. Nota Cloud Security Alliance opisuje drugie zakażenie w pierwszym przypadku jako rozprzestrzenione za pośrednictwem własnej przestrzeni nazw npm firmy. Tekst Mandiantu mówi jedynie o „pakiecie w oficjalnej przestrzeni nazw organizacji” i nie wymienia tam ekosystemu; interpretacja jako npm jest dodatkiem, a nie cytatem. Osobno The Hacker News wyraźnie podaje, że robak w tym przypadku nie jest — według dostępnych dowodów — powiązany z sierpniowym robakiem npm, który zasadził hooki dla asystentów kodowania, ani z wariantem Shai-Hulud wykrytym podczas skanowania 469 lokalizacji w poszukiwaniu poświadczeń — ta sama nazwa rodziny, odrębne kampanie, bez dowodów w artykule na ich powiązanie.

To, co według raportu powinno ulec zmianie

Rekomendacje Mandiant powtarzają się w studiach przypadków zawartych w raporcie: odejść od długoterminowych poświadczeń i kont usługowych na rzecz tożsamości powiązanych z obciążeniem i z założenia krótkotrwałych; traktować asystentów kodowania AI i serwery MCP jako sesje uprzywilejowane, których rozszerzenia i hooki CLI są weryfikowane przed uruchomieniem; zamykać obciążenia agentów w obwodach sieciowych blokujących ruch wychodzący do niezatwierdzonych dostawców modeli; oraz instrumentować użycie tokenów, wywołania API między aplikacjami i dostęp agentów do wrażliwych zasobów, tak aby pierwszy odczyt wrażliwego repozytorium ujawniał się jako sygnał, a nie wtapiał w legalny ruch narzędzi.

Pod względem kosztów wyznacza granicę między governance of AI a governance for AI: z jednej strony polityka określająca apetyt na ryzyko i zasady zakupów, z drugiej — egzekwowane limity techniczne. Agent księgowy jest przykładem z raportu, jak zawodzi ten drugi rodzaj: według Mandiant nic w jego wdrożeniu nie ograniczało pętli, a mechanizmy kontrolne, które by ją wychwyciły — limit, ograniczenie szybkości, wyłącznik awaryjny — to zwykłe środki zastosowane do nietypowego obciążenia.

Te trzy przypadki nie mają wspólnej przyczyny. Jeden to problem zaufania: rekomendacja asystenta miała autorytet rekomendacji współpracownika. Jeden to problem z poświadczeniami, który istniał przed jakimkolwiek modelem, a modele sprawiały, że po dostaniu się do środka włamanie było szybsze i bardziej adaptacyjne. Trzeci nie jest ani jednym, ani drugim: nie ma napastnika ani exploitu, jest tylko agent z prawem zapisu do księgi i bez limitu na to, ile mógł wydać na naprawę zepsutego narzędzia. Łączy je to, że w każdym z nich system AI miał uprawnienia, których nikt nie określił zakresu — do rekomendowania, do rekonfigurowania, do ponawiania prób.