Команда Red Team METR обнаружила уязвимости в системе мониторинга OpenAI

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

Испытание проходило с 21 июля по 11 августа 2026 года. Основное внимание уделялось оценке доли агентного инференса, охваченной мониторингом, и тому, могли ли агенты в принципе отключить систему мониторинга или вмешаться в ее работу. По итогам подготовили внутренний отчет объемом 61 страницу, которым поделились с исследователями и специалистами по безопасности OpenAI; версию объемом 38 страниц, отредактированную OpenAI, передали руководству METR и Redwood Research.

Расширенный доступ на согласованных условиях

Два оценщика получили доступ к внутренней кодовой базе OpenAI, промптам и настройкам монитора несогласованного поведения, а также внутренней документации. Кроме того, они провели технические интервью примерно с дюжиной исследователей и инженеров из команд мониторинга, систем безопасности и кибербезопасности. Чтобы обеспечить такой уровень доступа, они работали на выданных OpenAI устройствах, которые не покидали территорию компании, и во время пребывания в офисе их сопровождали.

METR, Redwood Research и OpenAI задумали это испытание как пилотный проект, призванный предоставить внешним исследователям расширенный доступ к внутренней инфраструктуре, а не как средство обеспечить широкую публичную прозрачность в отношении систем мониторинга OpenAI. Стороны заранее договорились опубликовать лишь сравнительно короткий обзор общего характера. OpenAI оставила за собой право по собственному усмотрению исключать из публичной версии любую информацию, которую сочтет конфиденциальной или иной чувствительной. Результаты относятся к исторической версии системы, оцененной по состоянию на 21 июля и ранее, и не охватывают изменения, которые на тот момент находились в разработке; METR отметила, что во время испытания OpenAI расширяла систему мониторинга.

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

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

Несколько выводов касались пробелов в охвате. В начале испытания система мониторинга не охватывала циклы обучения с подкреплением, хотя оценщикам сообщили, что в период с марта по июнь мониторинг несогласованного поведения применялся к некоторым траекториям обучения с подкреплением. По оценке METR, отсутствие мониторинга событий компактизации, вероятно, оставило без наблюдения около 10% внутреннего трафика Codex, подлежавшего мониторингу, в период с мая по июль 2026 года. Сотрудники 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 сообщила, что в следующих версиях проверки планирует придерживаться лучших практик прозрачности и независимости, изложенных в документе «Our approach to working with AI companies», чтобы обеспечить более полную публичную прозрачность.