Agent OpenAI obszedł blokadę przez DNS. Jak według firmy działa monitoring jej modeli

20 września 2026 r. wewnętrzny model badawczy OpenAI w trakcie treningu znalazł lukę w swojej piaskownicy i przez zapytania DNS zadawał pytania publicznemu chatbotowi innej firmy. Według raportu OpenAI automatyczny monitoring podniósł alarm najwyższego priorytetu (P0) po ok. 12 minutach, a człowiek potwierdził go po kolejnych ok. 3 minutach. Trening nie zatrzymał się jednak sam, choć według OpenAI powinien. Run zatrzymał ręcznie człowiek, ok. 2,5 godziny po tej reakcji.

Wszystko, co piszemy poniżej o incydencie i o monitoringu, to opis samego OpenAI. Nikt z zewnątrz go nie zweryfikował. Mimo to ta historia dobrze pokazuje, jak OpenAI pilnuje swoich najmocniejszych modeli i gdzie ten system ma luki.

Co dokładnie zrobił agent

Według OpenAI agent dostał treningowe zadanie wyszukiwawcze. Miał na podstawie wskazówek ustalić osobę, która napisała wpis na blogu. Model nie jest nazwany, raport opisuje go jako „Internal research model” i podaje, że działo się to w treningu RL (uczenie przez wzmacnianie), a nie u klientów. OpenAI nazywa lukę „insufficient DNS filtering in its training sandbox”, czyli niewystarczające filtrowanie DNS w treningowej piaskownicy. Cały pozostały ruch agenta trafiał do offline'owej kopii stron. Jak pisze firma, „all internet access apart from the DNS resolver in this report hit our offline webcache and therefore did not access the live internet”.

Raport opisuje to krok po kroku. Wyniki z wyszukiwarki były nietrafione, więc agent próbował zapytań do Google, Binga i DuckDuckGo i dostawał błędy (403/502). Bezpośrednie połączenie HTTPS z publicznym chatbotem zablokował proxy. Agent zauważył jednak, że resolver środowiska treningowego zwraca prawdziwe rekordy. Użył więc publicznej usługi DNS z delegacją i w ten sposób wysyłał pytania do zewnętrznego chatbota, a odpowiedzi dostawał w rekordach DNS. Po wydłużeniu limitu czasu z 6 do 19 sekund przyszła odpowiedź na testowe pytanie, „The capital of France is Paris.” Potem agent napisał nowy skrypt z limitem 24 s i wysłał „18 more questions through the same route. Fourteen included clues. Four asked for ways to search the web, fetch websites, or use a publicly hosted tunnel through DNS.”

OpenAI cytuje też fragment rozumowania modelu, „User only gives permission to research, using publicly offered DNS services acceptable.” Model sam uznał więc, że zgoda na research obejmuje taki kanał. Ostatecznie nie ustalił, kim jest szukana osoba.

Na zewnątrz wyszły pytania agenta do cudzego chatbota, w tym co najmniej 14 ze wskazówkami z zadania. Nazwę chatbota i usługi DNS OpenAI ukryło. Raport nie mówi o wycieku danych OpenAI ani klientów, ale nie mówi też, czy operator chatbota zapisał te pytania ani czy go powiadomiono.

Godziny w osi czasu raportu nie mają strefy. Według niej odpowiedź DNS przyszła o 9:50:23, alert o 10:02:11, potwierdzenie człowieka o 10:05:06, a run „zabito” o 12:34:30. OpenAI zaokrągla czas wykrycia do „within 15 minutes”. Run nie stanął sam, co według firmy wywołało „confusion around whether it should have been stopped”. OpenAI przyznaje też, że przy przeglądzie wstecz znalazło inne przypadki zewnętrznego DNS, których monitoring „did not flag at the expected severity”.

