Переход к основному контенту
OpenAI

Безопасное использование Codex в OpenAI

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

Загрузка…

По мере того как системы ИИ становятся все более мощными, они все чаще действуют от имени пользователей. Агенты для программирования могут автономно проверять репозитории, выполнять команды и взаимодействовать с инструментами разработки. Раньше такие задачи требовали непосредственного участия человека.

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

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

Управление работой Codex

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

Изолированная среда (песочница) и система одобрений

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

Для запросов, пересекающих границу песочницы, мы используем режим автоматической проверки(открывается в новом окне) — функцию, которая после включения автоматически одобряет определенные типы запросов, чтобы пользователям реже приходилось прерываться и подтверждать действия Codex. Codex отправляет запланированное действие и недавний контекст субагенту автоодобрения. Тот может автоматически одобрять низкорисковые действия (или высокорисковые при наличии достаточного уровня авторизации пользователя), не прерывая работу. Это позволяет Codex продолжать выполнение рутинных задач, приостанавливаясь лишь при обнаружении высокорисковых действий или операций, способных привести к непредвиденным последствиям.

TOML

1
# config.toml
2

3
# Turn on auto_review
4
approvals_reviewer = "auto_review"
5
# Add known development directories to the sandbox automatically
6
sandbox_workspace_write.writable_roots = ["~/development"]
7

8
# requirements.toml
9

10
# Require Codex to operate inside the sandbox
11
allowed_sandbox_modes = ["read-only", "workspace-write"]

Доступ к сети

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

TOML

1
# requirements.toml
2

3
# Ensure web fetch only comes from OpenAI's cache
4
allowed_web_search_modes = ["cached"]
5

6
[experimental_network]
7
# Turn on Network Proxy
8
enabled = true
9
# Allow Codex to interact with localhost
10
allow_local_binding = true
11
# Block all requests to this domain
12
denied_domains = ["pastebin.com"]
13
# Auto-allow requests to these domains
14
allowed_domains = ["login.microsoftonline.com", "*.openai.com"]

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

Мы также управляем тем, как Codex проходит аутентификацию. Учетные данные OAuth для CLI и MCP хранятся в защищенном системном хранилище ключей, вход принудительно выполняется через ChatGPT, а доступ привязывается к нашей корпоративной рабочей области ChatGPT. Это гарантирует, что использование Codex ограничено средствами контроля на уровне организации, а все действия агента фиксируются в платформе логов соответствия (Compliance Logs Platform) нашего рабочего пространства.

TOML

1
# config.toml
2

3
# Store CLI Auth Creds in OS Keychain
4
cli_auth_credentials_store = "keyring"
5
# Store MCP Creds in OS Keychain
6
mcp_oauth_credentials_store = "keyring"
7
# Require Auth via ChatGPT
8
forced_login_method = "chatgpt"
9
# Require Auth to Specific ChatGPT Workspace
10
forced_chatgpt_workspace_id = "<workspace-uuid>"

Правила

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

Starlark

1
# default.rules
2

3
prefix_rule(
4
pattern = ["gh", "pr", ["view", "list"]],
5
decision = "allow",
6
justification = "Allows read-only GitHub PR inspection via gh CLI.",
7
)
8
prefix_rule(
9
pattern = ["kubectl", ["get", "describe", "logs"]],
10
decision = "allow",
11
justification = "Allows Kubernetes resource inspection for debugging.",
12
)

Управляемые конфигурации

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

Нативная телеметрия и журналы аудита

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

Codex может предоставить командам безопасности более глубокое понимание работы агентов. Codex поддерживает экспорт логов в формате OpenTelemetry для различных событий, таких как промпты пользователей, решения об одобрении инструментов, результаты выполнения инструментов, использование серверов MCP, а также события разрешения или запрета доступа сетевым прокси. Журналы активности Codex также доступны через платформу соответствия (Compliance Platform) OpenAI для клиентов планов Enterprise и Edu.

TOML

1
# config.toml
2

3
[otel]
4
log_user_prompt = true
5
environment = "prod"
6

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

В OpenAI мы используем логи Codex совместно с нашим ИИ-агентом для приоритизации угроз (security triage agent). Когда оповещение на конечном устройстве сообщает о необычном действии Codex, инструмент безопасности эндпоинта сигнализирует нам о подозрительном событии. В этот момент логи Codex помогают восстановить контекст: намерения пользователя и логику самого агента. Наш ИИ-агент для анализа угроз использует эти логи, чтобы изучить исходный запрос, активность инструментов, принятые решения об одобрении, результаты работы и любые соответствующие решения сетевой политики или факты блокировки. Затем агент представляет результаты анализа нашей команде безопасности для проверки, позволяя отличить ожидаемое поведение агента и безобидные ошибки от активности, которая действительно требует эскалации.

Мы также используем ту же телеметрию в операционных целях. Эти логи помогают нам понять, как меняется уровень внедрения внутри компании, какие инструменты и серверы MCP используются чаще всего, как часто сетевая «песочница» блокирует запросы или запрашивает подтверждение, и в каких аспектах процесс развертывания все еще требует тонкой настройки. Эти логи в формате OpenTelemetry могут быть централизованы в системах SIEM и платформах логов соответствия.

Планы на будущее

По мере того как агенты для программирования, такие как Codex, интегрируются в процессы разработки, командам безопасности нужны инструменты, специально предназначенные для управления этим переходом. Codex предоставляет интерфейсы управления, средства конфигурирования, механизмы изоляции (песочницы) и детализированную нативную телеметрию, которые необходимы для обеспечения безопасного внедрения. Имея эти возможности, команды безопасности могут внедрять Codex с большей уверенностью, сочетая продуктивность разработчиков с видимостью и контролем, необходимыми для корпоративной безопасности. Подробнее о настройке Codex можно узнать здесь(открывается в новом окне), а о Compliance API — здесь(открывается в новом окне).

Автор

OpenAI