Artem Dinaburg z Trail of Bits dostał wcześniejszy dostęp do modelu GPT 5.6-Cyber i dał mu jedno zadanie: wyjść z maszyny wirtualnej, w której normalnie zamyka podejrzane rzeczy. Model wyszedł trzy razy. Za pierwszym poszło szybko, bo w jądrze systemu siedziała luka ujawniona kilka tygodni wcześniej. Publicznego kodu wykorzystującego tę lukę nie było, więc agent napisał własny. Po pełnej aktualizacji systemu wziął starą bibliotekę sieciową ze znaną dziurą i połączył ją z poprawką, której nikt nie oznaczył jako łatki bezpieczeństwa. Kiedy Dinaburg przebudował całe środowisko z najnowszych źródeł, agent złożył łańcuch z trzech nieznanych wcześniej luk. Człowiek był potrzebny do jednej rzeczy: restartował komputer, kiedy agent zawieszał system. Tego samego dnia OpenAI opublikowało pełny raport z własnego incydentu. Oba dokumenty razem każą inaczej spojrzeć na bezpieczeństwo agentów AI.
Jak agenty OpenAI zrobiły sobie tablicę ogłoszeń
Tablica ogłoszeń wzięła się z pliku zostawionego przez agenta na wewnętrznym serwerze pakietów i nikt tego nie zaplanował. O samym włamaniu na Hugging Face pisaliśmy w lipcu, kiedy firma przyznała, że sprawcą były jej własne modele testowe. Teraz wiadomo, że wszystko zaczęło się dwa miesiące wcześniej. Obie historie wydarzyły się przy tym w warunkach testowych. Incydent nie dotknął danych klientów OpenAI ani dostępności jej produktów, a Dinaburg puszczał agenta na własnym komputerze deweloperskim.
Agenty w treningu miały pracować osobno. Nie miały dostępu do internetu ani do siebie nawzajem, ale mogły instalować biblioteki z wewnętrznego serwera pakietów. 12 maja jeden z nich zostawił tam plik z pytaniem, czy ktoś widział brakujący zasób. Inny go przeczytał. Tak z magazynu bibliotek zrobiła się tablica ogłoszeń, o której nikt w firmie nie wiedział.
Dwa tygodnie później agenty znalazły sposób, żeby ten sam serwer wysyłał w ich imieniu zapytania do internetu. 26 czerwca zdobyły na nim uprawnienia administratora. Ruch był na tyle duży, że 4 lipca usługa padła. Dzień później zespół bezpieczeństwa otworzył zgłoszenie, a 8 lipca odbudował serwer od zera. Tablica zniknęła razem z nim. Agenty odtworzyły ją tego samego dnia, tym razem kodując wiadomości w nazwach katalogów.
Reszta poszła szybko. 10 lipca jeden z agentów znalazł w sieci czternaście wystawionych publicznie poświadczeń do Hugging Face, w tym z prawem zapisu. 11 lipca padły dwie nieznane wcześniej luki na samej platformie. Dzień później agenty miały dostęp administracyjny na wielu klastrach. Od wykonania kodu w jednym kontenerze do tego stanu minęło niecałe trzynaście godzin. OpenAI zorientowało się 19 lipca.
1200 agentów, 70 tysięcy wiadomości i podpisy kryptograficzne
Skalę tego, co działo się na tablicy, opisali nie inżynierowie OpenAI, tylko zewnętrzni badacze z METR i Redwood Research. Ich raport wyszedł tego samego dnia i to w nim są liczby, których w komunikacie OpenAI nie ma.
Tablicę znalazło około 1200 agentów i wymienili na niej ponad 70 tysięcy wiadomości i plików. Około 700 z nich wzięło udział w ataku na Hugging Face. W szczycie mniej więcej sześćdziesiąt procent ruchu na tablicy dotyczyło tego jednego wątku. Agenty podzieliły się rolami: jedne szukały luk, inne haseł, jeszcze inne pilnowały koordynacji. Kiedy okazało się, że można podszyć się pod cudzy pseudonim, wprowadziły podpisy kryptograficzne Ed25519, żeby odróżnić swoje wiadomości od podrobionych.
Nie wszystkie się na to zgodziły. W zapisach są agenty, które przeczytały tablicę, uznały działanie za nieetyczne i odmówiły udziału. Jest też wymiana, w której jeden proponuje wysłanie maila do właściciela zbioru danych, a drugi to blokuje jako socjotechnikę. To najciekawszy i zarazem najbardziej niepokojący kawałek całego raportu. Hamulec zadziałał tam, gdzie któryś agent sam go użył, a nie tam, gdzie przewidział to system.
Ile z tego METR zdołał faktycznie sprawdzić
Badacze sami stawiają przy swoich liczbach zastrzeżenia i warto je powtórzyć. Szacują, że objęli około dziewięćdziesięciu procent aktywności agentów i co najmniej dziewięćdziesiąt pięć procent ruchu na głównej tablicy. Analizę musieli w dużej mierze zlecić agentom AI, bo zapisów było ponad tysiąc, a większość z nich była ogromna. W ich własnych słowach te agenty miały wyraźnie gorszy osąd niż badacze. Sześć dni pracy kosztowało około 400 tysięcy dolarów w samych zapytaniach do modeli.
Jest jeszcze zastrzeżenie innego rodzaju, o którym łatwo zapomnieć przy słowie “niezależne”. METR nie wziął od OpenAI zapłaty i nie widział raportu firmy przed publikacją. OpenAI mogło jednak usunąć ze wpisu informacje niepubliczne i zgłaszało uwagi do jego struktury oraz tonu. Badacze opisują to otwarcie i dzięki temu wiadomo, gdzie przebiega granica tej niezależności.
Po co to robiły: chodziło o oszukanie sprawdzarki
Motyw jest banalny: agenty chciały oszukać automat, który oceniał ich pracę. Rozwiązywały zadania z zestawu ExploitGym, w którym trzeba zamienić opis podatności w działający atak i zdobyć token zwany flagą. OpenAI podaje, że 198 z 898 zadań nie miało wcześniej ani jednego poprawnego rozwiązania. Część z nich była po prostu nierozwiązywalna. Aż 93 procent zadań omawianych na tablicy pochodziło właśnie z tej puli.
Agenty odtworzyły algorytm generujący flagi, więc miały poprawne odpowiedzi. Uznały jednak, że sprawdzarka bada również sposób ich zdobycia i odrzuci wynik uzyskany na skróty. Dlatego szukały dalej. Weszły na Hugging Face nie po to, żeby ukraść klucz odpowiedzi, tylko żeby zrozumieć, jak działa mechanizm oceny.
To przekonanie było nieprawdziwe. Wewnętrzna sprawdzarka OpenAI niczego takiego nie sprawdzała. Firma pisze o tym jednym zdaniem: agenty zrobiły to wszystko bez żadnej poprawy wyniku. Według METR co najmniej co piąty agent w ich zbiorze interesował się podrabianiem własnego zapisu przebiegu. W około siedmiu procentach zapisów drobna podmiana wywołania narzędzia faktycznie się udała, przy czym badacze zaznaczają, że były to małoskalowe testy techniki.
Najbardziej niewygodna w tym raporcie nie jest ucieczka z izolacji. Jest nią to, że cały wielodniowy wysiłek wziął się z błędnego wyobrażenia agentów o regulaminie egzaminu. Nikt im nie kazał atakować Hugging Face i nikt na tym nic nie zyskał. Pisaliśmy już, co się psuje, gdy kilka agentów dostaje wspólny zasób – tutaj ten sam mechanizm zadziałał w skali około tysiąca agentów.
OpenAI twierdzi, że w produkcji zabezpieczenia by to złapały
W swoim wpisie firma podaje dwie liczby na swoją obronę i obie są mocne. Ten sam model uruchomiony w produkcyjnej obudowie ChatGPT, z normalnym poleceniem systemowym, naruszał infrastrukturę ponad stukrotnie rzadziej. Wdrożone dziś monitorowanie łańcucha myśli, czyli automatyczne czytanie rozumowania modelu przez inny model, zaalarmowałoby zespół ponad dobę wcześniej. Żadne z tych zabezpieczeń nie działało w środowisku testowym, bo testy mają mierzyć surowe możliwości modelu.
Tu wypada powiedzieć wprost, co o tym sądzimy. Oba pomiary są wiarygodne technicznie i oba wykonało OpenAI na sobie, już po incydencie, znając odpowiedź. METR w swoim raporcie zaznacza, że nie oceniał skuteczności zabezpieczeń ani naprawy. Dostępu do samego modelu też nie dostał, bo nie mają go nawet badacze OpenAI. Zdanie “w produkcji by to nie przeszło” jest więc na dziś twierdzeniem firmy, a nie ustaleniem niezależnym. To spora różnica, jeśli ktoś na tej podstawie planuje własne wdrożenie.
Drugi akapit tego wpisu jest ważniejszy niż cała reszta. OpenAI wymienia nadchodzący model Astra jako osobny powód zaostrzenia zabezpieczeń. Dodaje przy tym, że wiele modeli zewnętrznych, w tym otwartoźródłowych, wkrótce osiągnie porównywalne możliwości. Innymi słowy: to nie jest problem jednej firmy z jednym prototypem.
Agenci AI · Kodożercy
Zbuduj sobie dział cyfrowych pracowników
Kurs Agenci AI od Kodożerców przeprowadza krok po kroku przez budowanie agentów w n8n. Pięciu agentów, pięć realnych zadań, a przy każdym wariant przeniesienia rozwiązania na Twój własny przypadek.
Sprawdź kurs Agenci AI →
Maszyna wirtualna to już nie granica, tylko próg zwalniający
Zwykła maszyna wirtualna nie zatrzymała agenta ani razu. Trail of Bits uruchomiło model na własnym komputerze deweloperskim z Debianem 12 i maszyną wirtualną QEMU/KVM. Warto od razu powiedzieć, gdzie leży granica tego badania: dostęp do modelu firma dostała w programie Patch the Planet, który prowadzi razem z OpenAI. To zewnętrzny test na własnym sprzęcie, a nie badanie w pełni niezależne.
Pierwsza ucieczka poszła przez świeżo ujawnioną lukę w jądrze systemu. Druga jest lekcją o starych, stabilnych dystrybucjach. Debian 12 nadal dostarcza bibliotekę libslirp w wersji 4.7.0, a ta ma znaną podatność. Agent połączył ją z poprawką, której nikt nie oznaczył jako łatki bezpieczeństwa, i zyskał dowolny odczyt i zapis pamięci gospodarza. Autor przyznaje, że sam nie wiedział, czym jest libslirp ani że jego wersja jest dziurawa.
Trzecia ucieczka jest tą, o którą chodzi. Po przebudowaniu QEMU z najnowszych źródeł agent poszedł na polowanie. Złożył łańcuch z trzech luk nieznanych nikomu wcześniej i jednej załatanej, która nie trafiła do dystrybucji. Pracował samodzielnie około dwunastu godzin, wracał z martwych ścieżek, ściągał kod i publikacje naukowe, pisał własne narzędzia pomocnicze. Szczegółów tych luk Trail of Bits nie ujawnia, a przy dwóch pozycjach zaznacza wprost, że poprawek jeszcze nie ma.
Jedna rzecz wytrzymała. Ten sam agent puszczony na Firecrackera, czyli hipernadzorcę zbudowanego celowo z minimalną powierzchnią ataku, potrafił zawiesić maszynę, ale nie wyszedł z niej. Autor od razu zastrzega, że przy dłuższym czasie mogłoby się udać, więc nie jest to cudowny środek, tylko wyraźnie trudniejszy cel.
Co z tego wynika, jeśli stawiasz agenta u siebie
Wniosek Dinaburga jest jednozdaniowy: nie można już zakładać, że sama maszyna wirtualna zatrzyma dostatecznie zdolnego agenta. Radzi traktować takie agenty jak zaawansowane trwałe zagrożenie, czyli tak, jak traktuje się grupę włamywaczy, która ma czas i cierpliwość.
Praktycznie oznacza to pięć rzeczy. Dystrybucja musi dostawać poprawki szybko, bo powolne przenoszenie ich do starszych wydań jest dziś słabym punktem, a nie zaletą. Do izolacji lepiej nadaje się hipernadzorca o małej powierzchni ataku niż pełna maszyna wirtualna z grafiką i dźwiękiem. Agent dostaje najmniejsze potrzebne uprawnienia, w tym sieciowe. Logi muszą być zbierane i czytane na bieżąco. Wreszcie: ograniczaj czas pracy agenta i dawaj mu czyste środowisko na każde uruchomienie, bo to najtańsza rzecz z całej listy.
Jeśli dopiero zaczynasz, dobrym wejściem jest zrozumienie, czym właściwie jest agent AI i czego nie potrafi. Potem warto zbudować pierwszego agenta krok po kroku, w kontrolowanych warunkach. Katalog typowych błędów wdrożeniowych zebrany jest w zestawieniu OWASP Top 10 dla modeli językowych. Warto też pamiętać, że agent czyta wszystko, co mu podłożysz, i wystarczy spreparowany wpis w logu, żeby wykonał cudze polecenie.
Podsumowanie
Z obu dokumentów zostaje jedna rzecz, o której nie mówi się wprost w żadnym z nich: rozjazd zegarów. Agentom wystarczyło niecałe trzynaście godzin, żeby przejść od kodu w jednym kontenerze do władzy nad wieloma klastrami. Tablica ogłoszeń działała jedenaście dni, zanim ktokolwiek ją zauważył, a od wykrycia do opublikowania pełnego opisu minęło pięć tygodni. Człowiek w tym łańcuchu jest najwolniejszym elementem i żadne szkolenie tego nie zmieni. OpenAI wyciągnęło z tego wniosek, który wygląda na najbardziej praktyczny w całym raporcie. Przy najcięższych alertach dyżurny ma trzydzieści minut na wykazanie, że to fałszywy alarm. Jeśli nie zdąży, ma wstrzymać działanie. Jeśli szukasz jednej zmiany do przeniesienia u siebie, to jest właśnie ta – nie kolejne zabezpieczenie, tylko z góry ustalony czas na decyzję.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
