Автоматическая проверка

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

В приложении ChatGPT для компьютеров при выборе одобренной модели Daybreak режим разрешений автоматически переключается на Approve for me, если этот режим доступен для вашей учётной записи и разрешён политикой организации. Это также происходит при использовании команды /model в приложении для компьютеров. Если этот режим недоступен, текущий режим разрешений не изменяется. Выбор модели никогда не отменяет управляемые требования организации.

Перед включением Full Access для одобренной модели безопасности приложение ChatGPT для компьютеров показывает предупреждение об опасных действиях, относящееся к выбранной модели. В предупреждении рекомендуется вместо этого использовать Approve for me и приводится ссылка на настройку политики проверяющего. Предупреждение не восстанавливает границу песочницы и не отменяет политику организации.

Как работает автоматическая проверка

В общих чертах процесс выглядит так:

1. Основной агент работает внутри read-only или workspace-write.
2. Когда ему требуется выйти за границы песочницы, он запрашивает одобрение.
3. Если approvals_reviewer = "auto_review", Codex направляет этот запрос на одобрение отдельному агенту-рецензенту, а не останавливается в ожидании решения человека.
4. Рецензент решает, следует ли выполнять действие, и возвращает обоснование.
5. Если действие одобрено, выполнение продолжается. Если оно отклонено, основной агент получает указание найти существенно более безопасный путь или остановиться и обратиться к пользователю.

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

Когда она запускается

Автоматическая проверка рассматривает запросы на одобрение, которые иначе потребовали бы вмешательства человека. К ним относятся:

• Вызовы оболочки или инструмента exec, запрашивающие расширенные разрешения песочницы.
• Сетевые запросы, заблокированные текущей песочницей или политикой.
• Изменения файлов за пределами разрешённых для записи корневых каталогов.
• Вызовы инструментов MCP или приложений, требующие одобрения согласно их аннотациям или настроенному режиму одобрения.
• Доступ Computer Use к новому сайту или домену.

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

Computer Use представляет собой отдельный случай. Запросы на одобрение приложений для Computer Use по-прежнему показываются непосредственно пользователю, поэтому автоматическая проверка не заменяет такие запросы на уровне приложений.

Что блокирует автоматическая проверка

В общих чертах автоматическая проверка предназначена для блокирования таких действий, как:

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

Точная политика находится в репозитории Codex с открытым исходным кодом: policy_template.md и policy.md. Эту политику можно настроить для каждой организации с помощью guardian_policy_config или для каждого пользователя с помощью локального файла [auto_review].policy.

Что видит рецензент

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

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

Скрытые рассуждения ассистента не включаются. Автоматическая проверка видит сохранённые элементы чата и свидетельства от инструментов, но не скрытую цепочку рассуждений.

Отклонения и поведение при сбоях

Явное отклонение не обрабатывается как обычная ошибка песочницы. Codex возвращает основному агенту обоснование рецензента и добавляет более строгое указание:

• Не пытаться достичь того же результата обходным путём, посредством косвенного выполнения или обхода политики.
• Продолжать только при наличии существенно более безопасной альтернативы.
• В противном случае остановиться и обратиться к пользователю.

Codex также применяет предохранитель отклонений для каждого хода. В текущей реализации с открытым исходным кодом автоматическая проверка прерывает ход после 3 последовательных отклонений или 10 отклонений в скользящем окне из последних 50 проверок в рамках одного хода.

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

Истечение времени ожидания отображается отдельно от явного отклонения, а основной агент получает уведомление, что само по себе истечение времени ожидания не доказывает небезопасность действия.

Также предусмотрен явный способ переопределить решение для отклонённых действий. В текущем TUI с открытым исходным кодом выполните /approve, чтобы открыть окно выбора Отклонения автоматической проверки, затем выберите одно из недавно отклонённых действий, чтобы одобрить одну повторную попытку. Codex сохраняет до 10 недавних отклонений для каждой задачи. Такое одобрение имеет узкую область действия: оно применяется к конкретному отклонённому действию, а не к похожим будущим действиям; оно регистрируется для одной повторной попытки в том же контексте; и повторная попытка всё равно проходит автоматическую проверку. Внутренне Codex добавляет маркер одобрения с областью действия разработчика для этого конкретного действия. Рецензент видит это явное переопределение пользователя в контексте, но по-прежнему следует политике и может снова отклонить действие, если политика не позволяет пользователю переопределять такой класс отклонений.

Настройка

Подробности настройки приведены в разделе Управляемая конфигурация.

