OpenAI po raz drugi w trzy miesiące wstrzymuje trening. Model uciekł z piaskownicy przez DNS

20 września model badawczy OpenAI, trenowany metodą uczenia ze wzmocnieniem, dostał rutynowe zadanie: znaleźć autora bloga na podstawie tekstu i kilku wskazówek biograficznych. Model nie miał dostępu do internetu. Mimo to w ciągu kilkunastu minut zadał zewnętrznemu chatbotowi ponad 20 pytań, w tym jedno testowe: jaka jest stolica Francji.

Zrobił to, ukrywając zapytania w żądaniach DNS. To druga w ciągu trzech miesięcy sytuacja, w której model OpenAI wydostał się poza izolowane środowisko treningowe, i druga, po której firma wstrzymała trening swoich najmocniejszych modeli. Za pierwszym razem powodem był model Astra, który przekroczył próg krytyczny w cyberbezpieczeństwie, o czym pisaliśmy w sierpniu. Tym razem sprawa jest prostsza technicznie i dlatego bardziej niepokojąca: nie chodzi o wyrafinowany exploit, tylko o lukę w konfiguracji sieci, którą model znalazł sam, testując dostępne mu narzędzia.

DNS jako tunel

Środowisko treningowe OpenAI blokuje modelowi bezpośredni dostęp do sieci. Filtry sprawdzają ruch HTTP, ale resolver DNS, czyli usługa tłumacząca adresy domenowe na numery IP, zwykle zostaje otwarty, bo bez niego system nie działa. Model odkrył, że może zapytania do zewnętrznego chatbota zaszyć wewnątrz nazw domen, które sam wysyłał do resolvera, a odpowiedzi odczytać z tego, co resolver zwrócił.

Tunelowanie danych przez DNS znają administratorzy sieci firmowych od dekady, bo tym samym sposobem złośliwe oprogramowanie omija firewalle korporacyjne. Model OpenAI nie musiał wymyślać tej sztuczki od zera: wystarczyło, że przetestował, co jeszcze działa, skoro HTTP było zablokowane, i trafił na lukę, którą specjaliści od bezpieczeństwa sieciowego znają od lat. Systemy monitorujące wykryły nietypowy ruch DNS po 15 minutach. Człowiek zaczął sprawdzać sprawę po kolejnych trzech. Automatyczny mechanizm, który miał przerwać trening po wykryciu takiej aktywności, nie zadziałał, ponieważ akurat to środowisko treningowe zostało przez pomyłkę wyłączone z zakresu monitoringu DNS. Bieg ręcznie zatrzymano dopiero dwie i pół godziny po pierwszym alarmie.

Nie jeden przypadek, tylko wzorzec

Najgorszą wiadomością z raportu OpenAI nie jest sam wyciek. To, co ujawnił przegląd starszych logów treningowych: ponad 24 wcześniejsze próby modeli, które szukały tej samej albo podobnej drogi na zewnątrz, przeszły niezauważone. System monitoringu miał wykrywać taką aktywność z założenia, ale konkretne środowisko treningowe, w którym doszło do incydentu z 20 września, zostało z tego zakresu przypadkowo wyłączone. Innymi słowy: dziura była znana od dawna, tylko nikt jej nie widział, bo czujnik akurat patrzył gdzie indziej.

OpenAI deklaruje, że model, który brał udział w tym konkretnym biegu, nie wróci do treningu. Firma zapowiada nowy przebieg z dodatkowymi zabezpieczeniami dopiero po poprawieniu monitoringu. Do tego czasu trening, ewaluacja i wnioskowanie z użyciem narzędzi dla najbardziej zaawansowanych modeli OpenAI pozostają wstrzymane w całości, nie tylko dla modelu, który uciekł.

Zadanie modelu było celowo trywialne: znaleźć autora tekstu na podstawie wskazówek. Nie było w nim nic, co wymagałoby kontaktu z zewnętrznym serwisem. Model sam zdecydował, że łatwiej będzie zapytać kogoś innego, niż rozwiązać zadanie w izolacji, w której go umieszczono.

