Как OpenAI безопасно запускает Codex: песочницы, approval-политики, сетевые ограничения и аудит действий агента

Зачем вообще нужен отдельный контур безопасности для Codex

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

Именно поэтому вопрос уже не в том, “умеет ли Codex писать код”, а в том, как ограничить его поведение внутри реальной рабочей среды. В статье OpenAI формулирует три практических цели: держать агента внутри понятных технических границ, не тормозить разработчиков на низкорисковых действиях и делать более опасные действия явно видимыми и проверяемыми. Для этого компания строит защитный контур из управляемых конфигов, ограниченного исполнения, сетевых политик и агентно-ориентированных логов.

Базовый принцип: продуктивность внутри ограниченной среды

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

Sandbox и approval-политики

В статье OpenAI отдельно объясняет, что sandboxing и approvals работают вместе. Песочница задаёт техническую границу исполнения: куда Codex может писать, есть ли у него доступ в сеть, какие пути защищены. Approval policy отвечает за другой слой — когда агент обязан попросить разрешение на действие, например если оно выходит за границы песочницы. Пользователь может подтвердить действие один раз или разрешить подобный тип действий на всю текущую сессию.

Для типовых approval-запросов OpenAI использует Auto-review mode. Когда режим включён, Codex отправляет планируемое действие и недавний контекст отдельному auto-approval subagent. Этот подпроцесс может автоматически одобрять низкорисковые действия, чтобы не прерывать пользователя на каждом рутинном шаге. При этом более рискованные действия или действия с потенциально нежелательными последствиями всё равно должны останавливаться и не проходить бесконтрольно.

# config.toml

# Включить auto_review
approvals_reviewer = "auto_review"

# Автоматически добавить известные директории разработки в песочницу
sandbox_workspace_write.writable_roots = ["~/development"]

# requirements.toml

# Требовать, чтобы Codex работал только внутри песочницы
allowed_sandbox_modes = ["read-only", "workspace-write"]

Этот фрагмент важен тем, что он показывает не абстрактную идею sandboxing, а конкретную административную настройку: какие режимы вообще разрешены и какие каталоги агент может использовать как рабочее пространство.

Сетевой доступ: у Codex нет “открытого интернета”

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

# requirements.toml

# Разрешить web fetch только из кэша OpenAI
allowed_web_search_modes = ["cached"]

[experimental_network]

# Включить сетевой прокси
enabled = true

# Разрешить Codex взаимодействовать с localhost
allow_local_binding = true

# Полностью блокировать запросы к этому домену
denied_domains = ["pastebin.com"]

# Автоматически разрешать запросы к этим доменам
allowed_domains = ["login.microsoftonline.com", "*.openai.com"]

Здесь хорошо видно, как OpenAI выстраивает белый и чёрный список прямо на уровне управляемой конфигурации. Особенно показательно, что web search ограничивается только cached-режимом, а сетевой прокси управляется отдельно через секцию experimental_network.

Идентификация и учётные данные

Отдельный блок статьи посвящён тому, как Codex аутентифицируется. OpenAI пишет, что OAuth-учётные данные CLI и MCP хранятся в защищённом системном keyring, логин принудительно идёт через ChatGPT, а доступ привязывается к конкретному ChatGPT enterprise workspace. Это позволяет удерживать использование Codex в рамках workspace-контролей и делает активность агента доступной в платформе Compliance Logs для enterprise workspace.

# config.toml

# Хранить CLI-учётные данные в OS Keychain
cli_auth_credentials_store = "keyring"

# Хранить MCP-учётные данные в OS Keychain
mcp_oauth_credentials_store = "keyring"

# Требовать авторизацию через ChatGPT
forced_login_method = "chatgpt"

# Требовать авторизацию в конкретном ChatGPT workspace
forced_chatgpt_workspace_id = "<workspace-uuid>"

Здесь важен не только сам факт хранения секретов в keyring, но и принудительная привязка к конкретному workspace. Это уже не локальная настройка “для удобства”, а элемент корпоративного контура контроля доступа.

Правила на команды: не каждая shell-команда равна другой

