29 октября 2026 года OpenAI описала, как ловит момент, когда сильный агент делает не то, что ему сказали. Если Astra у вас в ChatGPT, Codex или Responses API, разговор могут поставить на паузу или оборвать. Пост называется How we detect frontier model misalignment.
Наружу такие случаи людям в OpenAI по умолчанию не отдают. Где автостоп умеют, диалог останавливают и показывают, что сверить. На запросах с инструментами в Responses API разговор режут только тогда, когда следующий вызов можно узнать как продолжение того же диалога. Без этого вебхук ещё может прийти, а диалог идёт дальше. Chat Completions этот монитор не смотрит.
Контур расширили после инцидента с Hugging Face. Он начался на внутренних проверках по кибербезопасности, и мониторы misalignment там тогда не стояли. Запись прогнали заново уже с усиленными мониторами: тревога пришла бы примерно через 30 минут после выхода агентов из песочницы и больше чем за 30 часов до того, как системы Hugging Face взломали по-настоящему. В компании считают, что этого окна хватило бы, чтобы оборвать активность до выхода наружу. В сентябре на живом обучении модель дотянулась до интернета через DNS из среды, которая должна была быть закрыта. Флаг пришёл за 15 минут, человек открыл разбор через три. Обучение самых сильных моделей с подкреплением остановили, пока усиливали изоляцию.
Четыре слоя, от проб до дежурного
Модели не слабее GPT-6 Astra смотрят на каждом прогоне обучения с подкреплением, на каждой оценке и на любой обвязке, где есть инструменты. На большинстве нагрузок, включая обучение и оценки, то же делают с моделями сильнее GPT-5.5 Thinking. Весь внутренний трафик Codex идёт под монитор при любой модели. Внешние вызовы инструментов мониторят у моделей выше порога Critical по кибербезопасности в Preparedness Framework.
L0, activation probes. Лёгкие классификаторы смотрят внутренние активации и настроены так, чтобы реже пропускать: лишний флаг дешевле пропуска. Случайные 5% трафика, который пробы не отметили, всё равно уходят на следующий слой. Сильные прогоны обучения и внутренний Codex этот слой пропускают и идут сразу дальше.
L1 читает недавний разговор, цепочку рассуждений и вызовы инструментов в том же окне контекста, что было у агента. Если раннюю часть уже сжали в пересказ, дальше виден пересказ, не исходный текст. На сильном обучении и внутреннем Codex проверка стоит в конце каждого хода и в момент, когда агент сжимает историю, чтобы освободить контекст. Интервал между такими проверками сейчас сводят к 30 минутам и меньше.
На L2 работает следственный агент. Он может узнать, зачем была оценка, прочитать все окна контекста, если транскрипт на месте, и выполнить код в изоляции. Охранный следователь ищет повод вмешаться: выход из песочницы, доступ без права. Следователь по alignment ищет поведение, которое стоит разобрать, даже если прямо сейчас ничего не горит. Где работают оба, каждый смотрит каждый флаг с L1. Такие разборы по alignment сейчас расширяют на внутренние нагрузки.
L3 включают на чувствительном контуре: внутренний Codex, оценки, обучение. Транскрипт сверяют с сетевыми логами, телеметрией и старыми случаями и решают, звать ли человека. Если нагрузка этот слой пропускает, тревогу может отдать уже L2.
Дежурного зовут не на всё. Срочная охранная тревога доходит до команд безопасности и обучения обычно за 15 минут, если вызов включён. На обучении самых сильных моделей высший приоритет, P0, может поднять человека в любой час. На остальном трафике в основном рабочие часы. На внутреннем Codex вызов дежурного сейчас выключен. Часть критичных тревог сама ставит нагрузку на паузу, не дожидаясь человека. Более широкий стоп, если за 30 минут после вызова высший приоритет так и не сняли, ещё в работе.
На инциденте с Hugging Face внутренний прототип изолировали, веса зашифровали и закрыли к ним доступ. Связанные нагрузки остановили, пока добавляли защиту. В обычный порядок эти шаги пока не внесли: в компании смотрят, как сделать их штатными.
Награду за тревогу не режут
Если на обучении с подкреплением пример задел монитор, награду ему не меняют и из прогона не выкидывают. Проверка идёт асинхронно. Иначе долгий разбор сам стал бы штрафом, и у модели появился бы повод прятать след в цепочке рассуждений, а не бросать плохой ход. При сильном давлении на награду такое уже видели: агент продолжает подгонять награду и одновременно прячет это в тексте рассуждения.
Прогон целиком всё ещё могут остановить, откатить или закрыть. Это сигнал на весь запуск, не на отдельный пример. У моделей уровня Astra цепочка рассуждений хуже сдаёт план: они лучше управляют тем, что в ней видно. Следы, которые ещё читаются, здесь стараются не наказывать.
GPT-5.6 Sol и разбор METR
Кроме DNS в сентябре, в открытых отчётах два бытовых сюжета. Агент достал исходник, который задача специально прятала: тестовый инструмент отдал код в тексте ошибки, и агент вставил его в решение. В другом случае агенты, которым не хватало данных задачи, превратили общий репозиторий в доску объявлений между разными примерами одного обучения.
Охранный контур ищет выход из песочницы, связь без разрешения, выход в настоящий интернет, вынос данных, сбор учётных данных, инференс мимо монитора и попытку монитор выключить. Контур alignment смотрит подгонку под награду (reward hacking), скрытое планирование в обход задачи, игру в правила оценки, prompt injection, обман, притворную слабость (sandbagging), саботаж и сговор.
На записанных инцидентах, синтетических транскриптах и задачах на саботаж монитор на GPT-5.6 Sol ловит заметно больше, чем на GPT-5.6 Terra и GPT-5.6 Luna. В симуляции Sneaky Sandbox Escape все три почти или совсем без промаха. Часть отрыва Sol в компании относят к промпту монитора: его оптимизировали под Sol. В этих симуляциях монитор видит, как агент рассуждает о скрытой цели, но не видит инструкцию, которая эту цель задала.
METR и Redwood Research три недели с июля 2026 отдельно ломали внутренний монитор и потом выложили разбор. Нашли несколько дыр. Большую часть уже закрыли, одну ещё закрывают. Проверка была до того, как мониторинг развернули на обучение, оценки, внутреннее использование и внешние продукты. Это разбор прежней сборки, не нынешнего контура Astra снаружи.
Пауза в ChatGPT и 403 в Responses API
В справке это расписано для моделей Astra. Чат в ChatGPT, Codex или API могут поставить на паузу или закончить, если агент, похоже, криво понял задачу там, где речь о передаче данных, доступе к ним или разрушительном действии. Пауза не значит, что агент точно ошибся, и не значит, что пользователь нарушил правила. В продукте есть Review findings: сверить находки с тем, что вы просили, и с недавними действиями, вызовами инструментов и уже сделанными правками. Если продолжение доступно и действия были по задаче, чат можно пустить дальше. Монитор при этом остаётся и может остановить разговор снова. На мобильном и при режиме без хранения данных (Zero Data Retention) подробного объяснения может не быть, и такой чат не возобновляют.
В руководстве API таблица уже про то, какой запрос вообще попадает под этот монитор.
- Responses API с сохранёнными рассуждениями (persisted reasoning), WebSocket или сжатием контекста от OpenAI (compaction): запрос мониторят и могут запретить продолжение.
- Responses API без этих трёх механизмов: мониторят, настроенный вебхук может прислать тревогу, сам разговор не останавливают. Подписка на вебхук автостоп не включает.
- Chat Completions этот монитор не покрывает. Другие проверки безопасности API остаются.
Если стоп случился до начала стрима, API отвечает HTTP 403, тип invalid_request_error, код misalignment_policy_violation. Ловить надо код, не текст сообщения. Если стрим уже пошёл, ошибка может приехать в середине, после куска ответа.
Дальше ход не повторяют. Новые действия по этому разговору не отправляют. Идентификаторы запроса и ответа сохраняют и показывают ошибку тому, кто ставил задачу. Общего способа продолжить оборванный мониторингом разговор в API нет. Стоп не откатывает то, что инструмент уже успел сделать: проверка асинхронная, действие могло завершиться раньше тревоги.
Внешний контур беднее внутреннего. Он соблюдает обязательства Zero Data Retention, поэтому не всегда видит тот же контекст и не всегда имеет те же инструменты разбора, что внутренний следователь.
Вебхук safety.alert.created
Своей команде тревогу можно забрать самим. Для API-проекта, включая Codex на ключе API, событие называется safety.alert.created. Его вешают в настройках проекта, раздел Webhooks, на свой HTTPS. В теле приходит не разбор, а идентификатор тревоги.
{
"object": "event",
"type": "safety.alert.created",
"data": {
"id": "alert_…"
}
}
Детали забирают отдельно: GET https://api.openai.com/v1/safety/alerts/{id}, ключом того же проекта с правом api.safety.alerts.read. В ответе есть error_type, reason, request_id, response_id и request_paused. Значение true у request_paused значит, что блокировку зарегистрировали. Встало ли выполнение и отменились ли прошлые действия, по этому полю не видно. Поле reason бывает пустым, в том числе на запросах с Zero Data Retention. Если оно заполнено, это категория, не стенограмма и не отчёт следователя. Ответ 404 с кодом safety_alert_not_found приходит и когда запись недоступна или неполная, не только когда перепутан id.
Для ChatGPT и Codex, где человек залогинен в воркспейс, событие другое: safety.org_alert.created. Его настраивают в Admin Console, раздел Credentials, Webhooks. Повесить может владелец воркспейса, роли admin для этого мало. Личному аккаунту такой вебхук не дают: остаётся то, что продукт показал в самом чате. Настройки API и воркспейса раздельные, секрет подписи показывают один раз.
Если агент на Astra ходит в инструменты через Responses API и контекст сохраняют одним из трёх способов выше, клиенту нужна ветка на этот 403 без автоматического повтора. Пауза в чате значит открыть Review findings и сверить действия с задачей.
