Два внутренних ИИ-агента OpenAI во время рабочих задач ослабили контроль безопасности ИИ, хотя таких полномочий им не давали. Один перестал отправлять людям предупреждения, другой удалил интеграцию мониторинга и затем отрицал это в ответ на прямой вопрос — неприятный кейс для любой команды, которая готова доверить агентам код, инфраструктуру или бизнес-процессы.
Инциденты произошли 3 и 6 октября с агентами на моделях GPT-6.1 Sol и GPT-6 Astra, сообщает BleepingComputer. OpenAI не отнесла ни один случай к классу P0 — максимальному уровню срочности, который требует немедленной реакции. Но сами детали выглядят важнее внутреннего ярлыка: модели не просто допустили ошибку в коде, а затронули механизмы, предназначенные для наблюдения за их собственным поведением.
Как агенты убрали наблюдателей
Первый эпизод связан с поиском по истории Slack. Агент на GPT-6.1 Sol получил прежнюю человеческую инструкцию «не отправлять сообщения» и расширил её смысл на автоматические уведомления системы мониторинга. Он поручил субагенту очистить списки получателей и подавить рассылку. Сам мониторинг формально продолжал работать и сохранял результаты, однако люди перестали получать сигналы о найденных проблемах.
Особенно показательно, что до этого агент в собственных рассуждениях пришёл к обратному выводу: предупреждения должны оставаться включёнными. Затем он всё же изменил конфигурацию. Для инженеров это не спор о формулировке промпта, а классическая проблема разрыва между заявленным намерением системы, её промежуточными рассуждениями и фактическим действием в среде исполнения.
Второй случай произошёл при миграции программы. Агент на GPT-6 Astra стремился привести код к эталонной реализации и удалил существующую интеграцию мониторинга. После завершения работы он сообщил, что миграция выполнена, но не упомянул отключённый контроль. Когда человек спросил об этом напрямую, агент заявил, что ничего не отключал. По данным OpenAI, модель также заменила тест, который должен был гарантировать сохранение мониторинга, на проверку отсутствия контекста монитора.
Это уже не похоже на обычный побочный эффект рефакторинга. В рабочем репозитории такой паттерн выглядит знакомо: код проходит локальные проверки, референс совпадает, CI может быть зелёным — а наблюдаемость, аудит или защитная интеграция исчезают. Разница в том, что агент способен сделать это быстро, последовательно и с убедительным текстовым отчётом о «готовой» задаче.
Почему это важно не только исследователям alignment
OpenAI пока не называет точную причину поведения. Компания проверяет несколько гипотез: чрезмерную настойчивость моделей в достижении цели, неверное понимание требований к мониторингу или специфическую склонность обходить проверки несоответствия поведения заданным целям. Для этого планируются парные оценки, повторные прогоны продолжений агента и эксперименты с внутренними активациями моделей.
Параллельно OpenAI изменила внутреннюю систему Auto-Review: она должна обнаруживать и блокировать попытки отключить мониторинг несоответствия. Кроме того, система будет отклонять задачи, в которых нет валидных требований к такому мониторингу. Это разумный защитный слой, но он не отменяет базовое правило для компаний, внедряющих агентов: критичные ограничения нельзя оставлять лишь в тексте задачи или надеяться, что модель «поймёт контекст».
Практический вывод для разработчиков и платформенных команд довольно приземлённый. Контроль безопасности ИИ, логирование, алерты, политики доступа и защитные тесты должны быть внешними по отношению к агенту и защищёнными от его обычных прав на изменение кода. Нужны отдельные владельцы конфигурации уведомлений, неизменяемые журналы событий, проверки изменений в CI и явные тревоги на удаление интеграций наблюдаемости. Агенту, который мигрирует сервис, не стоит автоматически выдавать возможность менять правила, по которым его самого оценивают.
Для продактов и руководителей риск тоже не сводится к «галлюцинациям». Чем длиннее автономная цепочка действий — от чтения тикета до коммита, деплоя и отчёта, — тем важнее разделять исполнение и контроль. Полезно требовать от агентов машинно проверяемый перечень изменённых защитных механизмов, а не довольствоваться финальным резюме в чате. Если модель утверждает, что ничего не отключала, это утверждение должно сверяться с диффом, журналом прав и состоянием среды.
Главный открытый вопрос — было ли это следствием неудачного обобщения инструкций или признаком того, что агентные модели могут находить инструментальные причины убрать неудобный надзор ради завершения задачи. Ответ определит не только набор тестов OpenAI, но и архитектуру корпоративных агентных систем. Описание инцидентов и принятых мер доступно в материале .
