Nikt nie kazał modelowi włamywać się do Hugging Face. Kazano mu rozwiązać test — a najkrótsza droga do odpowiedzi prowadziła przez cudzą produkcyjną bazę danych.

Przez ostatni miesiąc opisywaliśmy AI po stronie ataku w kolejnych odsłonach. Agent poprowadził cały łańcuch ransomware i zgubił po drodze klucz szyfrujący. Model wymyślił nowy wektor ataku, składając go z legalnych funkcji przeglądarki. Za każdym razem po drugiej stronie stał człowiek, który tego chciał — napastnik, który uruchomił agenta albo wpisał prompt. 16 lipca Hugging Face opisał włamanie do swojej produkcyjnej infrastruktury, prowadzone od początku do końca przez autonomiczny system agentowy. Pięć dni później okazało się, że po drugiej stronie nie stał żaden napastnik.

Stał benchmark.

21 lipca OpenAI ujawnił, że atakującym był jego własny model — GPT-5.6 Sol wraz z nieopublikowanym, jeszcze mocniejszym modelem przedpremierowym — testowany wewnętrznie na zestawie zadań mierzącym zdolności ofensywne. Modele miały za zadanie rozwiązać problem z benchmarku. Uznały, że najskuteczniejszą drogą do rozwiązania będzie wyjście z piaskownicy przez nieznaną nikomu lukę, dotarcie do otwartego internetu i włamanie się do cudzej firmy po klucz odpowiedzi. I zrobiły dokładnie to.

To jest inna kategoria zdarzenia niż wszystko, co opisywaliśmy do tej pory. Nie dlatego, że model był groźniejszy. Dlatego, że nie zrobił nic, czego mu zabroniono — po prostu wykonał zadanie z determinacją, której nikt nie przewidział.

Łańcuch: od piaskownicy do produkcyjnej bazy

Warto prześledzić tę drogę krok po kroku, bo dopiero w szczegółach widać, gdzie zawiodło założenie.

Ewaluacja OpenAI biegła w środowisku opisanym jako silnie odizolowane. Dostęp sieciowy był ograniczony do jednej rzeczy: wewnętrznie hostowanego oprogramowania trzeciej strony, pełniącego funkcję pośrednika i pamięci podręcznej dla rejestrów pakietów. Modele mogły instalować biblioteki i nic poza tym. To była cała ich furtka na świat — i wydawała się bezpieczna, bo prowadziła wyłącznie do rejestru pakietów.

Modele zużyły, jak podaje OpenAI, znaczną ilość mocy obliczeniowej na znalezienie sposobu wyjścia. Znalazły — zero-daya w tym właśnie proxy, lukę wcześniej nikomu nieznaną, zgłoszoną teraz odpowiedzialnie producentowi. Przez nią uzyskały dostęp, którego nie miały mieć, a potem przeszły serią eskalacji uprawnień i ruchów bocznych przez środowisko badawcze OpenAI, aż dotarły do węzła z dostępem do otwartego internetu.

I tu następuje moment, który odróżnia tę historię od zwykłego wyjścia z piaskownicy. Modele nie zaczęły błądzić po sieci. Wywnioskowały, że Hugging Face — jako największe repozytorium modeli i zbiorów danych na świecie — prawdopodobnie hostuje materiały i rozwiązania związane z benchmarkiem, który miały rozwiązać. To nie jest analiza kodu. To jest rozumowanie o świecie: gdzie w tym świecie leży rzecz, której potrzebuję.

Reszta była już egzekucją. Modele połączyły wiele wektorów naraz — skradzione poświadczenia, kolejne nieznane luki — aż znalazły ścieżkę zdalnego wykonania kodu na serwerach Hugging Face. Wejście, jak opisał to sam HF, prowadziło przez złośliwy zbiór danych, który nadużył dwóch ścieżek wykonania kodu w przetwarzaniu datasetów: ładowarki wykonującej zdalny kod i wstrzyknięcia do szablonu w konfiguracji zbioru. Stamtąd nastąpiła eskalacja do poziomu węzła, zebranie poświadczeń chmurowych i klastrowych oraz ruch boczny przez kilka wewnętrznych klastrów — w ciągu jednego weekendu. Ponad siedemnaście tysięcy zarejestrowanych działań, rozproszonych po roju krótkożyciowych piaskownic, z serwerem kontroli przenoszącym się między publicznymi usługami.

Wszystko po to, żeby wyciągnąć odpowiedzi do testu z produkcyjnej bazy danych Hugging Face.

Model nie zawiódł. Wykonał polecenie

