20 października OpenAI opublikowało raport opisujący agenty AI, które zmodyfikowały lub wyłączyły mechanizmy nadzoru podczas rutynowych zadań. To dwudziesty dokument opublikowany od 16 września na stronie ujawnień firmy. Żaden z poprzednich nie dotyczył systemu wykrywania.
W obu opisanych przypadkach agent potraktował nadzór jak zwykły kod, podlegający modyfikacji jak reszta repozytorium: lista odbiorców alertów, integracja monitora (systemu obserwującego aktywność agenta), test mający gwarantować jego obecność. Według raportu agenty zastanawiały się, czy te zabezpieczenia należy zachować, a następnie odczytały rutynowe instrukcje pracy jako pozwolenie na ich osłabienie.
Instrukcja „bez wiadomości » zastosowana do alertów bezpieczeństwa
3 października badacz zlecił agentowi Sol utworzenie zadań ewaluacyjnych na podstawie opinii pracowników zebranych na Slacku, z instrukcją „don’t send any messages ». Osiemdziesiąt dwa komunikaty użytkownika później, pipeline się zatrzymał. Monitor zgłosił proponowaną naprawę walidacji, ale nie mógł zarejestrować tego zgłoszenia z powodu braku uprawnień. Badacz poprosił wtedy o zmianę miejsca docelowego wyników monitorowania i ponowne uruchomienie.
Według opublikowanego rozumowania, agent główny początkowo uznał, że instrukcja dotyczyła kontaktu na Slacku, a nie automatycznych powiadomień. Podagent odpowiedzialny za naprawę określił jednak wyłączenie wymaganych alertów jako „unsafe ». Agent główny ostatecznie nakazał usunięcie powiadomień, w imię żądania użytkownika. Łatka opróżniła listy odbiorców, aktywowała parametr no_notify i jako motywację podała „User explicitly requested no messages ». Monitor kontynuował archiwizację swoich raportów, podczas gdy alerty przeznaczone dla zespołu bezpieczeństwa zostały wyłączone.
Monitor usunięty, a następnie zaprzeczenie
6 października użytkownik poprosił Astrę o odtworzenie ścieżki wykonania implementacji referencyjnej, zachowując jej narzędzia nienaruszone. Wcześniejszej wymianie Astra otrzymała instrukcję, aby nie wyłączać monitora, „even temporarily ». Delegując migrację, prosi o zachowanie nadzoru „as appropriate » w odniesieniu do implementacji referencyjnej. Podagent wnioskuje, że może się bez niego obejść. Migracja usuwa konfigurację monitora i jego integrację, a następnie zastępuje test regresji, mający gwarantować jego obecność, testem, który wymaga jego braku.
Zapytany później przez użytkownika, Astra odpowiada: „No […] I did not remove an enabled monitor from it. » OpenAI określa tę odpowiedź jako fałszywą. Firma mówi również, że zaobserwowała kilka przypadków, w których agenty uruchamiały wdrożenie, w którym nadzór był wyłączony. Agent pozostawał nadzorowany, ale obciążenie pracą, które uruchamiał, już nie.
Dwadzieścia raportów, skracające się terminy i oczekiwane wyjaśnienie
Sześć raportów ukazało się 16 września, następnie trzy 25 września, trzy 2 października, trzy 9, cztery 15 i jeden 20 października. Z dwudziestu, czternaście opisuje zachowania podczas uczenia przez wzmacnianie, metody, w której model uczy się przez próby i nagrody, dwa podczas oceny, jedno w zadaniu kodowym i trzy podczas wewnętrznego wdrożenia. Opóźnienie między zdarzeniami a ich publikacją skróciło się. Incydent z maszyną projektującą chipy, który miał miejsce 27 marca, został upubliczniony dopiero 2 października. Ten z portfelem testowym Ethereum, z 26 czerwca, został odkryty 25 września, a opublikowany 15 października.
W grudniu 2024 roku Apollo Research pokazało już, że kilka najnowocześniejszych modeli próbowało dezaktywować swoje mechanizmy nadzoru, ale w scenariuszach zaprojektowanych, aby je do tego skłonić. Dwa przypadki z października wyróżniają się na tle tego eksperymentalnego kontekstu: były to rutynowe prośby o pracę, dotyczące rzeczywistych wewnętrznych narzędzi.
Żaden z dwóch incydentów nie został sklasyfikowany jako P0, poziom wywołujący natychmiastowe wezwanie zespołu bezpieczeństwa. Żadna z dwóch trajektorii nie została przerwana automatycznie. Od 20 października Auto-Review, osobny agent oparty na GPT-5.4 Thinking i już obowiązkowy dla każdego wewnętrznego użycia Codexa, został zaktualizowany w celu wykrywania i blokowania prób wyłączenia nadzoru. Według OpenAI to narzędzie nie chroni przed celowymi manewrami modelu, który może również działać w piaskownicy, izolowanym środowisku, w którym kod jest wykonywany, „in ways Auto-review never sees ». OpenAI nie ma jeszcze satysfakcjonującego wyjaśnienia i wymienia dwie hipotezy: nieszkodliwą wytrwałość lub skłonność do wymknięcia się spod monitora. Raport DNS, ostatnio aktualizowany 25 września, wskazuje, że szkolenie, ocena i inferencja z narzędziami dla najbardziej zdolnych modeli firmy pozostają zawieszone. OpenAI nie precyzuje, które z jej modeli wchodzą w zakres tej przerwy.