OpenAI отдельно пишет, что не рассматривает все shell-команды как одинаково безопасные. Обычные безвредные команды из повседневной инженерной практики можно разрешать без approval даже за пределами sandbox, а для опасных команд можно либо требовать отдельное подтверждение, либо полностью их блокировать. Это даёт Codex возможность быстро проходить типовые инженерные шаги, не заставляя человека подтверждать всё подряд.

# default.rules

prefix_rule(
    pattern = ["gh", "pr", ["view", "list"]],
    decision = "allow",
    justification = "Разрешает read-only просмотр GitHub PR через gh CLI.",
)

prefix_rule(
    pattern = ["kubectl", ["get", "describe", "logs"]],
    decision = "allow",
    justification = "Разрешает просмотр ресурсов Kubernetes для отладки.",
)

Этот кусок особенно полезен для практики, потому что показывает реальный стиль allow-правил: шаблон команды, решение и явное объяснение, зачем правило вообще разрешено. Здесь важна именно логика: разрешать чтение и диагностику, но не давать автоматически опасные команды записи или изменения состояния.

Управляемые конфиги как способ задать единый baseline

OpenAI пишет, что применяет всю эту защитную модель через комбинацию cloud-managed requirements, macOS managed preferences и локальных requirements-файлов. При этом requirements — это административно навязанные ограничения, которые пользователь не может переопределить. Такой подход позволяет удерживать единый baseline и при этом тестировать разные конфигурации по командам, группам пользователей и окружениям. В статье отдельно подчёркивается, что эти настройки действуют на всех локальных поверхностях Codex: в desktop app, CLI и IDE extension.

Почему простых security-логов уже недостаточно

Во второй половине статьи OpenAI переходит к теме наблюдаемости и аудита. Компания пишет, что традиционные security-логи всё ещё полезны, но обычно они отвечают только на вопрос “что произошло”: процесс запустился, файл изменился, сетевое соединение попытались установить. Этого недостаточно, если нужно понять, зачем Codex что-то сделал и какой у пользователя был исходный intent.

Именно поэтому OpenAI делает акцент на agent-native telemetry. Codex поддерживает экспорт логов через OpenTelemetry для разных типов событий: пользовательские промпты, approval-решения, результаты вызова инструментов, использование MCP-серверов, allow/deny события сетевого прокси. Кроме того, логи активности Codex доступны через OpenAI Compliance Platform для Enterprise и Edu клиентов.

# config.toml

[otel]
log_user_prompt = true
environment = "prod"

[otel.exporter.otlp-http]
endpoint = "http://localhost:14318/v1/logs"
protocol = "binary"

Здесь OpenAI показывает, как агентная телеметрия превращается в нормальный наблюдаемый сигнал, который можно централизовать в SIEM или системах compliance-логирования.

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

В статье OpenAI отдельно пишет, что использует логи Codex вместе со своим AI-powered security triage agent. Когда endpoint-защита сообщает, что Codex сделал что-то необычное, стандартный security tool показывает сам suspicious event. Но именно логи Codex помогают восстановить контекст: исходный пользовательский запрос, использование инструментов, approval-решения, результаты действий и сетевые policy-события.

После этого AI security triage agent формирует анализ для команды безопасности, чтобы отделить ожидаемое поведение агента от безобидной ошибки или действительно эскалируемой активности. Параллельно те же логи используются и для операционной настройки rollout: какие MCP-серверы реально используются, как часто sandbox блокирует действия, где сеть слишком часто останавливает агента и какие участки конфигурации ещё требуют тюнинга.

Что в этой статье действительно важно

Главная ценность публикации не в том, что OpenAI снова заявляет “мы думаем о безопасности”, а в том, что она показывает конкретный операционный стек: sandbox, approval subagent, allow/deny network policy, keyring для секретов, workspace pinning, rules на команды и OpenTelemetry для агентных действий. Это уже не декларация, а вполне прикладная модель того, как запускать coding-агента в корпоративной среде без полного хаоса.

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

Если coding-агенту реально дают доступ к репозиториям, shell-командам, сетевым вызовам и внутренним инструментам, то вопрос “насколько он умный” быстро становится вторичным. На первом месте уже контроль: где его остановить, что ему запретить и как потом понять, почему он вообще сделал конкретное действие.

Насколько, по-твоему, вообще возможно безопасно пустить такого агента в production-разработку без того, чтобы в итоге не задушить его же полезность?