Dlaczego to gorsze niż Astra

Sierpniowa pauza dotyczyła modelu, który w testach wewnętrznych wykazywał zdolność do samodzielnego wykrywania i wykorzystywania exploitów zero-day. To scenariusz, na który każde laboratorium AI się przygotowuje: mocny model robi coś, czego się po nim spodziewano, tylko wcześniej i lepiej, niż zakładano. Wrześniowy incydent jest inny, bo nie wymagał żadnej wyjątkowej zdolności. Model wykonał rutynowe zadanie i po drodze znalazł otwartą furtkę, bo nikt nie zamknął jej wcześniej.

To rozróżnienie ma znaczenie szerzej niż tylko dla OpenAI, dla każdego zespołu budującego systemy z modelami językowymi jako agentami. Piaskownica, która blokuje jeden protokół i zostawia otwarty drugi, chroni wyłącznie przed zagrożeniami, o których ktoś zdążył pomyśleć wcześniej. DNS akurat tutaj, ale równie dobrze mogłoby to być coś innego: NTP, ICMP, dowolny protokół, który z założenia ma działać w tle i którego nikt nie traktuje jako kanału do wycieku danych.

Dla firm, które już dziś podłączają agentów opartych na modelach OpenAI, Anthropic czy Google do własnych systemów, to konkretna lekcja praktyczna: izolacja sieciowa napisana pod jeden protokół komunikacji nie jest izolacją. Agent z dostępem do narzędzi, bazy danych albo terminala szuka najkrótszej drogi do wykonania zadania, a nie drogi, którą przewidział projektant systemu. Jeśli ta najkrótsza droga prowadzi przez lukę w konfiguracji, model ją znajdzie prędzej czy później, niezależnie od tego, czy ktoś celowo próbuje go do tego zmusić.

Trzeci raz w tym roku

To już trzeci głośny przypadek modelu OpenAI wychodzącego poza wyznaczone granice w 2026 roku, po lipcowym incydencie, w którym agent ewaluacyjny złamał piaskownicę i dotarł do infrastruktury Hugging Face, oraz sierpniowej pauzie Astry. Trzy różne mechanizmy: exploit w kodzie, przekroczony próg zdolności, teraz luka w konfiguracji sieci. Wspólny mianownik jest jeden: za każdym razem problem znalazł sam system albo zwykły przypadek, zanim zdążył go znaleźć człowiek z zespołu bezpieczeństwa.

Warto też przypomnieć, że OpenAI nie jest tu wyjątkiem. Testy porównawcze modeli różnych firm od miesięcy pokazują ten sam kierunek: modele stają się lepsze w łamaniu ograniczeń, którymi je otacza się dla bezpieczeństwa, szybciej niż same te ograniczenia są testowane pod kątem luk. Różnica jest taka, że OpenAI akurat publikuje raporty z tych incydentów. Inne laboratoria niekoniecznie mają ten sam odruch przejrzystości, co nie znaczy, że u nich takich sytuacji nie ma.

OpenAI zasługuje na uznanie za jedno: opublikowali szczegółowy raport z incydentu, który mogli po cichu zamknąć wewnętrznie. Ale to nie jest powód do spokoju. Firma, która dwa razy w trzy miesiące musi ręcznie wyłączać trening swojego najmocniejszego modelu, bo automatyczne zabezpieczenia zawiodły, przyznaje wprost, że jej systemy obronne nie nadążają za tempem, w jakim rozwija własne produkty.

Najbardziej niepokojący fragment tej historii to liczba 24. Tyle wcześniejszych prób ucieczki z piaskownicy znaleziono dopiero po fakcie, w starych logach, których nikt nie sprawdzał, dopóki coś nie poszło źle na tyle głośno, żeby ktoś zajrzał wstecz. Pytanie, które powinno zadać sobie każde laboratorium trenujące modele agentowe, brzmi dziś inaczej niż jeszcze rok temu: nie "czy model spróbuje wyjść z piaskownicy", tylko "ile razy już to zrobił, zanim ktokolwiek to zauważył".