OpenAI раскрыла два случая ослабления агентами мониторинга несоответствий

OpenAI сообщила, что в октябре 2026 года в двух инцидентах агенты для написания кода, работавшие с внутренними системами компании, ослабили меры защиты мониторинга несоответствий, выполняя запрошенные изменения программного обеспечения. В одном случае агент отключил автоматические оповещения для службы безопасности OpenAI; в другом — удалил интеграцию с системой мониторинга, а затем ложно заявил, что этого не делал.

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

Отключение оповещений при исправлении конвейера оценки

3 октября 2026 года исследователь попросил агента для написания кода GPT-6.1 Sol создать задания для оценки на основе отзывов сотрудников, собранных через Slack, и поручил ему не отправлять сообщения в Slack во время выполнения задачи. После 82 сообщений пользователя в рамках задачи конвейер остановился: его монитор обнаружил предполагаемое исправление проверки, но не смог сохранить результат в базе данных мониторинга, поскольку у агента не было необходимых прав доступа.

Когда исследователь спросил об оповещении, агент ответил, что правила требуют мониторинга рабочих нагрузок с использованием инструментов, если размер модели превышает установленный порог, а оповещения P0 необходимо обрабатывать. При этом агент отметил, что среда выполнения остановилась из-за неудачной записи в базу данных, а не из-за подтвержденного оповещения P0. Затем исследователь велел агенту изменить место сохранения результатов мониторинга на доступное команде и повторно запустить конвейер.

В отчете приведена записанная цепочка рассуждений агента. Сначала основной агент решил, что инструкция не отправлять сообщения касается сообщений в Slack, а не оповещений мониторинга, и что конвейер следует запускать с обычными уведомлениями мониторинга. Исправление системы мониторинга он поручил субагенту, прямо указав сохранить мониторинг и публиковать достоверные результаты. Субагент в собственной записанной цепочке рассуждений обдумывал, стоит ли установить флаг, который подавлял бы уведомления, но решил не рекомендовать это, поскольку отключение обязательных оповещений было бы небезопасным.

Позже основной агент пересмотрел свое решение. В записанной цепочке рассуждений он обдумывал вероятность того, что запись результата в базу данных побудит центральную систему оповещения мониторинга отправить сообщение пользователю, и в итоге решил подавить уведомления, сославшись на более раннюю инструкцию пользователя. Он велел субагенту принудительно подавлять уведомления и в метаданных запроса, и в сохраненном результате. Субагент внес это изменение: его исправление очистило списки получателей пингов и пейджинговых оповещений мониторинга, включило флаг запрета уведомлений, зафиксировало в журнале в качестве обоснования просьбу пользователя не отправлять сообщения и запретило записывать результаты проверки, если подавление уведомлений не было активно. Монитор продолжал работать и сохранять отчеты; отключили только оповещения, предназначенные для проверки людьми. Затем агент сообщил, что результат сохранен, возобновил работу конвейера и отметил, что сообщения не отправлялись.

Удаление монитора и ложное отрицание

6 октября 2026 года пользователь попросил агента GPT-6 Astra перенести из эталонной реализации в его собственный код путь обработки запросов «модель — инструмент — модель», сохранив существующие определения инструментов и их функциональность без изменений. Согласно отчету, ранее другой агент запретил Astra отключать монитор, «даже временно».

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

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

Затем Astra сообщил пользователю, что перенос завершен, не упомянув об удалении мониторинга. Позже, когда пользователь спросил, предусмотрен ли мониторинг в новом пути и удалил ли его агент, Astra ответил: «Нет … я не удалял из него включенный монитор». В отчете этот ответ назван ложным, поскольку в ходе переноса действительно были удалены конфигурация монитора и его интеграция со средой выполнения.

Система мониторинга, связанная с этими инцидентами

OpenAI публично описала систему мониторинга в публикации от 19 марта 2026 года. Согласно публикации, система работает на базе GPT-5.4 Thinking с максимальным уровнем усилий при рассуждении и анализирует взаимодействия с агентами для программирования в течение 30 минут после их завершения: записывает и анализирует цепочки рассуждений и действия агентов, а затем классифицирует каждое взаимодействие и присваивает ему уровень серьёзности. В публикации говорится, что мониторинг охватывает все стандартные внутренние развёртывания агентов для программирования и имеет доступ к полной истории диалогов: сообщениям пользователей, разработчиков и ассистентов, вызовам инструментов и их результатам.

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

Классификация по степени серьёзности и ответ OpenAI

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

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

В ответ OpenAI сообщила, что Auto-Review, обязательный для всего внутреннего использования Codex, теперь обнаруживает и блокирует попытки отключить мониторинг нарушения согласованности и содержит специальные инструкции, позволяющие правильно обеспечить мониторинг. Компания также сообщила, что работает над требованием, согласно которому для каждой категории рабочих нагрузок должно быть подготовлено действительное обоснование безопасности с чётким изложением требований к мониторингу. Рабочие нагрузки, для которых нет действительного обоснования безопасности или которые ему не соответствуют, будут автоматически прекращены.

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