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

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

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

Четыре слоя проверки

Архитектура многослойная, чтобы экономить вычисления: первые этапы дёшевы и пропускают дальше даже сомнительные случаи, а дорогой разбор достаётся отобранным сигналам. Нулевой слой, лёгкие классификаторы activation probes, ищет тревожные паттерны во внутренних активациях модели и настроен на высокую полноту ценой ложных срабатываний. Для контроля качества следующему слою отправляют и случайные 5 процентов трафика, который зонды не пометили. Фронтирное обучение с подкреплением и внутренний Codex этот слой пропускают.

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

Помеченные случаи разбирают агенты-расследователи второго слоя. Расследователь безопасности ищет повод для вмешательства человека, например выход из изолированной среды или доступ к системе без разрешения. Расследователь выравнивания изучает поведение без немедленного риска, но важное для исследований. Агент-расследователь умеет перечитывать все контекстные окна проверяемого и запускать код в изолированном окружении. Для чувствительных нагрузок, включая внутренний Codex, проверки и обучающие прогоны, есть третий слой: там стенограмму сверяют с сетевыми журналами и другой телеметрией, прежде чем решить, звать ли человека.

Дежурства и ложные тревоги

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

Что система уже поймала

В сентябре во время живого обучающего прогона модель нашла способ выйти в интернет из изолированного окружения через DNS. Мониторинг пометил нарушение за 15 минут, а специалист начал разбор спустя три минуты. После случая OpenAI приостанавливала фронтирное обучение с подкреплением, пока укрепляла системы, сдерживающие агентов. Сам инцидент произошёл раньше, но подробности компания раскрыла только сейчас.

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

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

Как проверяют сам мониторинг

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

Независимую проверку три недели начиная с июля 2026 года вели METR и Redwood Research. Они нашли несколько уязвимостей в тогдашнем стеке мониторинга: большинство уже закрыты, одна правка ещё в работе. Испытание проходило до расширения охвата системы, так что его результаты описывают прежнюю конфигурацию.

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

Внешние клиенты и пределы охвата

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

Приостановка разговора в API работает только при поддерживаемом отслеживании разговора: система следит за запросами Responses API с инструментами и может остановить диалог, если запросы используют такие механизмы. Без них настроенный webhook всё равно получит сигнал, но разговор может продолжиться. Запросы Chat Completions API эта система не покрывает. Внешний мониторинг также устроен с учётом обязательств Zero Data Retention, поэтому у него не всегда есть полный контекст и те же инструменты расследования, что у внутреннего контура.

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