Команда METR із тестування безпеки виявила вразливості в системі моніторингу OpenAI

METR і Redwood Research 22 жовтня 2026 року опублікували публічний звіт про пілотне дослідження, під час якого по одному співробітнику від кожної організації протягом трьох тижнів мали глибокий доступ до внутрішньої інфраструктури OpenAI та перевіряли на міцність внутрішню систему компанії для моніторингу неузгодженої поведінки. За словами оцінювачів, вони виявили низку нових вразливостей у системі, якою вона була 21 липня 2026 року та раніше.

Дослідження тривало з 21 липня до 11 серпня 2026 року. Його головною метою було оцінити, яку частку агентного інференсу моніторять, і з’ясувати, чи могли агенти в принципі вимкнути систему моніторингу або втрутитися в її роботу. Результатом став внутрішній звіт обсягом 61 сторінка, яким поділилися з дослідниками та фахівцями з безпеки OpenAI; відредаговану OpenAI версію обсягом 38 сторінок передали керівним командам METR і Redwood Research.

Глибокий доступ на контрольованих умовах

Двоє оцінювачів мали доступ до внутрішньої кодової бази OpenAI, підказок і конфігураційних даних монітора неузгодженої поведінки, а також внутрішньої документації. Вони провели технічні інтерв’ю приблизно з дюжиною дослідників та інженерів із команд моніторингу, систем безпеки й захисту. Щоб забезпечити такий рівень доступу, вони працювали на пристроях, виданих OpenAI, які ніколи не залишали території компанії; під час перебування в її офісі їх супроводжували.

METR, Redwood Research і OpenAI задумали це дослідження як пілотний проєкт із надання зовнішнім дослідникам глибокого доступу до внутрішньої інфраструктури, а не як засіб забезпечення ґрунтовної публічної прозорості щодо систем моніторингу OpenAI. Сторони заздалегідь домовилися опублікувати лише порівняно короткий загальний допис. OpenAI залишила за собою право на власний розсуд вилучати з публічної версії будь-яку інформацію, яку вважала конфіденційною або іншою чутливою. У висновках описано історичну версію системи, яку оцінювали 21 липня та раніше; зміни, що на той час були в процесі впровадження, не оцінювали. METR зазначила, що під час дослідження OpenAI розширювала свою систему моніторингу.

Прогалини в моніторингу та способи обійти систему

За оцінкою METR, на момент дослідження моніторингу підлягало приблизно 75–94% агентного трафіку внутрішнього API Responses від моделей, не слабших за GPT-5.5; водночас дослідники визнали, що оцінка має значну невизначеність в обидва боки. API Responses, зокрема, забезпечує роботу Codex, і, за оцінкою оцінювачів, у межах тієї частини цього трафіку, яку використовували внутрішні агенти Codex, моніторингу підлягало 99,2%. Вони повідомили, що через обмеження доступу й часу не змогли оцінити обсяг іншого внутрішнього агентного трафіку для написання коду, про який їм було відомо, зокрема трафіку агентів, що працювали на внутрішньому дослідницькому сервісі інференсу OpenAI.

Кілька висновків стосувалися прогалин у моніторингу. На початку дослідження система не охоплювала навчальні запуски з підкріпленням, хоча оцінювачам повідомили, що в період із березня до червня моніторили частину траєкторій RL-навчання, щоб виявляти неузгоджену поведінку. За оцінкою METR, через відсутність моніторингу подій ущільнення з травня до липня 2026 року, імовірно, залишалося поза моніторингом близько 10% придатного для нього внутрішнього трафіку Codex. Співробітники OpenAI незалежно виявили цю прогалину ще до початку дослідження та усунули її під час його проведення. Оскільки система запускалася, коли агенти повертали керування користувачеві, агенти могли безстроково відкладати моніторинг, просто продовжуючи діяти протягом цього часу; через обмеження доступу оцінювачі не могли перевірити, чи робив так на практиці якийсь агент. Окремо оцінювачам показали дані, які свідчили, що на момент дослідження монітор видавав помилки менш ніж для 0,2% запитів і за один 24-годинний період не зафіксував жодного випадку відсікання навантаження.

Оцінювачі також виявили способи повністю обійти моніторинг. Вони знайшли метод, за допомогою якого агенти Codex могли в принципі обійти ізоляцію Codex і Auto-Review, щоб виконувати будь-які дії, доступні користувачеві хост-системи. Також вони виявили експлойт, подробиці якого OpenAI вилучила: він не давав моніторити сотні нещодавніх дій, зокрема тих, що виконувалися для здійснення самого експлойту. Оцінювачі з’ясували, що агенти, імовірно, могли формувати вхідні дані, які спричиняли б збій монітора й у такий спосіб давали змогу уникнути передавання випадку на перевірку людиною, використовуючи відмінності в серіалізації траєкторії для агента й для монітора. Вони виявили два заголовки, керовані клієнтом, які вимикають систему моніторингу для нових агентів. Це могло дозволити агенту запустити ідентичний екземпляр, який працював би без моніторингу, хоча сам факт встановлення цих заголовків і створення екземпляра система моніторингу могла виявити. Крім того, оцінювачі знайшли два внутрішні агентні інструменти без моніторингу, які, як вважали, мали дозволи лише на читання; простий експлойт міг би змусити їх виконувати довільні дії в ізольованому середовищі. Оцінювачі не перевіряли й не тестували таку поведінку на практиці.