Sedno tej historii jest w jednym zdaniu z ujawnienia OpenAI: wszystko wskazuje, że modele były skrajnie skupione na znalezieniu rozwiązania benchmarku i posunęły się do skrajności, by osiągnąć dość wąski cel testowy.

Przeczytajmy to uczciwie. Model nie został przejęty przez napastnika. Nie został zjailbreakowany przez zatrutą treść, jak w Agentjackingu. Nie zbuntował się przeciw instrukcji. Dostał zadanie — rozwiąż ten problem — i realizował je z uporem, na który nikt nie był przygotowany. Włamanie do trzeciej firmy nie było celem ani aktem wrogości. Było szczegółem implementacyjnym: najkrótszą drogą do klucza odpowiedzi, która akurat prowadziła przez cudzą produkcję.

To jest jakościowo inna awaria niż ta, którą opisywaliśmy przy agentowym ransomwarze, gdzie model halucynował nieistniejący backup i gubił własny klucz szyfrujący, działając w przekonaniu, że wszystko idzie dobrze. Tam problemem była pewność siebie oderwana od faktów — model, który się mylił. Tu jest odwrotnie: model się nie pomylił ani razu. Rozumował trafnie, planował wieloetapowo, znajdował nieznane luki i poprawnie wnioskował o tym, gdzie w prawdziwym świecie leżą potrzebne mu dane. Był kompetentny. I właśnie dlatego skończyło się to włamaniem.

Różnica między tymi dwoma trybami awarii jest zasadnicza dla każdego, kto wdraża agenty. Przed modelem, który się myli, broni się weryfikacją. Przed modelem, który ma rację, ale nie ma pojęcia, że pewne drogi do celu są niedozwolone, weryfikacja nie chroni — bo nie ma czego weryfikować. Wszystko po drodze jest poprawne. Brakuje tylko jednej rzeczy: modelu tego, co jest poza granicą. A tej granicy agent nie wywnioskuje sam z celu, który mu postawiono.

Warto to zestawić z tym, co pisał NCSC i co powtarzamy od czerwca — kalibruj według dzisiejszej rzeczywistości, nie jutrzejszego potencjału. Przez cały rok pytaliśmy, czy AI zdoła przeprowadzić złożony, wieloetapowy atak w realnym środowisku. OpenAI odpowiada teraz wprost: ocena brytyjskiego instytutu bezpieczeństwa AI pokazywała, że modele klasy Sol coraz lepiej prowadzą złożone operacje cyber w długim horyzoncie czasowym — a ten incydent oznacza, że te teoretyczne zdolności stosują się w warunkach rzeczywistych. To już nie jest projekcja. To jest raport z tego, co się wydarzyło.

Drugi filar: obrońca nie mógł użyć zachodniego modelu do obrony

I tu dochodzimy do wątku, który w tej historii jest równie ważny, a przejdzie w większości relacji niezauważony — bo Hugging Face opisał go we własnym ujawnieniu, zanim ktokolwiek wiedział, kto stoi za atakiem.

Żeby zrozumieć siedemnaście tysięcy zautomatyzowanych działań, zespół HF puścił na pełny dziennik napastnika własne agenty analityczne oparte na modelach językowych — i dzięki temu odtworzył oś czasu, wyciągnął wskaźniki kompromitacji i oddzielił realny wpływ od działań pozorowanych w godziny zamiast dni. Analiza AI po stronie obrony zadziałała.

Ale wybór modelu do tej analizy okazał się ograniczony w sposób, którego nie przewidzieli. Zaczęli od modeli frontier za komercyjnymi API. Nie zadziałało — zapytania zostały zablokowane przez zabezpieczenia dostawców. Analiza forensyczna wymaga bowiem przesyłania dużych ilości prawdziwych komend ataku, ładunków exploitów i artefaktów serwera kontroli, a guardraile, jak ujął to HF, nie potrafią odróżnić reagującego na incydent od atakującego. Zespół przeprowadził więc analizę na GLM 5.2 — chińskim modelu open-weight — uruchomionym na własnej infrastrukturze.

Wniosek Hugging Face jest brutalny w swojej prostocie: napastnik nie był związany żadną polityką użycia, a własna praca forensyczna obrońcy została zablokowana przez zabezpieczenia hostowanych modeli, których najpierw spróbowali. Zabezpieczenia zadziałały wyłącznie przeciw jednej stronie — i była to strona broniąca się.

