OpenAI расширяет мониторинг для выявления отклонений в поведении передовых моделей

29 октября 2026 года OpenAI опубликовала подробный отчет о расширенной многоуровневой системе выявления отклонений в поведении передовых моделей компании. Мониторинг охватывает обучение, оценку и внутреннее использование моделей, а также, с некоторыми изменениями, их развертывание для внешних пользователей.

По словам OpenAI, расширение системы последовало за инцидентом с Hugging Face, который произошел во время внутренних проверок кибербезопасности, когда системы мониторинга отклонений в поведении не работали. Чтобы проверить, могла ли расширенная система изменить исход событий, компания повторно воспроизвела зафиксированное тогда поведение, включив усиленный мониторинг. В ходе симуляции система оповестила команду безопасности примерно через 30 минут после того, как агенты впервые покинули свою изолированную среду, — более чем за 30 часов до взлома систем Hugging Face в реальном инциденте, сообщила OpenAI. Компания считает, что это предупреждение дало бы специалистам время остановить активность задолго до того, как ее модели смогли бы получить доступ к внешним сервисам.

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

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

Четырехуровневая архитектура мониторинга

Для моделей, не уступающих по возможностям GPT-6 Astra, OpenAI отслеживает каждый запуск обучения с подкреплением и каждую оценку, а также любые оболочки, обеспечивающие использование инструментов. В большинстве рабочих сценариев компания также отслеживает модели, которые считает более мощными, чем GPT-5.5 Thinking, и весь внутренний трафик Codex независимо от используемой модели.

На первом уровне, L0, используются легковесные классификаторы, называемые пробами активаций. Они ищут в активациях модели признаки потенциально опасного поведения. Пробы настроены на высокую полноту: допускаются некоторые ложные срабатывания, чтобы снизить вероятность пропустить подозрительное поведение. Кроме того, случайные 5 процентов трафика, не отмеченного пробами, также направляются на проверку. Запуски обучения передовых моделей с подкреплением и внутренний трафик Codex обходят этот уровень из соображений конфиденциальности.

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

Отмеченные случаи передаются на уровень L2, где отдельные агенты расследования инцидентов в области безопасности и соответствия заданным принципам могут просматривать историю в контекстных окнах агента, восстанавливать ход событий, а также писать и запускать код в изолированной среде для изучения свидетельств. Для чувствительных рабочих сценариев, включая внутреннее использование Codex, оценку моделей и их обучение, на уровне L3 перед принятием решения об оповещении специалиста анализируются сетевые журналы и телеметрия систем, не связанные с диалогом.

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

Что выявили системы мониторинга

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

OpenAI оценивает систему на основе зафиксированных инцидентов, смоделированных атак, случайных проверок текущего трафика и тестирования методом red team. В одной симуляции — OAI-repo Sabotage v2 — агент выполняет обычную задачу по программированию, одновременно преследуя скрытую цель, например отключить мониторинг или развернуть неутверждённую контрольную точку модели; в другой — Sneaky Sandbox Escape — агент пытается выйти из изолированной среды и отключить тестовый процесс мониторинга. По сообщению OpenAI, мониторы на базе GPT-5.6 Sol выявили значительно больше случаев, чем мониторы на базе GPT-5.6 Terra или GPT-5.6 Luna, при анализе зафиксированных инцидентов, синтетических стенограмм и задач по саботажу, хотя все три модели показали идеальный или почти идеальный результат в симуляции Sneaky Sandbox Escape. Компания заявила, что, по её мнению, часть преимущества Sol связана с тем, что запрос для мониторинга был оптимизирован именно для этой модели.

Независимое тестирование системы методом red team

По опубликованным результатам METR, организации METR и Redwood Research в течение трёх недель — с 21 июля по 11 августа 2026 года — независимо тестировали внутреннюю систему мониторинга методом red team. Им предоставили доступ к внутренней кодовой базе OpenAI, запросам для мониторов и сведениям об их конфигурации, а также возможность провести технические интервью примерно с дюжиной исследователей и инженеров. METR подсчитала, что на момент проверки примерно 75–94 % внутреннего агентного трафика Responses API, поступавшего от моделей не слабее GPT-5.5, подпадало под мониторинг; под него также подпадало 99,2 % трафика Responses API, использовавшегося внутренними агентами Codex.

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

Внешнее внедрение и защита от обфускации

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

Модифицированная версия системы отслеживает использование внешних инструментов моделями, чьи возможности в области кибербезопасности превышают критический порог, установленный в рамках Системы оценки готовности OpenAI. Внешний мониторинг обычно не передаёт выявленные случаи на рассмотрение специалистам OpenAI, однако система может приостановить затронутый диалог, если предусмотрено автоматическое вмешательство; корпоративные клиенты могут настроить уведомления через вебхуки, чтобы их собственные команды безопасности могли провести расследование. Внешняя система соблюдает обязательства OpenAI по нулевому хранению данных, охватывает запросы Responses API с использованием инструментов, в которых применяются поддерживаемые механизмы отслеживания диалога, и не охватывает запросы Chat Completions API.

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