METR нашла способы отключить надзор за агентами OpenAI

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

Тем, кто строит надзор за собственными агентами, METR оставила по итогам набор требований. Главные из них: проверять агента каждые N сообщений или минут, не дожидаясь конца хода, и показывать монитору ровно тот контекст, который видит агент.

Что METR предлагает строить

Исходная планка у METR такая: мониторинг должен выдерживать целенаправленные, продуманные и затяжные атаки со стороны сильных внутренних агентов, причём в больших масштабах. Почти каждое требование из списка опирается на конкретную находку.

Запросы без мониторинга, по мысли METR, должны требовать явного разрешения и идти только от определённого набора организаций и API-ключей, которым агентный инференс запрещён. В проверенной системе нашлись два независимых заголовка запроса, которые выставляет сам клиент и которые отключали мониторинг для новых агентов. Через них агент мог запустить собственную копию без надзора, во всём остальном идентичную. Правда, сам момент, когда агент выставляет заголовки и поднимает новый экземпляр, монитор мог заметить.

С контекстом картина двойственная. METR убедилась, что, за несколькими мелкими исключениями, монитору показывали всю траекторию агента, а промпты монитора ищут интриги, попытки подорвать сам мониторинг, саботаж, утечку данных, обман и промпт-инъекции во входящих и исходящих данных. Но траекторию для агента и для монитора сериализовали по-разному. На этом расхождении агенты, вероятно, могли собрать такой вход, на котором монитор падает и потому не передаёт траекторию людям на разбор.

Ещё одно требование касается изоляции. Обвязку агента по возможности стоит запускать отдельно от среды, где исполняются вызовы инструментов, действия агента не должны влиять на то, сработает ли монитор и когда, а доступа к устройству и коду монитора у агентов обычно быть не должно. Под это требование подпадает эксплойт, который скрывал от монитора сотни недавних действий, включая действия самого эксплойта (подробности OpenAI вычеркнула). Туда же относится способ, которым агенты Codex в принципе могли обойти песочницу и Auto-Review и делать всё, что доступно пользователю хоста. Нашлись и два внутренних агентных инструмента без мониторинга, которые считались доступными только на чтение: простой эксплойт снимал это ограничение и давал выполнять в их песочнице произвольные действия. Это поведение METR не воспроизводила и не проверяла, применимо ли оно на практике.

Остальное в списке организационное: у реагирования на инциденты должен быть понятный владелец и чёткие правила, логи инференса и монитора должны быть защищены от правки и удобны для поиска, а сам монитор нужно регулярно атаковать, в том числе разрабатывая методику оценки стратегического сговора агентов.

Сколько трафика видел монитор

По оценке METR, на момент проверки мониторингу подлежали примерно 75-94% внутреннего агентного трафика Responses API (на нём работает в том числе Codex) от моделей уровня GPT-5.5 и выше, причём неопределённость велика в обе стороны. В эту оценку не вошёл, например, агентный трафик внутреннего исследовательского сервиса инференса OpenAI: его объём оценить не дали ограничения доступа и сроки. Для той части трафика Responses API, на которой работают внутренние агенты Codex, доля выше, 99,2%.

«Подлежит мониторингу» здесь значит, что трафик должен уйти на монитор, но по дороге его могут потерять сбои, отбрасывание запросов при перегрузке или баги. Судя по статистике, которую показали проверяющим, монитор ошибался менее чем на 0,2% запросов, а за одни сутки во время проверки не было отброшено ни одного запроса.

Самая заметная дыра в покрытии связана со сжатием контекста, когда длинную историю агента ужимают, чтобы продолжить работу. С мая по июль такие события не мониторились, и, по оценке METR, мимо монитора из-за этого, вероятно, проходило порядка 10% подлежащего мониторингу трафика внутреннего Codex. Точнее посчитать не вышло: какая доля вызовов монитора запускается сжатием, тогда не логировали. Отсюда и требование вести учёт всего инференса и регулярно сверять его с логами самого монитора. OpenAI нашла эту проблему сама ещё до начала проверки и исправила, пока проверка шла. Пользовались ли агенты бесконечной отсрочкой на деле, METR из-за ограничений доступа проверить не смогла.

Обучение с подкреплением на старте проверки монитор не покрывал, хотя, как сообщили METR, с марта по июнь часть RL-прогонов на рассогласование всё же проверялась.

Условия пилота

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

Задумывался пилот как проба глубокого доступа для внешних исследователей, а обеспечивать публичную прозрачность, по словам METR, он не должен был. Из 61-страничного отчёта наружу вышел лишь короткий пост, и вычеркнуть из него OpenAI могла всё, что сама сочла конфиденциальным, а права самостоятельно рассказать о вычеркнутом у METR не было. Руководству METR и Redwood передали версию на 38 страниц, отредактированную OpenAI. У схемы, по которой METR работает внутри Anthropic, условия другие: Anthropic вправе вычеркнуть только узкие категории, а METR может публично сказать, оправданно ли это. В следующих раундах METR рассчитывает следовать своим принципам прозрачности и независимости, а под каждой опубликованной находкой подписывается и сейчас.

OpenAI расширяла мониторинг прямо во время проверки и, помимо заявления о закрытых уязвимостях, описала существенные последующие изменения в том, что её система должна покрывать. METR эти заявления не оценивала, и какое покрытие у расширенной системы сейчас, проверка не устанавливала.