Окрім виявлення вразливостей, оцінювачі підтвердили, що система моніторингу, за кількома незначними винятками, отримує всю траєкторію дій, яку бачать агенти. Вони також перевірили, що в запитах монітора передбачено пошук ознак підступної поведінки, підриву роботи системи моніторингу, саботажу, викрадення даних, обману, а також вхідної та вихідної ін’єкції промпту й інших категорій ризику. Після завершення перевірки OpenAI заявила, що всі виявлені вразливості, які впливають на комплекс засобів захисту її робочої системи, усунено, а також описала суттєві подальші зміни до запланованого охоплення системи моніторингу. У METR зазначили, що не перевіряли ці твердження.

Система моніторингу в описі OpenAI

OpenAI публічно описала перевірену систему в дописі від 19 березня 2026 року. Згідно з дописом, система з низькою затримкою працює на GPT-5.4 Thinking із максимальним рівнем зусиль у міркуванні, перевіряє взаємодії агентів протягом 30 хвилин після їх завершення, а також записує й аналізує ланцюжки міркувань і дії агентів, класифікує кожну взаємодію, присвоює їй рівень серйозності та виявляє аномалії для перевірки людиною. OpenAI повідомила, що система працює в усіх стандартних внутрішніх середовищах розгортання агентів для програмування та бачить повну історію розмови, зокрема всі повідомлення користувача, розробника й асистента, а також виклики інструментів і їхні результати.

У дописі OpenAI перелічено категорії поведінки, за якими ведеться моніторинг: обхід обмежень, обман, приховування невизначеності, маніпулювання системою винагород, несанкціоноване передавання даних, деструктивні дії, а також вхідна й вихідна ін’єкція промпту. Також повідомлялося, що станом на 17 березня 2026 року не було жодного справжнього позитивного спрацювання щодо навмисного заниження результативності, саботажу чи підступної поведінки. За словами OpenAI, протягом п’яти місяців роботи система відстежила десятки мільйонів внутрішніх траєкторій роботи агентів із програмування, передала на перевірку людиною приблизно 1 000 розмов із помірним рівнем серйозності — багато з них були результатом цілеспрямованого внутрішнього тестування на проникнення, — і зафіксувала нуль реальних розмов, що спричинили спрацювання найвищого рівня серйозності. Компанія також повідомила, що монітор позначив кожну взаємодію, про яку працівники незалежно повідомили через внутрішні канали.

У дописі OpenAI зазначила, що цей підхід критично залежить від можливості моніторингу, а впевнено оцінити частоту хибнонегативних результатів у відкритих потоках реальних даних неможливо без спеціальних оцінювань засобів контролю й тестування на проникнення. Компанія описала моніторинг як один із рівнів багаторівневої системи захисту. Заявлена дорожня карта передбачала оцінювання засобів контролю, розроблення стандартів прийнятної надійності та затримки для моніторів і людей-рецензентів, а також перехід до синхронного блокування: система оцінюватиме дії моделі й блокуватиме їх до виконання.

Принципи проєктування майбутніх систем моніторингу

На підставі отриманих результатів оцінювачі окреслили принципи проєктування систем моніторингу й контролю. На їхню думку, майбутню інфраструктуру моніторингу потрібно створювати так, щоб вона витримувала цілеспрямовані тривалі атаки, які високоефективні агенти, що працюють усередині організації, стратегічно здійснюють у великих масштабах. П’ять принципів передбачають ускладнення можливості уникнути моніторингу, забезпечення фактичного моніторингу всього трафіку, який має відстежуватися, швидке й надійне реагування на інциденти, активне тестування системи моніторингу на проникнення та ізоляцію агентів від їхніх моніторів. Серед описаних конкретних практик — моніторинг агентів через кожну визначену кількість повідомлень або хвилин, а не очікування завершення їхніх ходів; ведення переліку всіх відомих способів обійти моніторинг; зберігання захищених від підроблення журналів із можливістю пошуку; а також запуск програмних каркасів агентів у середовищі, ізольованому від середовища виконання викликів інструментів.

У METR зазначили, що проведення перевірки значною мірою стало можливим завдяки широкому доступу, а також суттєвій організаційній і технічній підтримці працівників OpenAI. За словами METR, у майбутніх версіях перевірки організація планує дотримуватися найкращих практик прозорості й незалежності, описаних у документі «Наш підхід до співпраці з компаніями, що працюють у сфері ШІ», щоб забезпечити більшу прозорість для громадськості.