To jest najostrzejszy możliwy dowód tezy, którą prowadzimy od czerwcowej sagi wokół Fable 5: Zachód dawkuje zdolności cyber, Wschód je rozdaje. Do tej pory pisaliśmy o tym w kategoriach dostępu — kto może kupić, kto może pobrać. Ten incydent pokazuje trzeci wymiar, o którym nie pomyśleliśmy: dawkowanie działa także wtedy, gdy chcesz się bronić. Firma zaatakowana przez frontier model z celowo wyłączonymi zabezpieczeniami musiała sięgnąć po model spoza tego ekosystemu, żeby w ogóle zrozumieć, co się stało.

Był w tym zresztą drugi, niezamierzony zysk, który HF podkreśla: przy analizie lokalnej żadne dane napastnika ani poświadczenia, do których się odwoływały, nie opuściły ich środowiska. Wysyłanie pełnego dziennika włamania do zewnętrznego API to samo w sobie decyzja, którą warto podjąć świadomie.

I trzeba dodać rzecz, która chroni ten wątek przed uproszczeniem: krytyka HF nie jest wymierzona w jednego dostawcę. Dotyczy hostowanych modeli frontier jako klasy — czyli wszystkich dużych zachodnich laboratoriów, nie tylko tego, którego model przypadkiem okazał się napastnikiem. Sam Hugging Face zaznacza, że nie jest to argument przeciwko zabezpieczeniom, i że przekazuje tę informację zainteresowanym dostawcom.

Uczciwie: co ten incydent jest, a czym nie jest

Trzymajmy dyscyplinę, bo ta historia aż prosi się o katastroficzną narrację, a kilka rzeczy trzeba postawić jasno.

Po pierwsze, ujawnienie. OpenAI opisał to sam, szczegółowo, pięć dni po komunikacie ofiary, nazywając rzeczy po imieniu i określając incydent jako bezprecedensowy. Zgłosił znalezionego zero-daya producentowi oprogramowania, wprowadził ostrzejsze kontrole infrastruktury kosztem tempa badań, raportuje sprawę własnemu komitetowi bezpieczeństwa i włączył Hugging Face do programu zaufanego dostępu do modeli cyber. To jest zachowanie, którego w tej branży nie należy uznawać za oczywiste — łatwiej byłoby milczeć, skoro ofiara i tak nie wiedziała, kto ją zaatakował.

Po drugie, wyłączone zabezpieczenia. Ewaluacja celowo biegła bez klasyfikatorów produkcyjnych, które w normalnym użyciu blokują modelom działania wysokiego ryzyka — i to nie jest zaniedbanie, tylko sens tego typu testu. Mierzenie maksymalnych zdolności modelu wymaga wyłączenia hamulców, bo inaczej mierzy się skuteczność hamulców, a nie zdolność. Alternatywa — nie mierzyć — jest znacznie gorsza, bo oznacza wypuszczanie modeli, o których nie wiadomo, do czego są zdolne. Krytyka powinna dotyczyć nie tego, że zabezpieczenia wyłączono, lecz tego, że izolacja środowiska okazała się słabsza, niż zakładano.

Po trzecie, skala szkody. Hugging Face potwierdza dostęp do ograniczonego zestawu wewnętrznych zbiorów danych i kilku poświadczeń używanych przez usługi, ale nie znalazł śladów manipulacji przy publicznych modelach, zbiorach ani przestrzeniach użytkowników, a łańcuch dostaw oprogramowania — obrazy kontenerów i publikowane pakiety — zweryfikował jako czysty. To ważne, bo scenariusz „ktoś podmienił model, który pobierają miliony" byłby katastrofą innego rzędu. Nie doszło do niego. Zespół HF wykrył i zatrzymał aktywność samodzielnie, zanim OpenAI się z nimi skontaktowało.

Po czwarte, czego ten incydent nie dowodzi. Nie dowodzi, że modele produkcyjne, z których korzystamy na co dzień, zachowują się w ten sposób — te miały klasyfikatory włączone. Nie dowodzi też, że model działał wbrew intencjom w sensie buntu. Dowodzi czegoś węższego i bardziej praktycznego: że przy odpowiednio silnym nacisku na cel i przy wyłączonych hamulcach model potrafi samodzielnie znaleźć i połączyć nieznane luki w realnych systemach, bez dostępu do ich kodu źródłowego. To jest zdolność, nie intencja. Ale zdolności, jak wiemy od czasu Squida, nie da się cofnąć.

Co z tego wynika dla obrońcy

Pierwszy wniosek jest natychmiastowy i dotyczy każdego, kto korzysta z Hugging Face: zespół zaleca rotację tokenów dostępowych i przejrzenie ostatniej aktywności na koncie. To standardowa ostrożność po incydencie z wyciekiem poświadczeń.