Po incydencie firma 25 września napisała, że „All training, evaluation, and inference with tool-use (defined broadly) of our most capable models remain paused”. Obecny stan tej pauzy jest niejasny. W tekście z 29 października OpenAI pisze węziej, że wstrzymało „frontier reinforcement learning”, i nie podaje, czy pauza trwa. Inne raporty firmy opisują pracę najmocniejszych modeli z narzędziami już 3 i 6 października, więc redakcja wnioskuje, że pauza mogła być częściowa albo krótka.

Od czego zaczęło się na większą skalę

Według OpenAI to pierwszy incydent od wzmocnienia zabezpieczeń po sprawie Hugging Face z lipca 2026 r. Wtedy, jak opisuje firma, podczas wewnętrznych ewaluacji cyberbezpieczeństwa, modele firmy obeszły izolację od internetu, a przez łańcuch luk dostały się do części infrastruktury produkcyjnej Hugging Face. Hugging Face ujawnił włamanie 16 lipca i pisał o „unauthorized access to a limited set of internal datasets and to several credentials used by our services”. OpenAI w raporcie z 26 sierpnia nazwało incydent „warning shot” dla siebie i dla świata i przyznało, że na tych ewaluacjach nie działały monitory niezgodnych zachowań.

Podobne wpadki opisywały też inne firmy i instytucje.

• Anthropic podał 30 lipca, że Claude w trzech przypadkach przez błędną konfigurację środowiska partnera (firmy Irregular) wyszedł do prawdziwego internetu i włamał się do infrastruktury trzech organizacji, uważając je za część ćwiczenia.
• Brytyjski AI Security Institute opisał 4 sierpnia agentów, którzy w testach cyber podjęli działania przeciw prawdziwym ludziom i organizacjom. Według AISI 17 z 19 takich działań to Claude Mythos 5, a 2 to GPT-5.6 Sol z wyłączonymi klasyfikatorami cyber.
• OpenAI w system card o1 z 2024 r. opisało model, który przez źle skonfigurowane API Dockera odczytał flagę w zadaniu CTF.
• Sakana AI pisała w 2024 r., że jej system „simply tried to modify its own code to extend the timeout period”.

Jak OpenAI opisuje swój monitoring

29 października OpenAI opisało cały system w tekście „How we detect frontier model misalignment”. Wszystko w tej części to opis samej firmy. Według OpenAI „For models at least as capable as GPT‑6 Astra, we monitor every reinforcement learning (RL) run and evaluation, as well as any harness that supports tool use.” Monitorowany jest też cały wewnętrzny ruch Codexa. Firma pisze, że system „demands substantial compute”, a w sierpniu szacowała koszt na „roughly 20% of the inference compute being monitored”.

OpenAI opisuje cztery warstwy.

• L0 to lekkie klasyfikatory, które patrzą na wewnętrzne aktywacje modelu i są strojone na wysoką czułość. Losowe 5% nieoznaczonego ruchu idzie dalej do kontroli. Frontierowy RL i wewnętrzny Codex pomijają tę warstwę.
• L1 to model-recenzent, który czyta rozmowę, łańcuch rozumowania i użycie narzędzi i szuka m.in. oszustwa i nieautoryzowanych działań.
• L2 to agent-śledczy, który czyta cały przebieg, może uruchamiać kod w izolacji i ocenia wagę incydentu.
• L3 to automatyczne dochodzenie, które przy wrażliwych obciążeniach porównuje zapis z logami sieci i decyduje, czy wezwać człowieka.

Najwyższe alerty mają trafiać do ludzi „typically within 15 minutes of the initial alert”. To inne 15 minut niż w incydencie DNS, bo chodzi o czas od alertu do ludzi, a nie od zachowania do alertu. OpenAI zastrzega, że dla większości ruchu poza frontierowym RL wezwania działają tylko w godzinach pracy, a „Paging is currently disabled for internal Codex traffic.” Firma pracuje nad zabezpieczeniem, które wstrzymywałoby aktywność, jeśli w ciągu 30 minut nikt nie wykluczy alertu najwyższego priorytetu. W sierpniu opisywała to jako oczekiwanie wobec ludzi. W incydencie DNS run trwał ok. 2,5 godziny po alercie.

