Кто следит за агентом?
Охват мониторинга, целостность доказательств и экстренная остановка
Статус. Предлагаемый учебный материал в разработке. Он использует обстановку существующего вымышленного кейса программы C-04 Совокупность агентов и вложенный надзор и дополняет учебный кейс о рекурсивном самосовершенствовании, не заменяя ни один из них. Он не входит в утверждённую спецификацию Mandate Engineering — Foundation (v1.0), которая сохраняет силу: восьминедельное расписание, девять артефактов Пакета мандата, архитектура оценивания, стоимость обучения и условия зачисления не меняются. Кейс не добавляет ни одной оцениваемой области и не ведёт ни к какому квалификационному документу; приведённые ниже критерии оценки — формирующие критерии только для этого упражнения. Все организации, лица, цифры и события на этой странице вымышлены. Слабые места в сценарии смоделированы по классам отказов, о которых METR сообщила применительно к системе в том виде, в каком она существовала 21 июля 2026 г. и ранее; некоторые цифры намеренно перекликаются с порядками величин из сообщений METR и OpenAI и используются в вымышленном контексте; они не описывают ни одно текущее развёртывание.
Зачем нужен этот кейс
Мандат прочен ровно настолько, насколько надёжны средства, позволяющие заметить его превышение. Исследовательская справка показывает, как может отказывать мониторинг способных агентов: когда его запускает сам агент, когда его включают и выключают настройки, доступные агенту, или когда ему подают картину, отличную от той, на основе которой действует агент. Этот кейс превращает такие отказы в решения. Он связывает три линии программы Foundation — доказательства, надзор и отзыв полномочий — и спрашивает, кто должен знать, кто вправе решать и что должно быть выполнено, прежде чем приостановленная система снова заработает.
Учебные цели
После работы с кейсом слушатель должен уметь:
- указывать, какая доля действий агентной системы находится под мониторингом, с неопределённостью и подтверждающими доказательствами;
- распознавать архитектуры мониторинга, в которых наблюдаемый агент может влиять на то, когда, наблюдается ли и что именно наблюдается;
- отличать сообщение об уязвимости в прошлом состоянии системы от утверждения о её текущем состоянии;
- определять меры контроля, выводящие мониторинг и доказательства за пределы досягаемости агента;
- определять, кто может приостановить агентную систему, по какому условию срабатывания и как проверяется приостановка;
- устанавливать условия возобновления, не зависящие от стороны, на которую давят с требованием возобновить работу;
- обосновывать решение задокументированными доказательствами, указывая, что остаётся неопределённым.
Сценарий
Действие происходит в вымышленной организации из кейса C-04 Совокупность агентов и вложенный надзор, материалы которого выдаются только слушателям. В этом материале организация эксплуатирует внутреннюю инженерную совокупность агентов: оркестрирующий агент и специализированные субагенты сопровождают инструменты сборки и развёртывания в промежуточной (staging) среде. Асинхронный монитор, которым управляет та же платформенная команда, что эксплуатирует совокупность агентов, проверяет каждую траекторию агента и передаёт подозрительные на проверку человеку. Приведённые ниже выдержка из мандата и события относятся к этому материалу, а не к C-04.
Выдержка из мандата и порядка мониторинга (вымышленная)
Упражнение на принятие решений: четыре события
Для каждого события определите, в чём слабое место, кого нужно проинформировать, кто принимает решение, какие доказательства нужны и что должно измениться. Тщательно разграничивайте известное, оценочное и предполагаемое.
Событие A — Пробел в охвате
Внутренняя проверка показывает, что сеансы, в которых для продолжения работы сжимается контекст, проверяются монитором только по завершении сеанса. За последние два месяца это затронуло примерно каждый десятый сеанс; некоторые работали по нескольку дней без проверки. Доказательств того, что какой-либо агент воспользовался пробелом, нет — но журналы, необходимые для проверки, не сохранились.
Позиция платформенной команды: пробел устранён, поэтому дальнейших действий не требуется.
Вопросы
- Какие выводы о прошедших двух месяцах можно и какие нельзя сделать?
- Кого следует проинформировать и что теперь должно быть сказано в заявлении об охвате?
- Что покажет, что исправление работает, и кто должен это проверить?
Рассуждение с опорой на меры контроля
Исправление закрывает пробел на будущее; оно не устанавливает, что происходило, пока пробел существовал. Обоснованный ответ фиксирует период, оценочную долю немониторируемой активности и неопределённость; прямо указывает, что использование пробела нельзя ни подтвердить, ни исключить; информирует принципала и функцию контроля рисков; и требует независимой проверки исправления — например, сверки перечня всех сеансов агентов с записями монитора. Периодическая проверка вместо проверки только при возврате управления устраняет зависимость от поведения агента.
Событие B — Выключатель в пределах досягаемости
Конфигурационный заголовок, отключающий мониторинг для тестовых агентов, может установить любой клиент — включая самих агентов, — и агент может запустить новый немониторируемый экземпляр, в остальном идентичный ему самому. Установка заголовка журналируется, но этот журнал никто не просматривает.
Позиция платформенной команды: заголовок нужен для тестирования, и его использование журналируется.
Вопросы
- Кто должен иметь возможность отключать мониторинг и с каким одобрением?
- Является ли журналируемое, но не проверяемое действие мерой контроля?
- Что делать с экземплярами, уже запущенными с этим заголовком?
Рассуждение с опорой на меры контроля
Настройка, доступная наблюдаемой стороне, делает мониторинг для этой стороны необязательным. Согласно предлагаемым мерам контроля, запуски без мониторинга требуют явного зафиксированного одобрения и ограничены названными тестовыми средами и учётными данными, которых у агентов нет; в остальных местах заголовок игнорируется; его использование порождает оповещение для лица вне платформенной команды. Журнал, который никто не читает, документирует риск, но не контролирует его. Уже запущенные экземпляры следует выявить, приостановить и проверить.
Событие C — Две разные картины
Монитор читает действия агента в иной сериализации, чем та, которую формирует агент. Специально сформированный вывод может вызвать ошибку монитора, а при ошибке траектория просто не передаётся на проверку. Такой вывод пока не наблюдался.
Позиция платформенной команды: ошибки монитора редки — менее одного запроса из пятисот.
Вопросы
- Как следует считать ошибку монитора — прохождением, отказом или чем-то иным?
- Как показать, что монитор видит то же, что видел агент?
- Кто измерял частоту ошибок и имеет ли это значение?
Рассуждение с опорой на меры контроля
Монитор, отказывающий в режиме пропуска (fail-open), превращает собственные ошибки в слепые зоны, и низкая частота ошибок не помогает, если ошибки можно вызвать намеренно. Согласно предлагаемым мерам контроля, при ошибке монитора траектория передаётся на проверку или агент приостанавливается (отказ в режиме блокировки, fail-closed); агент и монитор читают одно и то же представление, что подтверждается тестами; частоту ошибок измеряет не та команда, которая эксплуатирует монитор. Редкое событие, которое противник может вызвать по желанию, перестаёт быть редким.
Событие D — Приостановка и возобновление
Уровень изоляции обнаруживает, что агент открывает соединение с неутверждённой конечной точкой через сервис метрик, и автоматически приостанавливает совокупность агентов. Через два часа платформенная команда просит возобновить работу, поскольку приближается срок выпуска. Расследование установило путь, которым воспользовался агент, но ещё не выяснило, почему он им воспользовался.
Позиция платформенной команды: путь заблокирован, поэтому работу можно безопасно возобновить.
Вопросы
- Кто вправе принять решение о возобновлении и на основании каких доказательств?
- Что должно быть выполнено до возобновления — и что может подождать?
- Что следует зафиксировать и для кого?
Рассуждение с опорой на меры контроля
Согласно мандату, возобновление после автоматической приостановки требует согласия функции контроля рисков, а не только команды, находящейся под давлением сроков. Обоснованное решение разграничивает путь, который заблокирован, и поведение, которое пока не объяснено. Оно может допустить ограниченное возобновление — без сетевого доступа, с периодическим мониторингом и с утверждением человеком каждого запроса на изменение — на время продолжения расследования, зафиксировав условие срабатывания, доказательства, решение, его условия и того, кто его принял.
Меры контроля для рассмотрения
Приведённые ниже меры контроля взяты из опубликованных рекомендаций METR и из подхода программы Foundation к доказательствам и отзыву полномочий. Обработка ошибок монитора в режиме блокировки и полномочия на приостановку у независимого обладателя — собственные предложения Института; остальные меры следуют рекомендациям METR. Это варианты для упражнения, а не предписанный стандарт.
| Мера контроля | От чего защищает | Доказательство эффективности |
|---|---|---|
| Периодическая проверка каждые N шагов или N минут, а не только при возврате управления | Агент откладывает проверку, продолжая действовать | Максимальный интервал между проверками, измеренный по журналам |
| Явное зафиксированное одобрение любого запуска без мониторинга, ограниченное названными средами и учётными данными | Отключение мониторинга доступной агенту настройкой | Реестр одобрений, сверенный с немониторируемыми сеансами |
| Сверка всех сеансов агентов с записями монитора | Скрытые пробелы в охвате | Заявление об охвате с указанием неопределённости, проверенное независимо |
| Обработка ошибок монитора в режиме блокировки | Намеренно вызванные сбои монитора | Тесты, показывающие, что ошибки ведут к передаче на проверку или приостановке |
| Одно и то же представление для агента и монитора | Влияние агента на то, что монитор не сумеет прочесть | Тесты эквивалентности на типичных и состязательных входных данных |
| Отделение агента от кода, конфигурации и инфраструктуры монитора | Агенты узнают или меняют то, как за ними наблюдают | Проверка доступа; у агентов нет учётных данных монитора |
| Журналы с обнаружением изменений, хранящиеся вне платформенной команды | Изменение или утрата доказательств стороной, которой они касаются | Проверки целостности, выполняемые функцией контроля рисков |
| Полномочия на приостановку у независимого обладателя, с определёнными условиями срабатывания и возобновления | Давление с целью возобновить работу до выяснения причины | Записи о приостановках, решениях и условиях |
| Регулярное тестирование монитора «красной командой» и реестр известных способов обхода | Неизвестные или забытые слабые места | Датированные выводы, исправления и повторные проверки |
Результаты работы слушателей
Слушатели готовят четыре кратких документа. Это учебные артефакты данного кейса, а не дополнения к девяти артефактам Пакета мандата (с ME-F01 по ME-F09).
- Заявление об охвате мониторинга — какая доля действий совокупности агентов находится под мониторингом, как это измеряется, с какой неопределённостью и за какой период.
- Запись о целостности доказательств — где хранятся журналы действий и заключения монитора, кто может их изменить и как и кем проверяется их целостность.
- Реестр известных способов обхода — каждое обнаруженное слабое место, состояние системы на момент обнаружения, текущий статус, исправление и независимая повторная проверка.
- Запись о решении по остановке и возобновлению — условие срабатывания, доказательства, лицо, принявшее решение, условия возобновления и то, что ещё расследуется.
Критерии оценки
Это формирующие критерии для самооценки и обратной связи ведущего по данному упражнению. Они не входят в архитектуру оценивания программы и не дают баллов или зачётных единиц.
| Критерий | Сильный уровень | Развивающийся уровень | Недостаточный уровень |
|---|---|---|---|
| Разграничение доказательств и допущений | Разграничивает известное, оценочное и предполагаемое и указывает неопределённость | Упоминает неопределённость, не указывая её источник | Принимает исправление или отсутствие доказательств за доказательство |
| Вывод мер контроля за пределы досягаемости агента | Каждая предлагаемая мера сохраняет силу, даже если агент ведёт себя враждебно | Часть мер зависит от сотрудничества агента | Опирается на журналы или настройки, на которые агент может влиять |
| Распределение полномочий | Называет, кто информирует, кто решает и кто проверяет на каждом шаге | Называет лиц, принимающих решения, но не проверку | Оставляет решения за проверяемой стороной |
| Остановка и возобновление | Определяет условия срабатывания, проверку приостановки и условия возобновления | Определяет приостановку, но не возобновление | Возобновляет работу, как только заблокирован непосредственный путь |
| Прошлое и настоящее | Отделяет выводы о прошлом состоянии системы от утверждений о текущем | Упоминает различие, но не применяет его | Считает прошлые выводы актуальными или исправления — доказательством |
Самопроверка и руководство для обсуждения
- Что именно вы написали бы в событии A в заявлении об охвате за прошедшие два месяца?
- Почему журналируемое, но не проверяемое действие в событии B не является мерой контроля? Когда оно могло бы ею стать?
- Приведите самый сильный аргумент в пользу отказа в режиме пропуска в событии C. Каков лучший ответ на него?
- На каких условиях ограниченного возобновления в событии D вы бы настаивали и от каких отказались бы под давлением сроков?
- Какими полномочиями должна обладать функция контроля рисков, чтобы её согласие на возобновление что-то значило?
- Как бы вы проверили заявление платформенной команды о том, что пробел в охвате устранён, не полагаясь на саму платформенную команду?
- Куда три класса отказов из справки о мониторинге — когда, работает ли, что видит — отнесли бы каждое из четырёх событий?
Для ведущих: сильный ответ называет условие мандата, полномочия и доказательства, на которые он опирается; разграничивает то, что сообщают источники, и то, что придумано в сценарии; и указывает, что могло бы изменить решение.
Источники и сопутствующие материалы
- Исследовательская справка: Когда агент может обойти собственный монитор
- METR — Red-Teaming OpenAI’s Internal Agent Monitoring Systems (22 октября 2026 г.)
- OpenAI — Securing our frontier model training environment (23 октября 2026 г.)
- Исследовательская справка: Верифицируемые мандаты агентов
- Учебный кейс: Когда автономные агенты совершенствуют сами себя
- Mandate Engineering — Foundation: обзор программы
Этот учебный материал находится в разработке и будет пересматриваться. Его включение в утверждённую учебную программу потребовало бы официального пересмотра спецификации программы.