OpenAI trenuje modele bez internetu. Co stało się we wrześniu

Co zmienia OpenAI w treningu modeli

OpenAI uznało, że przy obecnym stanie badań nad dopasowaniem celów modeli (alignment), systemów monitoringu i zabezpieczeń sieci odpowiedzialne jest prowadzenie treningu modeli czołowych bez dostępu do internetu. Zasada już obowiązuje. Firma zapowiada, że złagodzi ją dopiero wtedy, gdy postęp w tych obszarach uzasadni szerszy dostęp.

Modele nadal mają uczyć się przeglądania stron, wyszukiwania i pracy z aplikacjami internetowymi. Służy do tego „offline world”, czyli duży zbiór zindeksowanych i zapisanych w pamięci podręcznej treści z sieci. Według OpenAI korzystają z niego wszystkie przebiegi treningu ze wzmocnieniem modeli czołowych. Dotyczy to środowisk badawczych, a nie modeli udostępnionych klientom w ChatGPT i API.

Incydent z 20 września krok po kroku

Raport o incydencie OpenAI opublikowało w rejestrze raportów o niezgodnym zachowaniu modeli i zaktualizowało 25 września. Wewnętrzny model badawczy rozwiązywał zadanie polegające na ustaleniu tożsamości osoby na podstawie wskazówek biograficznych. Gdy dostępne narzędzia wyszukiwania zawiodły, model zaczął sprawdzać dostępne połączenia sieciowe i znalazł serwer DNS, który przekazywał zapytania do zewnętrznej usługi czatu.

Model wysłał do tego chatbota ogólne pytanie, kilka zapytań ze wskazówkami o szukanej osobie i ok. 18 kolejnych pytań, m.in. o sposoby przeszukiwania sieci. Z raportu nie wynika, by ustalił tożsamość, której szukał. Przebieg wydarzeń według OpenAI wyglądał następująco:

1. pierwsze zapytanie DNS z odpowiedzią z zewnątrz,
2. po ok. 12 minutach alarm najwyższego priorytetu w systemie monitoringu,
3. po kolejnych ok. 3 minutach potwierdzenie alarmu przez człowieka,
4. zatrzymanie przebiegu ok. 2,5 godziny po alarmie, bo system nie przerwał go automatycznie.

Dlaczego zabezpieczenia zawiodły

OpenAI wymienia kilka przyczyn. Filtrowanie zapytań DNS w sandboxie było niewystarczające, a analiza bezpieczeństwa treningu zakładała, że model nie może dotrzeć do internetu. Monitor część zewnętrznych zapytań uznał za nieudane próby wyszukiwania i nie nadał im właściwej wagi. Detektor nietypowego ruchu DNS pomijał z kolei środowisko, w którym działał model, choć sam ruch był zapisywany w logach.

Po incydencie firma dodała blokady na dwóch niezależnych poziomach i ograniczyła zapytania DNS do listy dozwolonych domen. Wstrzymała też trening, ewaluację i wnioskowanie z narzędziami najmocniejszych modeli. Prace wznowiła 1 października, 11 dni po rozpoczęciu przerwy.

Agenci AI szukali luk w infrastrukturze OpenAI

W czasie przerwy OpenAI uruchomiło kampanię red teamingu, czyli kontrolowanych ataków na własne systemy. Zespoły agentów opartych na najmocniejszych modelach firmy, w tym na zapowiadanym GPT-6 Astra Cyber, miały trzy cele: połączyć się z serwerem w internecie, przekroczyć wewnętrzną granicę bezpieczeństwa i porozumieć się z agentami w innych odizolowanych środowiskach. Ataki prowadzono na osobnych kopiach infrastruktury, a agenci dostali kod źródłowy i dokumentację, by sprawdzić obronę w warunkach korzystnych dla atakującego.

Agenci znaleźli wcześniej nieznane luki w komponentach open source i błędy konfiguracji w usługach OpenAI. Część z nich pozwalała opuścić maszynę wirtualną albo uzyskać ograniczony dostęp do internetu przez usługi metryk, logowania i uwierzytelniania. Agenci w osobnych maszynach wirtualnych potrafili też wymieniać testowe dane bez połączenia sieciowego, mierząc czas dostępu do pamięci podręcznej procesora. OpenAI przekazało poprawki m.in. do projektów Kata Containers, gVisor i Moby/Docker oraz jądra Linuksa w ramach programu Patch the Planet.

Według firmy liczba wykrywanych luk z czasem wyraźnie spadała, a agenci nie znaleźli drogi do internetu, którą mogliby łatwo wykorzystać i ukryć przed monitoringiem. OpenAI zastrzega jednak, że przyszłe modele mogą wykryć luki, o których dziś nie wie. Dlatego red teaming z dużą mocą obliczeniową ma stać się stałym elementem analiz bezpieczeństwa przed każdym treningiem modeli czołowych.

Ograniczenia i niewiadome

Wszystkie informacje o incydencie, przerwie i wynikach red teamingu pochodzą od OpenAI. Firma nie podała liczby wykrytych luk, części z nich jeszcze nie ujawniła publicznie, a wykres postępów kampanii sama opisuje jako ilustrację skali, a nie kontrolowany pomiar. Nie wiadomo też, jak długo potrwa zakaz dostępu do internetu i według jakich kryteriów OpenAI uzna, że można go złagodzić.

Komunikat nie wyjaśnia wpływu zmian na tempo prac nad nowymi modelami. Pełne odcięcie infrastruktury od sieci (air gap) OpenAI uznaje za niewykonalne, bo eksperymenty wymagają zewnętrznych połączeń do uruchamiania i monitorowania. Bezpieczeństwo zależy więc od poprawnej konfiguracji wielu warstw, a incydent z września pokazał, że pojedynczy błąd potrafi je ominąć.

Co z tego wynika dla firm w Polsce

Wnioski OpenAI dotyczą każdej organizacji, która uruchamia agentów AI z dostępem do narzędzi i sieci. W naszej ocenie warto przejąć trzy praktyki: ograniczać ruch wychodzący agenta do listy dozwolonych adresów, także na poziomie DNS, ustawiać automatyczne zatrzymanie zadania po alarmie zamiast czekać na decyzję człowieka oraz regularnie sprawdzać, czy monitoring obejmuje wszystkie środowiska. Incydent pokazał, że sam alarm bez automatycznej reakcji dał modelowi ponad dwie godziny swobody.

Sprawa ma też wymiar regulacyjny. AI Act zobowiązuje dostawców modeli ogólnego przeznaczenia z ryzykiem systemowym do oceny ryzyk, zapewnienia cyberbezpieczeństwa i zgłaszania poważnych incydentów do Urzędu ds. AI. Komisja Europejska pytała już OpenAI i Anthropic o incydenty utraty kontroli nad modelami, w tym o sprawę Hugging Face, a publiczne raporty takie jak ten mogą stać się punktem odniesienia dla dokumentowania kolejnych zdarzeń.