METR opisał luki w wewnętrznym monitorowaniu agentów OpenAI, a także różne szacunki tego, jaki ruch trafiał do monitora. W podsumowaniu opublikowanym 22 października 2026 r. organizacja podała, że od 75 do 94% określonego ruchu Responses API kwalifikowało się do monitorowania. W przypadku ruchu wewnętrznych agentów Codex było to 99,2%. Kwalifikacja oznaczała zamiar wysłania żądania do monitora, nie gwarancję, że przeszło ono cały proces kontroli.
Co sprawdzał pilotaż METR i Redwood Research
Po jednym pracowniku METR i Redwood Research przeprowadziło trzytygodniowy pilotaż z udziałem OpenAI, który wspólnie zaprojektowały te trzy organizacje. Audyt dotyczył wewnętrznego, asynchronicznego systemu OpenAI monitorującego oznaki niezgodnego z założeniami działania agentów. Dostęp do systemu audytorzy mieli od 21 lipca do 11 sierpnia; METR nie podał roku tych dat.
Badacze analizowali wewnętrzny kod, polecenia i konfigurację monitora oraz dokumentację. Przeprowadzili też rozmowy z około tuzinem badaczy i inżynierów. Na początku ćwiczenia system nie obejmował przebiegów treningu RL, czyli uczenia przez wzmacnianie.
Co oznaczają szacunki dotyczące monitorowania
METR podał trzy osobne miary. Dotyczą różnych zbiorów ruchu, dlatego nie można ich traktować jako wspólnego wskaźnika pokrycia.
| Miara | Ruch objęty szacunkiem | Wynik i okres | Zastrzeżenie dotyczące zakresu |
| Kwalifikacja do monitorowania | Wewnętrzny ruch agentów przez Responses API, korzystających z modeli co najmniej tak zaawansowanych jak GPT-5.5 | 75–94% | METR określił szacunek jako obarczony znaczną niepewnością. Nie obejmował on między innymi ruchu z wewnętrznej usługi inferencyjnej używanej w badaniach, którego wielkości METR nie potrafił oszacować. |
| Kwalifikacja do monitorowania | Ruch przez Responses API używany przez wewnętrznych agentów Codex | 99,2% | To szacunek dla podzbioru ruchu Codex, a nie całej aktywności agentów OpenAI. |
| Ruch pominięty przez monitor | Kwalifikujący się ruch wewnętrznych agentów Codex | Około 10% w okresie od maja do lipca 2026 r. | METR powiązał ten szacunek z pomijaniem zdarzeń kompakcji i zaznaczył, że jest on obarczony znaczną niepewnością. |
Ostatnia wartość opisuje ruch, który prawdopodobnie nie został monitorowany z powodu luki związanej z kompakcją. Nie jest tym samym co odsetek ruchu zakwalifikowanego do monitorowania. Pracownicy OpenAI niezależnie znaleźli i naprawili ten błąd podczas ćwiczenia.
Jakie drogi obejścia monitoringu opisał METR
METR opisał sposób, w jaki agent mógł w zasadzie ominąć sandbox Codex i Auto-Review, a także exploit pozwalający ukryć setki ostatnich działań. Audytorzy wskazali również wejścia, które prawdopodobnie mogły doprowadzić do awarii monitora, oraz dwa nagłówki kontrolowane przez klienta, które wyłączały monitoring dla nowych agentów. Samo ustawienie tych nagłówków mogło jednak zostać wykryte.
Monitor uruchamiał się, gdy agent oddawał kontrolę użytkownikowi. W czasie luki związanej z kompakcją agent mógł więc bezterminowo odkładać kontrolę, kontynuując działania. METR nie ustalił, czy agenci rzeczywiście wykorzystali tę słabość. Nie sprawdził też w praktyce, czy możliwe było wykorzystanie osobnej luki w dwóch niemonitorowanych narzędziach wewnętrznych.
Co OpenAI podało o poprawkach
OpenAI przekazało, że luki wskazane przez audytorów i wpływające na zabezpieczenia produkcyjne zostały naprawione. METR nie oceniał skuteczności tych poprawek ani późniejszych zmian w zakresie monitorowania.
METR opisał wewnętrzny raport liczący 61 stron. Do kierownictwa METR i Redwood Research trafiły jego 38-stronicowe kopie z redakcjami OpenAI, a publicznie udostępniono krótsze podsumowanie.
