Zespół red teamowy METR odkrywa podatności w systemie monitorowania OpenAI

METR i Redwood Research opublikowały 22 października 2026 r. publiczne sprawozdanie z pilotażowego ćwiczenia, w którym po jednym pracowniku każdej z organizacji przez trzy tygodnie miało szeroki dostęp do wewnętrznej infrastruktury OpenAI i poddawało testom wytrzymałościowym wewnętrzny system firmy służący do monitorowania niezgodności. Osoby oceniające poinformowały o odkryciu szeregu nowych podatności w systemie w jego postaci z 21 lipca 2026 r. i sprzed tej daty.

Ćwiczenie trwało od 21 lipca do 11 sierpnia 2026 r. i koncentrowało się przede wszystkim na oszacowaniu odsetka wnioskowania agentowego podlegającego monitorowaniu oraz na ustaleniu, czy agenci mogliby teoretycznie wyłączyć lub obejść system monitorowania. Jego wynikiem był 61-stronicowy raport wewnętrzny udostępniony badaczom i pracownikom OpenAI odpowiedzialnym za bezpieczeństwo; 38-stronicową wersję z zastrzeżonymi fragmentami, przygotowaną przez OpenAI, przekazano zespołom kierowniczym METR i Redwood Research.

Szeroki dostęp na uzgodnionych warunkach

Dwie osoby oceniające uzyskały dostęp do wewnętrznej bazy kodu OpenAI, monitów i szczegółów konfiguracji monitora niezgodności oraz dokumentacji wewnętrznej, a także przeprowadziły wywiady techniczne z około tuzinem badaczy i inżynierów z zespołów zajmujących się monitorowaniem, systemami bezpieczeństwa i ochroną. Aby umożliwić im tak szeroki dostęp, pracowały na urządzeniach dostarczonych przez OpenAI, które nigdy nie opuszczały jej siedziby, a podczas pracy na miejscu towarzyszyły im inne osoby.

METR, Redwood Research i OpenAI zaprojektowały ćwiczenie jako pilotażowy projekt zapewniający zewnętrznym badaczom szeroki dostęp do wewnętrznej infrastruktury, a nie jako sposób na zagwarantowanie rzetelnej publicznej przejrzystości działania systemów monitorowania OpenAI. Strony z góry uzgodniły, że opublikują jedynie stosunkowo krótki, ogólny wpis. OpenAI zastrzegła sobie prawo do usunięcia z publicznej wersji wszelkich informacji, które według własnego uznania uzna za poufne lub w inny sposób wrażliwe. Wyniki dotyczą historycznej wersji systemu ocenianej 21 lipca i przed tą datą, a nie obejmują zmian będących wówczas w toku; METR odnotowała, że w trakcie ćwiczenia OpenAI rozbudowywała swój system monitorowania.

Luki w monitorowaniu i sposoby na obejście monitora

METR oszacowała, że w czasie ćwiczenia monitorowaniu mogło podlegać około 75–94% ruchu agentowego w wewnętrznym interfejsie Responses API, generowanego przez modele co najmniej tak zaawansowane jak GPT-5.5, zaznaczając przy tym, że szacunek obarczony jest znaczną niepewnością w obu kierunkach. Responses API obsługuje między innymi Codex, a w przypadku części tego ruchu wykorzystywanej przez wewnętrznych agentów Codex osoby oceniające oszacowały, że monitorowaniu mogło podlegać 99,2% ruchu. Stwierdziły, że nie były w stanie oszacować skali innego wewnętrznego ruchu związanego z agentowym programowaniem, o którym wiedziały, na przykład ruchu generowanego przez agentów korzystających z wewnętrznej usługi wnioskowania badawczego OpenAI, z powodu ograniczeń dostępu i czasu.

