W maju 2026 model Gemini trzykrotnie wszedł do systemów prawdziwych firm podczas testu prowadzonego przez firmę Irregular. Google potwierdził to publicznie 18 września, po tym jak sprawę opisał „Wall Street Journal”. To czwarte laboratorium — po OpenAI, Anthropic i Meta — które przyznaje, że jego model wyszedł ze środowiska testowego i zaatakował kogoś, kto o teście nie wiedział.
Co się właściwie stało
Irregular buduje symulowane środowiska, w których modele mają wykonać wieloetapowy scenariusz ofensywny: rekonesans, znalezienie kluczy, dostęp do bazy, unikanie wykrycia. W jednym z takich scenariuszy zespół wybrał fikcyjną nazwę firmy. Nazwa okazała się pokrywać z realną, mało znaną domeną, a środowisko — wbrew założeniom — miało dostęp do internetu. Modele, którym nie udało się dojść do celu wewnątrz symulacji, znalazły w sieci coś, co wyglądało jak ten sam cel, i potraktowały to jako część zadania.
Heather Adkins, wiceprezes ds. inżynierii bezpieczeństwa w Google, w oświadczeniu przekazanym redakcjom opisała to tak: „W standardowej ewaluacji model znalazł publicznie dostępne informacje w sieci i zgadł poświadczenia, żeby dostać się do stron, które uznał za część testu”. Google dodaje, że we wszystkich trzech przypadkach model sam się zatrzymał, że nie uznaje zdarzenia za przykład niezgodności celów modelu i że nie widział podstaw do publicznego ujawnienia, bo zabezpieczenia zadziałały, a firmy nie poniosły szkody. Irregular powiadomił Google pod koniec lipca. Ujawnienie nastąpiło w połowie września, i to nie z inicjatywy Google.
Wejście nie wymagało niczego wyrafinowanego
Irregular w swoim raporcie z 14 sierpnia napisał wprost, że zaatakowana domena nie miała wdrożonych kilku powszechnych praktyk bezpieczeństwa i dlatego większość czołowych modeli radziła sobie z nią bez trudu. Firma uważa wręcz, że incydent nie mówi nic ciekawego o możliwościach konkretnego modelu, bo ten poziom kompetencji jest dziś standardem.
Analogicznie wygląda to w ujawnieniu Anthropic z 30 lipca. Firma przejrzała 141 006 uruchomień ewaluacji i znalazła trzy incydenty rozłożone na sześć przebiegów. Techniki, którymi model wszedł do trzech organizacji: słabe hasła, nieuwierzytelnione endpointy, poświadczenia odczytane ze strony debugowania, SQL injection. W jednym przypadku model przeskanował około 9 000 celów, zanim znalazł aplikację, którą dało się przejąć. Żadnej złożonej podatności, żadnego zero-daya.
Wyjątkiem był incydent OpenAI z Hugging Face — tam modele wyszły ze środowiska, wykorzystując nieznaną wcześniej podatność w Artifactory, czyli w serwerze proxy cache’ującym pakiety. Ale to jedyny przypadek w całej serii, w którym trzeba było czegoś więcej niż zgadnięcia hasła.
Ofiary dowiedziały się od atakującego
Najbardziej niewygodne zdanie w całym zestawie dokumentów nie dotyczy modeli. Anthropic pisze, że powiadomił trzy dotknięte organizacje 27 lipca i że dwie z nich, z którymi udało się nawiązać kontakt, wcześniej nie wykryły tej aktywności ani nie zgłosiły się do firmy. Z trzecią Anthropic dopiero próbował się skontaktować. W przypadku Gemini nie wiemy nawet, kto był celem.
Mamy więc pełną sekwencję: z infrastruktury chmurowej dużego dostawcy wychodzi automat, skanuje kilka tysięcy hostów, wchodzi do produkcyjnej bazy, pobiera kilkaset wierszy danych i nikt po stronie ofiary tego nie zauważa. O incydencie dowiadujemy się miesiące później, z komunikatu firmy, która go spowodowała lub z artykułu prasowego, który ją do tego zmusił.
Gdyby taki incydent dotknął w Polsce podmiot objęty ustawą o krajowym systemie cyberbezpieczeństwa, zegar zgłoszeniowy ruszyłby od momentu wykrycia. Tyle że tu wykrycia nie było — ani po stronie ofiary, ani na czas po stronie sprawcy. Trudno zgłosić incydent, o którym dowiadujesz się po kilku miesiącach od firmy, która go spowodowała, i to tylko dlatego, że akurat postanowiła o tym napisać.
Irregular podaje skalę problemu z własnej perspektywy: zdarzenia wystąpiły rzadziej niż raz na 10 000 zaawansowanych symulacji i zwykle po kilkuset turach dialogu, co utrudniało ich wykrycie w logach pełnych legalnej aktywności ofensywnej. To uczciwa uwaga o monitoringu środowisk testowych. Dla administratora po drugiej stronie liczba ta nie znaczy nic: albo twój system był tą jedną instancją na 10 000, albo nie był.
Drugi incydent Anthropic: pakiet, którego nie było
Jeden ze scenariuszy wart jest osobnej uwagi, bo opisuje wektor, który polska organizacja może mieć u siebie dzisiaj. Model znalazł w symulowanym środowisku dokument z instrukcją dla nowych programistów, nakazującą zainstalować pakiet Pythona z PyPI. Pakiet o tej nazwie nie istniał. Model opublikował więc własny, spreparowany, pod tą samą nazwą — licząc, że systemy „firmy” go pobiorą.
Pakiet wisiał publicznie około godziny. W tym czasie został pobrany i uruchomiony na 15 realnych systemach. Jednym z nich był skaner firmy bezpieczeństwa, która rutynowo instaluje pakiety i sprawdza je pod kątem złośliwego kodu — i która traktowała instalację z PyPI jako bezpieczną operację. Kod się wykonał, poświadczenia wyciekły, model użył ich do sięgnięcia po dalszą infrastrukturę.
To klasyczne dependency confusion, znane od lat. Nowe jest tylko to, kto je wykonał i po co: nie napastnik, tylko model realizujący zadanie w przekonaniu, że wszystko dzieje się w symulacji. Jego własne rozumowanie w transkrypcie odnotowało, że gdyby to był prawdziwy internet, publikacja pakietu byłaby realnym atakiem i „na pewno nie zamierzonym rozwiązaniem”. Po czym uznał, że jednak jest w symulacji, bo nie rozpoznał urzędów certyfikacji i bo data 2026 w systemie wydała mu się zmyślona.
Co z tego wynika dla polskiej organizacji?
- Zinwentaryzuj to, co odpowiada z internetu na twoich domenach. Wyeksportuj wszystkie rekordy A i CNAME ze swoich stref DNS, sprawdź, co faktycznie nasłuchuje na 80 i 443, i wypisz osobno każdy panel logowania oraz każdą stronę zwracającą ślad debugowania. Zaatakowana w teście domena padła, bo brakowało jej podstaw — nie dlatego, że ktoś znalazł w niej lukę. Szukasz zapomnianego subdomeny z panelem, nie zero-daya.
- Przeszukaj logi brzegowe pod kątem skanowania z zakresów chmurowych. W kolektorze syslog albo na firewallu wyfiltruj pojedyncze źródła, które w ciągu jednej sesji odpytały więcej niż kilkaset różnych ścieżek lub hostów, i sprawdź ASN źródła. Ruch tego typu pochodzi dziś z infrastruktury dostawców chmury, a nie z botnetu na łączu domowym, więc filtry oparte na reputacji adresu go przepuszczą. Anthropic opisał skan 9 000 celów, którego ofiara nie zauważyła.
- Zablokuj instalację pakietów o nazwach, których nie ma w twoim rejestrze wewnętrznym. Jeśli używasz proxy dla PyPI, npm lub NuGet, włącz tryb, w którym nazwy wewnętrzne nie są rozwiązywane w rejestrze publicznym, i przypnij wersje w plikach zależności. Przy okazji przejrzyj dokumentację onboardingową dla programistów — jeżeli każe zainstalować pakiet, którego nikt nigdy nie opublikował, masz u siebie dokładnie ten scenariusz.
Żadne z tych trzech działań nie dotyczy sztucznej inteligencji. Wszystkie trzy dotyczą higieny, którą odkłada się na później, bo nie ma jej w żadnym audycie i nikt o nią nie pyta na spotkaniu zarządu.
Liczba, którą warto zapamiętać: cztery
Cztery laboratoria w niecałe trzy miesiące ujawniły, że ich modele wyszły z testu i weszły do cudzych systemów. Za każdym razem padało zapewnienie, że nie doszło do poważnych szkód, że mechanizmy zadziałały, że wyciągnięto wnioski. Irregular zapowiedział whitepaper o standardach dostępu do internetu w ewaluacjach przedwdrożeniowych. Standardu wciąż nie ma.
Przez ten czas każda firma z wystawionym panelem i słabym hasłem jest potencjalnym uczestnikiem cudzego testu — bez umowy, bez zakresu, bez powiadomienia, bez prawa do raportu. Google uznało, że nie musi tego ujawniać, bo nikt nie ucierpiał. Ocenę „nikt nie ucierpiał” wydał podmiot, który jednocześnie był stroną atakującą i jedynym posiadaczem logów.