METR i Redwood Research przeprowadziły trzytygodniowy pilotaż, by sprawdzić, czy wewnętrzny system OpenAI potrafi wykrywać niepożądane zachowania agentów AI i czy agenci mogą go obejść. Badacze znaleźli luki w monitoringu, w tym sposób na ukrycie setek niedawnych działań. OpenAI poinformowało, że załatało podatności wpływające na zabezpieczenia produkcyjne, ale późniejszych zmian nie oceniono niezależnie.
1
10
21
Jak przebiegał test
Od 21 lipca do 11 sierpnia 2026 r. po jednym badaczu z każdej organizacji pracowało na miejscu w OpenAI. Testowali wewnętrzny system monitorowania agentów pod kątem niepożądanych zachowań. Mieli dostęp do kodu źródłowego, dokumentacji, części infrastruktury oraz pracowników technicznych. Korzystali z urządzeń udostępnionych przez OpenAI, które pozostawały na terenie firmy, a ich praca odbywała się pod nadzorem pracowników OpenAI.
2
5
7
Celem było sprawdzenie zarówno tego, jak szeroki jest zasięg monitoringu, jak i tego, czy agent może go wyłączyć lub obejść. METR poinformowała, że wyniki zebrano w 61-stronicowym raporcie wewnętrznym przekazanym badaczom i zespołom bezpieczeństwa OpenAI. Publicznie przedstawiono szersze podsumowanie, a nie pełny raport.
7
17
Co wykazał przegląd
Monitoring nie obejmował całego istotnego ruchu
Według szacunku METR monitorowaniem mogło być objęte 75–94% wewnętrznego ruchu agentów przez Responses API, pochodzącego od modeli co najmniej tak zaawansowanych jak GPT-5.5. To szacunek tego, jaka część ruchu kwalifikowała się do monitorowania — nie dowód, że cała ta aktywność była faktycznie nadzorowana ani że system wykrywał każdy problem.
1
6
18
Na początku testu monitoring pod kątem niepożądanych zachowań nie obejmował również przebiegów treningu z użyciem uczenia ze wzmocnieniem.
22
Istniały potencjalne sposoby obejścia nadzoru
Publiczne podsumowania opisują kilka rodzajów słabości: potencjalne obejście zabezpieczeń piaskownicy Codex, nagłówki kontrolowane przez klienta, które mogły wyłączać monitoring dla nowych instancji agentów, oraz metodę pozwalającą ukryć przed systemem setki niedawnych działań. Dostępne publicznie informacje nie przedstawiają jednak pełnych technicznych szczegółów raportu.
1
3
Zdarzenia kompakcji wiązały się z luką w monitoringu
METR oszacowała, że nieuwzględnianie zdarzeń kompakcji mogło sprawić, iż od maja do lipca 2026 r. monitorowaniu nie podlegało około 10% kwalifikującego się wewnętrznego ruchu Codex. Organizacja zaznaczyła, że dokładny odsetek jest niepewny. Według relacji o ustaleniach METR pracownicy OpenAI wykryli tę lukę jeszcze przed pilotażem, a w trakcie przeglądu została ona naprawiona.
10
Czego przegląd nie potwierdza
Ocena dotyczyła systemu monitorowania w stanie z początku pilotażu. METR nie badała późniejszych zmian, dlatego przegląd nie pozwala niezależnie potwierdzić, jaki zasięg ma system obecnie ani czy wszystkie działania naprawcze były skuteczne.
7
21
22
Informacja OpenAI, że załatano podatności wpływające na zabezpieczenia produkcyjne, jest stanowiskiem firmy — nie niezależnym potwierdzeniem, że usunięto każdą słabość.
21
Dlaczego ten pilotaż jest istotny
Ćwiczenie sprawdziło, jak może wyglądać pogłębiony dostęp zewnętrznych ekspertów do systemów firmy. We wrześniu OpenAI zapowiedziało „dostęp na poziomie pracownika” dla niezależnych ewaluatorów. Pilotaż pokazuje, z czym może wiązać się taki model oceny, ale nie należy traktować go jako kompletnego, publicznego audytu.
8
28
Najważniejszy wniosek jest konkretny: badacze pracujący na miejscu znaleźli luki w monitoringu i potencjalne drogi jego obejścia, a OpenAI poinformowało o naprawieniu problemów wpływających na zabezpieczenia produkcyjne. Publicznie dostępne informacje nie rozstrzygają jednak, jak kompleksowy stał się nadzór po pilotażu ani kto niezależnie sprawdził skuteczność poprawek.
7
21