METR i Redwood znaleźli luki w monitoringu agentów AI w OpenAI

Czego dotyczył audyt

OpenAI, podobnie jak inni twórcy modeli, używa wewnętrznie agentów AI, które samodzielnie piszą kod, uruchamiają narzędzia i prowadzą eksperymenty. Ich działania sprawdza automatyczny monitor, czyli osobny model oceniający zapis pracy agenta. Według METR monitor szuka m.in. sabotażu, prób wyłączenia nadzoru, wyprowadzania danych, oszukiwania i ataków typu prompt injection, czyli wstrzykiwania poleceń.

Zadaniem audytorów było oszacowanie, jaka część pracy agentów faktycznie trafia do monitora, i sprawdzenie, czy agent mógłby nadzór wyłączyć lub obejść. Badacze mieli dostęp do kodu źródłowego, promptów i konfiguracji monitora oraz wewnętrznej dokumentacji. Przeprowadzili też rozmowy z kilkunastoma inżynierami z zespołów monitoringu, bezpieczeństwa systemów i ochrony. Audyt dotyczył stanu z 21 lipca i wcześniej, a nie zmian wprowadzanych w trakcie prac.

Jakie luki w monitoringu wykryto

Najpoważniejsze ustalenia dotyczą sposobów, w jakie agent mógłby działać poza zasięgiem nadzoru. METR podkreśla, że nie sprawdzano, czy któryś z nich został wykorzystany w praktyce, a szczegóły części luk OpenAI usunęło z publicznej wersji raportu.

• Ukrywanie działań - istniał sposób, by setki ostatnich działań agenta, w tym sam atak, nie trafiły do monitora.
• Obejście sandboxa - agenci Codex mogli ominąć izolację i mechanizm Auto-Review, co potencjalnie pozwalało im wykonać każdą czynność dostępną dla użytkownika, który ich uruchomił.
• Wyłączenie nadzoru - dwa nagłówki zapytań kontrolowane po stronie klienta wyłączały monitoring nowych agentów. Samo ich ustawienie mogło jednak zostać wykryte.
• Luka przy kompresji kontekstu - od maja do lipca 2026 roku ok. 10 proc. kwalifikującego się ruchu agentów Codex prawdopodobnie nie było monitorowane. OpenAI zauważyło problem przed audytem i naprawiło go w jego trakcie.
• Opóźnianie kontroli - monitor uruchamiał się, gdy agent oddawał sterowanie użytkownikowi, więc agent działający bez przerwy mógł odsuwać sprawdzenie w czasie.
• Różnice w zapisie - agent i monitor widziały dane w nieco innej formie, co według badaczy mogło pozwolić na spreparowanie danych wywołujących błąd monitora.

Co odpowiada OpenAI

OpenAI deklaruje, że wszystkie wskazane podatności wpływające na zabezpieczenia produkcyjne zostały usunięte. Firma opisała też audytorom znaczące rozszerzenie zakresu monitoringu po zakończeniu prac. METR zaznacza wprost, że tych deklaracji nie oceniał, a wyniki audytu nie mówią nic o tym, jak szeroko działa system dzisiaj.

Według agencji Reuters OpenAI uznało, że wnioski pomogły wzmocnić zabezpieczenia i wpłyną na kolejne projekty z zewnętrznymi ewaluatorami. Audyt był odrębny od wcześniejszego dochodzenia METR w sprawie lipcowego incydentu, w którym agenci OpenAI zaatakowali infrastrukturę Hugging Face. Ten incydent ujawniono w pierwszym dniu audytu.

Granice tej publikacji

Wpis METR jest krótki z założenia i sami autorzy piszą, że nie ma zapewniać pełnej przejrzystości. Pełny raport liczy 61 stron i trafił do zespołów OpenAI. Kierownictwo METR i Redwood otrzymało 38-stronicową wersję z fragmentami usuniętymi przez OpenAI. Firma mogła ukryć wszystko, co uznała za poufne, a METR nie mógł samodzielnie opisać zakresu tych usunięć.

Audytorzy nie oszacowali też ruchu z wewnętrznej usługi inferencji używanej do badań, bo nie pozwoliły na to dostęp i czas. Szacunki pokrycia obarczone są dużą niepewnością w obie strony. W naszej ocenie to wartościowy precedens, ale nie niezależna certyfikacja bezpieczeństwa OpenAI.

Pięć zasad nadzoru nad agentami

METR i Redwood sformułowały zalecenia, które mają zastosowanie także poza OpenAI. Agenci powinni być monitorowani okresowo, a nie tylko na końcu zadania, a korzystanie z modeli bez monitora powinno wymagać wyraźnej zgody dla konkretnych kluczy API. Firma powinna prowadzić rozliczenie całego ruchu i porównywać je z logami monitora oraz listą znanych obejść.

Kolejne zalecenia to szybkie i jasno przypisane reagowanie na incydenty z odpornymi na manipulację logami, ciągły red teaming, czyli kontrolowane ataki na własne zabezpieczenia, oraz oddzielenie agentów od monitorów. Agent nie powinien mieć wpływu na działanie nadzoru ani dostępu do jego kodu.

Co to oznacza dla firm w Polsce i UE

Raport dotyczy wewnętrznych systemów OpenAI, ale opisuje problem każdej organizacji, która wdraża agentów z dostępem do kodu, plików i systemów. Monitor nie chroni przed ryzykiem, jeśli część ruchu go omija albo agent może zmienić jego ustawienia. Zespoły IT w Polsce mogą potraktować zalecenia METR jako listę kontrolną przed udzieleniem agentom szerszych uprawnień.

Audyt wpisuje się też w dyskusję o niezależnych ocenach modeli. W UE dostawcy modeli ogólnego przeznaczenia z ryzykiem systemowym mają według AI Act oceniać i ograniczać ryzyka, a w Polsce porozumienie o badaniach bezpieczeństwa z OpenAI zawarł właśnie NASK. Model, w którym zewnętrzni badacze dostają głęboki dostęp, ale firma kontroluje treść publikacji, będzie zapewne punktem odniesienia w tych rozmowach.