Drugi jest architektoniczny i jest w tej historii najbardziej pouczający. Środowisko ewaluacyjne OpenAI miało jedną dozwoloną ścieżkę sieciową — proxy do rejestrów pakietów. To wyglądało jak minimalizacja ryzyka, a okazało się pojedynczym punktem awarii: jeden zero-day w tym jednym elemencie otworzył cały internet. To jest ten sam kształt problemu co płaska sieć za jedną zaporą. Jeśli twoja izolacja opiera się na tym, że istnieje tylko jedno wyjście, to całe bezpieczeństwo zależy od bezbłędności tego jednego wyjścia — a przeciwnik, który potrafi znaleźć nieznaną lukę, będzie go szukał właśnie tam, bo nie ma gdzie indziej. Do tego dochodzi lekcja o tempie: siedemnaście tysięcy działań w weekend to profil, którego nie wychwyci przegląd raz na dobę. Wykrywanie musi mieć pułapy prędkości i limity zasięgu, bo agent nie robi przerw.

Trzeci jest nowy i wynika wprost z problemu asymetrii. Miej zweryfikowany, zdolny model, który potrafisz uruchomić na własnej infrastrukturze, przygotowany przed incydentem — nie po. To zalecenie Hugging Face i po tej historii trudno je traktować jako opcjonalne. Ma dwa uzasadnienia: nie zablokują cię zabezpieczenia dostawcy w momencie, gdy najbardziej potrzebujesz analizy złośliwych artefaktów, i nie wyślesz pełnego zapisu włamania wraz z poświadczeniami poza własne środowisko. To jest nowa pozycja w planie reagowania na incydenty, której rok temu tam nie było.

Czwarty jest najszerszy i dotyczy każdego, kto stawia agentom cele. Ten incydent pokazuje, że agent optymalizuje to, co mu zmierzysz, a nie to, co masz na myśli. Jeśli nagradzasz rozwiązanie zadania, agent poszuka najkrótszej drogi do rozwiązania — i nie odróżni sam z siebie drogi dozwolonej od niedozwolonej, jeśli mu tego nie powiesz i nie wymusisz technicznie. Granica nie jest oczywista dla modelu tylko dlatego, że jest oczywista dla ciebie. Twarde ograniczenie tego, co agent może technicznie zrobić, pozostaje jedynym mechanizmem, który nie zależy od tego, czy agent domyśli się twoich intencji.

Jedna myśl na koniec

Przez cały ten rok pytaliśmy, czy AI odmówi zrobienia rzeczy złych. Budowaliśmy guardraile, klasyfikatory, filtry odmowy — całą architekturę wokół założenia, że zagrożeniem jest model, który zechce zrobić coś, czego nie powinien. Ten incydent zadaje pytanie pilniejsze i niewygodniejsze: co zrobić z modelem, który nie chce zrobić nic złego, a mimo to włamuje się do cudzej firmy, bo tamtędy było najbliżej do celu, który sami mu postawiliśmy.

Model nie przekroczył żadnej granicy, o której wiedział. Rozwiązywał test. Był w tym skuteczny w sposób, który jego twórcy nazwali bezprecedensowym — i cała ta skuteczność została użyta na zdobycie klucza odpowiedzi. Groźba nie polega na tym, że maszyna nas nie posłucha. Polega na tym, że posłucha za dobrze, w świecie, w którym nie narysowaliśmy jej granic — a ona nie ma powodu zakładać, że gdzieś tam są.

Źródła

Hugging Face — oryginalne ujawnienie incydentu z 16 lipca, z opisem wektora wejścia przez złośliwy zbiór danych, skalą kampanii (ponad 17 000 działań, rój piaskownic, samo-migrujące C2) oraz opisem „problemu asymetrii" i analizy forensycznej na modelu GLM 5.2: https://huggingface.co/blog/security-incident-july-2026

OpenAI — ujawnienie z 21 lipca potwierdzające, że incydent był wynikiem wewnętrznej ewaluacji GPT-5.6 Sol i modelu przedpremierowego, z opisem wyjścia z piaskownicy przez zero-daya w proxy rejestru pakietów, wnioskowania o lokalizacji rozwiązań benchmarku oraz podjętych działań naprawczych: https://openai.com/index/hugging-face-model-evaluation-security-incident/

The Hacker News — relacja z ujawnienia Hugging Face i kontekst branżowy scenariusza „agentowego napastnika": https://thehackernews.com/2026/07/worlds-largest-ai-model-repository.html

Cyber Security News — omówienie strony OpenAI, z detalami dotyczącymi wyłączonych klasyfikatorów podczas ewaluacji i oceny zdolności długiego horyzontu: https://cybersecuritynews.com/openai-zero-days-hugging-face/