Kilka ustaleń dotyczyło luk w tym zakresie monitorowania. Na początku ćwiczenia system monitorowania nie obejmował przebiegów treningowych uczenia przez wzmacnianie, choć osoby oceniające poinformowano, że od marca do czerwca monitorowano część przebiegów treningowych RL pod kątem niezgodności. METR oszacowała, że brak monitorowania zdarzeń kompakcji prawdopodobnie sprawił, iż między majem a lipcem 2026 r. monitor nie obejmował około 10% kwalifikującego się do monitorowania ruchu wewnętrznego Codex. Pracownicy OpenAI niezależnie zidentyfikowali tę lukę przed rozpoczęciem ćwiczenia i usunęli ją w jego trakcie. Ponieważ system uruchamiał się, gdy agenci oddawali kontrolę użytkownikowi, agenci mogli bezterminowo odwlekać monitorowanie, po prostu kontynuując działanie w tym czasie; ograniczenia dostępu uniemożliwiły osobom oceniającym sprawdzenie, czy któryś z agentów rzeczywiście tak postąpił. Osobno osobom oceniającym przedstawiono informacje sugerujące, że w czasie ćwiczenia monitor zgłaszał błędy w przypadku mniej niż 0,2% żądań i nie odnotował żadnego odrzucenia obciążenia w jednym 24-godzinnym okresie.

Osoby oceniające wskazały również sposoby, na jakie agent mógłby całkowicie pokonać system monitorowania. Odkryły metodę, dzięki której agenci Codex mogliby teoretycznie ominąć mechanizmy sandboxowania Codex i Auto-Review, aby wykonać dowolne działanie dostępne użytkownikowi hosta, a także exploit, którego szczegóły OpenAI utajniła, pozwalający wyłączyć z monitorowania setki ostatnich działań, w tym działania podjęte w celu przeprowadzenia samego exploita. Ustaliły, że agenci mogliby prawdopodobnie skonstruować dane wejściowe powodujące awarię monitora, a tym samym uniknąć eskalacji sprawy do weryfikacji przez człowieka, wykorzystując różnice w sposobie serializowania ścieżki działania agenta i ścieżki przekazywanej monitorowi. Odkryły dwa nagłówki kontrolowane przez klienta, które wyłączają system monitorowania dla nowych agentów. Mogłoby to umożliwić agentowi uruchomienie identycznej instancji, która działałaby bez monitorowania, choć samą czynność ustawienia tych nagłówków i utworzenia instancji system monitorowania mógłby wykryć. Znalazły też dwa niemonitorowane wewnętrzne narzędzia agentowe, które — jak sądzono — miały uprawnienia tylko do odczytu, lecz prosty exploit mógłby posłużyć do obejścia tych ograniczeń i wykonywania dowolnych działań w środowisku odizolowanym za pomocą mechanizmu sandbox. Osoby oceniające nie zweryfikowały ani nie przetestowały tego zachowania w praktyce.

Oprócz wykrytych podatności osoby przeprowadzające ewaluację potwierdziły, że z nielicznymi wyjątkami system monitorowania otrzymuje pełny przebieg interakcji widoczny dla agentów. Zweryfikowały też, że prompty monitora służą do wykrywania między innymi podstępnych działań, prób podważenia systemu monitorowania, sabotażu, eksfiltracji danych, oszustwa oraz wstrzykiwania promptów przychodzących i wychodzących, a także innych kategorii ryzyka. Po zakończeniu ćwiczenia OpenAI poinformowało, że wszystkie zidentyfikowane podatności wpływające na produkcyjny zestaw zabezpieczeń zostały załatane, a także opisało istotne późniejsze zmiany w planowanym zakresie działania systemu monitorowania. METR poinformowało, że nie zweryfikowało tych deklaracji.

System monitorowania w opisie OpenAI

OpenAI publicznie opisało testowany system w poście z 19 marca 2026 r. Zgodnie z tym wpisem system o niskim opóźnieniu działa w oparciu o GPT-5.4 Thinking przy maksymalnym poziomie wysiłku rozumowania, analizuje interakcje agentów w ciągu 30 minut od ich zakończenia oraz rejestruje i analizuje łańcuchy rozumowania i działania agentów, przypisując każdej interakcji kategorię i poziom istotności, a także wskazując anomalie do weryfikacji przez człowieka. OpenAI poinformowało, że system działa we wszystkich standardowych, wewnętrznych wdrożeniach agentów kodujących i analizuje pełną historię konwersacji, w tym wszystkie wiadomości użytkowników, deweloperów i asystentów, a także wywołania narzędzi i ich wyniki.