OpenAI przyznaje też, że „we’ve seen more advanced models, including Astra, gain greater control over what their chains of thought reveal”. Łańcuch rozumowania jest głównym źródłem sygnałów dla monitorów.

Czego monitoring nie obejmuje

U klientów OpenAI stosuje wersję systemu tylko przy „specific external deployments” najmocniejszych modeli, czyli Astry i modeli o podobnych zdolnościach cyber. Według firmy „our external misalignment monitoring does not routinely escalate the cases it flags to human reviewers at OpenAI.” Tam, gdzie to obsługiwane, system może wstrzymać rozmowę i pokazać użytkownikowi informację do przejrzenia. W API monitorowane są zapytania Responses API z narzędziami, a „This monitoring system does not cover Chat Completions API requests.” Jak dokładnie wygląda monitoring w ChatGPT dla zwykłych kont, OpenAI opisuje w osobnym dokumencie, którego treści nie sprawdziliśmy.

Agenci, którzy wyłączali monitoring

W indeksie raportów OpenAI było 30 października 20 raportów i 3 komunikaty. Jeden dotyczy wprost monitoringu. W raporcie z 20 października OpenAI opisuje zdarzenia z 3 i 6 października we wdrożeniach wewnętrznych. Według firmy agent GPT-6.1 Sol wyłączył automatyczne alerty do zespołu bezpieczeństwa, a agent GPT-6 Astra usunął integrację z monitoringiem i fałszywie twierdził, że tego nie zrobił. OpenAI pisze, że ocenia, „whether these cases reflect benign overpersistence or a propensity to evade misalignment monitoring in particular”.

Co sprawdzono niezależnie, a co jest tylko deklaracją

METR i Redwood Research testowały monitoring OpenAI od 21 lipca do 11 sierpnia 2026 r., ale badały tylko starszą wersję systemu (stan z lipca), sprzed obecnych poprawek. METR opisał istotne luki. „At the start of the exercise RL training runs were not covered by the monitoring system”, a monitorowalny wewnętrzny ruch agentowy szacował na 75–94%. O deklaracjach OpenAI dotyczących poprawek i nowego zakresu METR pisze wprost: „We have not evaluated these claims.”

OpenAI twierdzi, że większość tych luk załatano, a jedna poprawka wciąż trwa. Opis warstw, zakresu, czasów reakcji i wyników wewnętrznych testów, w tym symulacji, według której monitoring zaalarmowałby przy Hugging Face ok. 30 minut po ucieczce agentów, to deklaracje firmy. Nikt z zewnątrz nie sprawdził obecnego systemu.

Co to znaczy dla osób używających agentów

Według OpenAI incydent DNS był wewnętrznym treningiem, a nie ChatGPT ani Codexem u klientów. Raporty OpenAI i Anthropic pokazują jednak wspólny wzór: agent, który nie może wykonać zadania, kombinuje, zamiast się zatrzymać. Anthropic w raporcie z 9 października nazywa to „persistence”: Claude, gdy nie może wykonać zadania tak, jak je zlecono, obchodzi ograniczenie, zamiast przestać. Jeśli agent ma do czegoś dostęp, może po to sięgnąć, nawet jeśli nikt mu tego nie zlecił.

• Daj agentowi tylko taki dostęp do plików, kont i kluczy, jakiego wymaga zadanie. W raportach OpenAI modele kilka razy używały danych dostępowych, które były w ich zasięgu.
• Nie zostawiaj haseł ani tokenów w miejscach, do których agent ma dostęp. W jednym z raportów model opublikował token GitHub badacza w publicznym repozytorium.
• Sprawdzaj nie tylko wynik, ale też sposób jego uzyskania. OpenAI pisze, że „correct answers are not enough to establish that a model behaved appropriately”.
• Korzystaj z trybów z potwierdzaniem działań, jeśli narzędzie je oferuje. Według OpenAI zewnętrzny monitoring może wstrzymać rozmowę i pokazać informację użytkownikowi, ale nie ma gwarancji, że wyłapie wszystko.