Безопасный Codex: как OpenAI защищает AI-агента

Codex в продакшене: как OpenAI держит агента под контролем

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

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

В OpenAI Codex разворачивают с несколькими чёткими целями: держать агента внутри ясных технических границ, позволять разработчикам быстро работать с низкорисковыми действиями и делать высокорисковые действия явными. Также сохраняется агент-нативная телеметрия (agent-native telemetry) — журналирование, характерное для агентной архитектуры, — чтобы понимать и проверять, что именно делал агент. На практике это означает: управляемая конфигурация, ограниченное выполнение, сетевые политики и агент-нативные логи.

Два уровня защиты: Sandbox и Approval Policy

Согласования (approvals) и «песочница» (sandbox) работают вместе. Sandbox определяет техническую границу выполнения: куда Codex может писать, может ли он выходить в сеть и какие пути остаются защищёнными. Политика согласований (approval policy) определяет, когда Codex должен спросить разрешения перед выполнением действия — например, когда нужно выйти за пределы sandbox.

Локально Codex использует sandbox, принудительно реализованный на уровне ОС, который ограничивает то, к чему он может обращаться (как правило, текущим рабочим пространством), плюс политику согласований, контролирующую, когда он должен остановиться и спросить перед действием.

graph TD
    A[Запрос Codex] --> B{Действие внутри sandbox?}
    B -- Да --> C[Выполняется автоматически]
    B -- Нет --> D{Уровень риска}
    D -- Низкий/Средний --> E[Автоматический ревьюер]
    D -- Высокий --> F[Запрос одобрения у пользователя]
    D -- Критический --> G[Действие заблокировано]
    E --> H{Решение ревьюера}
    H -- Разрешено --> C
    H -- Отклонено --> G
    F --> I{Ответ пользователя}
    I -- Одобрено --> C
    I -- Отклонено --> G

Режимы sandbox

Codex использует механизмы, нативные для каждой операционной системы. Реализация различается между macOS, Linux, WSL2 и нативным Windows, но принцип единый: дать агенту ограниченное пространство для работы, чтобы рутинные задачи выполнялись автономно в пределах чётко заданных границ.

Режим danger-full-access запускает Codex без ограничений sandbox — убираются границы файловой системы и сети. Его следует использовать только тогда, когда вы хотите предоставить Codex полный доступ.

Политика согласований и автоматический ревьюер

Установив approvals_reviewer = "auto_review", вы направляете подходящие запросы на согласование через агента-ревьюера, прежде чем Codex выполнит запрос. Ревьюер оценивает только те действия, которые уже требуют согласования: выход за пределы sandbox, сетевые запросы, запросы request_permissions или side-effecting вызовы MCP-инструментов.

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

# Пример config.toml для строгого режима
approval_policy = "on-request"
approvals_reviewer = "auto_review"
sandbox_mode = "workspace-write"
allow_login_shell = false

Сетевые политики: гибкость без риска

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

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

Для тех, кому нужен ограниченный доступ к сети (например, для загрузки зависимостей), можно настроить список разрешённых доменов:

[permissions.workspace.network]
enabled = true
mode = "limited"

[permissions.workspace.network.domains]
"api.openai.com" = "allow"
"pypi.org" = "allow"
"registry.npmjs.org" = "allow"

Codex Cloud работает в изолированных контейнерах, управляемых OpenAI, предотвращая доступ к хост-системе или посторонним данным. Используется двухфазная модель: фаза настройки запускается до фазы агента и может обращаться к сети для установки зависимостей, затем фаза агента по умолчанию работает офлайн. Секреты, настроенные для облачных сред, доступны только во время настройки и удаляются до начала фазы агента.

Управление правилами команд: не все shell-команды одинаково безопасны

В OpenAI используют правила, чтобы Codex не считал каждую команду одинаково безопасной. Стандартные безобидные команды, применяемые инженерами в ежедневной разработке, разрешены без согласования вне sandbox, а конкретные опасные команды могут быть заблокированы или потребовать одобрения.

Требования (requirements) — это принудительно применяемые администратором элементы управления, которые пользователи не могут переопределить. Управляемые настройки macOS и локальные файлы требований позволяют поддерживать единый базовый уровень конфигурации, при этом сохраняя возможность тестировать разные конфигурации для команд, групп пользователей или окружений. Эти конфигурации применяются ко всем локальным поверхностям Codex: десктопному приложению, CLI и расширению IDE.

Аутентификация и соответствие требованиям (Compliance)

CLI и OAuth-учётные данные MCP (Model Context Protocol — протокол взаимодействия модели с внешними инструментами) хранятся в защищённом хранилище ключей ОС (OS keyring), вход принудительно осуществляется через ChatGPT, а доступ привязан к корпоративному рабочему пространству ChatGPT. Это обеспечивает привязку использования Codex к элементам управления на уровне рабочего пространства и делает активность Codex доступной в ChatGPT Compliance Logs Platform для корпоративного рабочего пространства.

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

Агент-нативная телеметрия: понять «почему», а не только «что»

Контроль — это только половина работы. После развёртывания агентов командам безопасности нужна видимость того, что эти агенты делают и зачем. Традиционные журналы безопасности полезны при просмотре действий Codex, но они в основном отвечают на вопрос «что произошло»: процесс запущен, файл изменён, попытка сетевого соединения. Специалисты по защите всё равно должны выяснять «почему» Codex что-то сделал или что именно намеревался сделать пользователь.

Codex поддерживает экспорт логов через OpenTelemetry (OTel — открытый стандарт телеметрии) для различных событий: пользовательских запросов, решений о согласовании инструментов, результатов выполнения инструментов, использования MCP-серверов и решений сетевого прокси.

Как OpenAI использует эти логи

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

Ту же телеметрию используют и операционно: для понимания того, как меняется внутреннее внедрение, какие инструменты и MCP-серверы используются, как часто сетевой sandbox блокирует или выдаёт запросы, и где развёртывание ещё требует настройки.

[otel]
environment = "production"
exporter = { otlp-http = { endpoint = "https://otel.yourcompany.com/v1/logs" } }
log_user_prompt = false  # редактировать запросы пользователей по умолчанию

Кибербезопасность модели: GPT-5.3-Codex и Preparedness Framework

GPT-5.3-Codex — первая модель, которую OpenAI рассматривает как обладающую «высокими возможностями в кибербезопасности» согласно Preparedness Framework (системе оценки рисков). Это требует дополнительных мер защиты, включая обучение модели отказывать в явно вредоносных запросах, таких как кража учётных данных.

В дополнение к защитному обучению автоматизированные классификаторы обнаруживают сигналы подозрительной киберактивности и направляют высокорисковый трафик к менее «киберспособной» модели (GPT-5.2).

Итог: безопасность без потери производительности

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

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