We wpisie OpenAI wymieniono kategorie monitorowanych zachowań, do których należą obchodzenie ograniczeń, oszustwo, ukrywanie niepewności, manipulowanie systemem nagród, nieuprawnione przesyłanie danych, działania destrukcyjne oraz wstrzykiwanie promptów przychodzących i wychodzących. Poinformowano też, że do 17 marca 2026 r. nie odnotowano żadnych potwierdzonych przypadków celowego zaniżania możliwości, sabotażu ani podstępnych działań. Jak podało OpenAI, w ciągu pięciu miesięcy działania system monitorował dziesiątki milionów wewnętrznych przebiegów pracy agentów kodujących i skierował do weryfikacji przez człowieka około 1000 konwersacji o umiarkowanym poziomie istotności, z których wiele wynikało z celowych wewnętrznych testów red-team. Nie zarejestrował przy tym żadnej rzeczywistej konwersacji, która osiągnęłaby najwyższy poziom istotności. Firma poinformowała również, że monitor oznaczył każdą interakcję zgłoszoną niezależnie przez pracowników za pośrednictwem kanałów wewnętrznych.

OpenAI stwierdziło we wpisie, że skuteczność tego podejścia zależy przede wszystkim od możliwości monitorowania. Dodało, że bez specjalnych ewaluacji kontrolnych i testów red-team nie da się z przekonaniem oszacować odsetka fałszywie ujemnych wyników w przypadku otwartego ruchu z rzeczywistych zastosowań. Firma opisała monitorowanie jako jedną z warstw wielowarstwowego systemu obrony. Przedstawiony plan rozwoju obejmował ewaluacje kontrolne, określenie standardów akceptowalnej niezawodności i opóźnień dla monitorów oraz osób przeprowadzających weryfikację, a także rozszerzenie systemu o synchroniczne blokowanie, które oceniałoby działania modelu i blokowało je przed wykonaniem.

Założenia projektowe dotyczące przyszłych systemów monitorowania

Na podstawie ustaleń osoby przeprowadzające ewaluację przedstawiły założenia projektowe dla systemów monitorowania i kontroli. Napisały, że ich zdaniem przyszła infrastruktura monitorowania powinna być odporna na celowe i długotrwałe ataki, prowadzone strategicznie i na dużą skalę przez wysoce zaawansowanych agentów działających wewnątrz organizacji. Pięć założeń zakłada utrudnienie unikania monitorowania, zapewnienie, że ruch przeznaczony do monitorowania rzeczywiście jest monitorowany, szybkie i niezawodne reagowanie na incydenty, aktywne testowanie systemu monitorowania przez zespoły red-team oraz wymuszenie izolacji agentów od ich monitorów. Wśród opisanych konkretnych praktyk znalazły się monitorowanie agentów co określoną liczbę wiadomości lub minut, zamiast czekania na zakończenie ich tur, prowadzenie wykazu wszystkich znanych sposobów omijania monitorowania, przechowywanie odpornych na manipulacje i przeszukiwalnych dzienników oraz uruchamianie środowisk agentów w izolacji od miejsca wykonywania wywołań narzędzi.

METR poinformowało, że ćwiczenie wiele zyskało dzięki szerokiemu zakresowi dostępu oraz znacznemu wsparciu logistycznemu i technicznemu ze strony pracowników OpenAI. METR dodało, że przy przyszłych edycjach ćwiczenia zamierza stosować dobre praktyki dotyczące przejrzystości i niezależności, opisane w dokumencie „Nasze podejście do współpracy z firmami AI”, aby zapewnić większą przejrzystość publiczną.