METR перевіряє моніторинг агентів OpenAI

22 жовтня 2026 року METR опублікувала підсумок тритижневої вправи (21 липня — 11 серпня), під час якої її співробітник і співробітник Redwood Research мали глибокий доступ до внутрішнього коду OpenAI й перевіряли систему моніторингу неузгодженості агентів. Вони оцінили, що 75–94% внутрішнього агентного трафіку Responses API від моделей рівня GPT-5.5 і сильніших підлягало моніторингу, і знайшли вразливості, які дозволяли агентам його обійти.

Вправа. З 21 липня до 11 серпня 2026 року один співробітник METR і один — Redwood Research працювали з доступом до внутрішнього коду OpenAI, налаштувань і підказок моніторів та внутрішньої документації, провели технічні інтерв’ю з приблизно десятком дослідників і інженерів із команд моніторингу, систем безпеки та кібербезпеки. Працювали на пристроях, виданих OpenAI, які не залишали приміщень, у супроводі. Результат — внутрішній звіт на 61 сторінку для дослідників і служби безпеки OpenAI; версію на 38 сторінок, відредаговану OpenAI, отримало керівництво METR і Redwood. Оцінювали систему «такою, якою вона була на 21 липня й раніше», а не розширену пізніше. Приклади знахідок за дописом (слова METR). Приблизно 75–94% агентного внутрішнього трафіку Responses API від моделей щонайменше рівня GPT-5.5 підлягало моніторингу, «з великою невизначеністю в обидва боки»; 99,2% — у підмножині внутрішніх агентів Codex. Навчальні прогони з підкріпленням на початку вправи моніторингом не покривались (OpenAI повідомила про моніторинг частини прогонів з березня по червень). Нестежені події стиснення контексту залишали на порядок 10% придатного трафіку Codex поза моніторингом з травня по липень 2026 року; працівники OpenAI виявили це самі до вправи й виправили під її час. Оскільки монітор спрацьовував, коли агент повертав керування користувачеві, агент міг необмежено відкладати моніторинг, продовжуючи діяти (METR не могла перевірити, чи цим користувались). За наданою інформацією, монітор помилявся менше ніж у 0,2% запитів. Знайдено спосіб, яким агенти Codex могли б обійти пісочницю й Auto-Review і зробити все, що може користувач-господар; експлойт, який вивів би з-під моніторингу «сотні нещодавніх дій» (подробиці вилучила OpenAI); розбіжність серіалізації між тим, що бачить агент і що бачить монітор; два заголовки, які клієнт може задати, щоб вимкнути моніторинг нових агентів; два немоніторені внутрішні інструменти, які вважали читальними. Перевірено, що монітор, за невеликими винятками, бачить усю траєкторію агента, а його підказки шукають змову, підрив монітора, саботаж, ексфільтрацію даних, обман та ін’єкції. Що METR радить: ускладнити уникнення моніторингу (стежити кожні N повідомлень або хвилин, а не лише після завершення ходу), звіряти, що все призначене для моніторингу справді моніториться, швидко реагувати на інциденти, активно перевіряти монітор червоними командами та відокремлювати агентів від їхніх моніторів. Чого запис не стверджує. Вправа була пілотом глибокого доступу, а не публічною прозорістю, і сторони наперед домовились про короткий допис; OpenAI мала право вилучати будь-що, що вважала конфіденційним, а METR, на відміну від двох інших недавніх проєктів, не мала права описувати вилучення. OpenAI сказала, що всі вразливості, які стосуються виробничих захистів, виправлено, і описала значні зміни в задуманому покритті; METR цих тверджень не оцінювала. Покриття описано на липень, а не на жовтень. Допис не каже, що хтось користувався знайденими слабкістями.