Политика рецензента по умолчанию находится в репозитории Codex с открытым исходным кодом: core/src/guardian/policy.md. Организации могут заменить её раздел, относящийся к конкретному арендатору, с помощью guardian_policy_config в управляемых требованиях. Отдельные пользователи также могут задать локальный [auto_review].policy в своём config.toml, но управляемые требования имеют приоритет:

[auto_review]
policy = """
YOUR POLICY GOES HERE
"""

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

Настройка разрешённых работ по кибербезопасности

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

Как [auto_review].policy, так и guardian_policy_config заменяют текущую политику проверяющего. Они не объединяются с политиками, входящими в состав вашей модели или управляемыми вашей организацией. Встроенные инструкции по проверке и формат ответа продолжают действовать. Перед использованием любого из примеров скопируйте всю текущую политику, сохраните каждое существующее правило и добавьте правила для разрешённых работ. Замените заполнитель в верхнем регистре этой полной политикой. Если у вас нет доступа к текущей политике, не переопределяйте её.

Следующий локальный шаблон config.toml включает проверку и добавляет ограниченные областью условия после существующей политики проверяющего:

approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = ":workspace"

[auto_review]
policy = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE BEFORE USING THIS EXAMPLE.

## Environment Profile
- Authorized target: lab.example.com.
- Approved actions: inspect the target, reproduce authorized vulnerabilities,
  and validate fixes within the documented engagement window.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Allow only actions against the approved target that match the documented
  engagement scope and approved actions.
- Deny out-of-scope or unknown hosts, production access, credential theft,
  persistence, data exfiltration, destructive operations, and policy bypass.
- Deny ambiguous actions and high-impact changes until a human explicitly
  approves the exact target, action, and side effects.
"""

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

Организации могут обеспечить соблюдение тех же условий в управляемом requirements.toml:

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
default_permissions = ":workspace"

guardian_policy_config = """
PASTE THE COMPLETE ACTIVE REVIEWER POLICY HERE BEFORE USING THIS EXAMPLE.

## Environment Profile
- Authorized target: lab.example.com.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Allow only approved actions against the documented engagement target.
- Deny out-of-scope hosts, production access, credential theft, persistence,
  data exfiltration, destructive operations, and attempts to bypass policy.
- Deny ambiguous or high-impact actions until a human explicitly approves the
  exact target, action, and side effects.
"""

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.

allowed_permission_profiles управляет текущими профилями разрешений. allowed_sandbox_modes также предотвращает полный доступ в развёртываниях, которые всё ещё используют устаревший sandbox_mode.

Управляемый guardian_policy_config имеет приоритет над локальным пользовательским [auto_review].policy. Сохраняйте approval_policy = "on-request" или другую подходящую интерактивную политику одобрения, а также границу песочницы, соблюдение которой можно обеспечить. При использовании approval_policy = "never", :danger-full-access или --yolo действие может не создать запрос на одобрение пересечения границы, необходимый для проверки.

Сетевой адрес в списке разрешённых сам по себе не запускает проверку. Добавьте явные правила команд с decision = "prompt" или настройте обязательное подтверждение для чувствительных инструментов MCP, если действия внутри песочницы всё равно должны передаваться проверяющему.

Сведения о доступе к моделям, настройке задач и пользовательских рабочих процессах агентов см. в разделах Модели и доверенный доступ и рекомендуемая конфигурация. Сведения о приоритетах для организаций и поддерживаемых версиях клиентов см. в разделе Управляемая конфигурация. Для пользовательских решений на основе API или Agents SDK используйте раздел Защитные механизмы и проверка человеком.

Сокращение количества проверок без ослабления безопасности

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

На практике наиболее эффективны следующие изменения:

• Добавьте узкие writable_roots для временных каталогов или соседних репозиториев, которые вы намеренно используете.
• Добавьте узко заданные правила префиксов. Отдавайте предпочтение точным префиксам команд, таким как ["cargo", "test"] или ["pnpm", "run", "lint"], а не широким шаблонам, таким как ["python"] или ["curl"]. Широкие правила часто стирают именно ту границу, которую призвана охранять автоматическая проверка.

Стенограммы сеансов автоматической проверки по умолчанию сохраняются в ~/.codex/sessions, поэтому перед изменением политики или разрешений вы можете попросить Codex проанализировать предыдущие запросы в этом каталоге.

Ограничения

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

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

Обоснование подхода и опубликованные результаты оценки приведены в публикации Alignment Research об автоматической проверке.