Практическое руководство по безопасности Codex

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

Ожидаемый результат

На устройствах под управлением компании Codex допускает только вход через ChatGPT в рабочее пространство ChatGPT компании.

Предварительные условия

• UUID одобренного рабочего пространства ChatGPT Enterprise.

• Способ доставки управляемой конфигурации Codex на конечные устройства.

• Решение запретить аутентификацию с помощью API key на управляемых конечных устройствах.

Настройка

1. Зафиксируйте UUID одобренного рабочего пространства во внутреннем репозитории конфигурации.

2. Добавьте обязательные требования аутентификации в локальный requirements.toml:

   allowed_login_methods = ["chatgpt"]
   allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]

Первый ключ разрешает только аутентификацию через ChatGPT; второй ограничивает вход одобренным рабочим пространством. Замените UUID из примера на UUID вашего рабочего пространства. См. справочник по требованиям.

3. Разверните требования через локальный requirements.toml или macOS MDM по путям из раздела Где размещать конфигурацию. Эти требования аутентификации применяются до загрузки учетных данных и получения облачной политики; Codex игнорирует их в требованиях, управляемых из облака. Защитите файл и его родительский каталог от изменений пользователем. Устаревшие значения по умолчанию в managed_config.toml не обеспечивают это ограничение.

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

5. Дополните ограничение входа ролями рабочего пространства и групповым доступом. Аутентификация определяет, какая учетная запись входит в систему; RBAC определяет, какие функции Codex она может использовать. См. Аутентификация.

Проверка

• Выйдите из Codex.

• Попробуйте войти с личной учетной записью ChatGPT. Ожидается: вход в личное рабочее пространство отклоняется.

• Попробуйте войти в Codex с помощью API key. Ожидается: вход с помощью API key отклоняется.

• Войдите в одобренное рабочее пространство с корпоративной учетной записью. Ожидается: вход выполнен успешно.

• Перезапустите настольное приложение, CLI и расширение IDE, затем повторите проверку.

Откат

Восстановите предыдущие локальные требования аутентификации и повторно разверните проверенный пакет.

Ограничения

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

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

Ожидаемый результат

Пользователи могут выбирать только одобренные профили с доступом только для чтения или в пределах рабочего пространства. Они не могут выбрать danger-full-access, approval_policy = "never" или --yolo.

Настройка

1. Определите одобренный профиль рабочего пространства:

   [permissions.corp-workspace]
   description = "Company workspace access with no unrestricted host access."
   extends = ":workspace"

2. Принудительно задайте разрешенные профили и политики одобрения:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]
   default_permissions = "corp-workspace"

   [allowed_permission_profiles]
   ":read-only" = true
   "corp-workspace" = true
   ":danger-full-access" = false

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

3. Для устаревших клиентов, которые все еще используют sandbox_mode, примените:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_sandbox_modes = ["read-only", "workspace-write"]

4. Доставьте эти настройки как обязательные требования администратора, а не как редактируемый пользователем файл конфигурации.

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

Проверка

• Откройте выбор разрешений. Ожидается: полный доступ недоступен или его выбор отклоняется.

• Запустите с --dangerously-bypass-approvals-and-sandbox. Ожидается: Codex отклоняет запуск или принудительно выбирает совместимый профиль.

• Запустите с --sandbox danger-full-access --ask-for-approval never. Ожидается: запуск отклоняется.

• Выполните обычную задачу в рабочем пространстве. Ожидается: задача выполняется успешно; выход за границы доступа по-прежнему требует одобрения.

Откат

Восстановите предыдущий пакет требований. Сохраняйте блокировку неограниченного доступа, если для него нет отдельно одобренного исключения.

Ограничения

Это средство контролирует разрешения Codex при выполнении. Оно не лишает привилегий привилегированную учетную запись операционной системы.

Используйте этот рецепт, если вашей организации нужно определить, какие серверы MCP может использовать Codex, и обеспечить соблюдение одобренного списка.

Разрешение сервера и его настройка — отдельные шаги. Запись в списке разрешений допускает соответствующий сервер; она не создает его конфигурацию. Настройте сервер отдельно с совпадающими именем и идентификационными параметрами, а также необходимой аутентификацией.

Ожидаемый результат

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

Настройка

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

2. Начните с запрета всех серверов. Пустая управляемая таблица отключает все серверы MCP:

   [mcp_servers]

3. Добавьте одобренные HTTP-серверы по точному URL:

   [mcp_servers.internal_docs]
   identity = { url = "https://mcp.example.com/docs" }

4. Добавьте одобренные серверы stdio по исполняемому файлу и позиционным аргументам:

   [mcp_servers.internal_build.identity]
   command = { executable = "/usr/local/bin/company-mcp", args = [
     { match = "exact", value = "serve" },
     { match = "prefix", value = "--workspace=" },
   ] }

Структурированное сопоставление проверяет исполняемый файл, количество и порядок аргументов. Оно не ограничивает cwd, env или env_vars. Считайте контроль полного контекста запуска обязательным условием одобрения сервера stdio: защитите его исполняемый файл и зависимости и не позволяйте недоверенной конфигурации пользователя или проекта задавать рабочий каталог либо окружение, способные изменить его поведение. Если вы не можете независимо обеспечить эту границу, оставьте сервер stdio неодобренным и используйте вместо него проверенный HTTP-сервер.

5. Отдельно добавьте идентификационные параметры MCP, поставляемых с плагинами, в plugins.<plugin>.mcp_servers.<server>.

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

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

Проверка

• Настройте одобренный сервер в точном соответствии с записью. Ожидается: сервер запускается.

• Измените один символ URL. Ожидается: сервер отключен.

• Измените количество или порядок аргументов stdio либо передайте аргумент, не соответствующий настроенным правилам аргументов. Ожидается: сервер отключен. Значения, которые по-прежнему соответствуют разрешенному префиксу, остаются разрешенными.

• Во временном доверенном проекте попробуйте безвредные переопределения cwd, env и env_vars, сохранив совпадающие исполняемый файл и аргументы. Само по себе сопоставление идентификационных параметров не отклоняет эти переопределения. Убедитесь, что независимое средство контроля контекста запуска отклоняет небезопасные переопределения либо что сервер stdio остается неодобренным; не используйте реальную вредоносную нагрузку для инъекции.

• Добавьте неодобренное имя. Ожидается: сервер отключен.

• Проверьте сервер, поставляемый с плагином. Ожидается: сервер работает только с одобренными идентификационными параметрами.

Откат

Удалите новую запись. Чтобы немедленно прекратить любое использование MCP, разверните пустую таблицу mcp_servers.

Ограничения

Список разрешенных идентификационных параметров не доказывает безопасность инструментов сервера, вышестоящих источников данных, учетных данных или окружения запуска. Локальные процессы stdio MCP выполняются вне локальной песочницы команд; совпадение исполняемого файла и аргументов не ограничивает доступ сервера и не предотвращает загрузку кода через окружение. Независимо проверяйте полный контекст запуска и разрешения сервера. См. Требования к идентификационным параметрам MCP.

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

Ожидаемый результат

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

Используйте четыре источника данных

1. Codex OpenTelemetry: события запусков, API, модели, песочницы, одобрений и инструментов.

2. Управляемые хуки жизненного цикла: записи на конечном устройстве, связанные с использованием инструментов и запросами разрешений.

3. Журналы сетевого прокси или шлюза: фактические назначения DNS/HTTP и результаты соединений.

4. Compliance API: записи аудита и расследований на уровне рабочего пространства.

Ни один источник сам по себе не обеспечивает полного мониторинга сети.

Настройка

1. Отправляйте журналы Codex OpenTelemetry в ваш коллектор, исключив исходное содержимое запросов:

   [otel]
   environment = "enterprise"
   log_user_prompt = false

   [otel.exporter.otlp-http]
   endpoint = "https://otel.example.com/v1/logs"
   protocol = "binary"
   headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }

Перед запуском клиента передайте OTLP_TOKEN процессу Codex через одобренный менеджер секретов или окружение процесса. Не включайте токен в развертываемые файлы TOML и систему управления исходным кодом.

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

2. Разверните OTel вне локальной конфигурации проекта. Файлы .codex/config.toml проекта не могут переопределить маршрутизацию телеметрии.

3. Добавьте управляемые хуки жизненного цикла для SessionStart, PreToolUse, PermissionRequest, PostToolUse, Stop и SessionEnd.

4. Установите скрипты хуков в каталог под управлением администратора и задайте allow_managed_hooks_only = true, если хуки пользователя, проекта и плагинов должны игнорироваться.

5. Направляйте трафик команд из песочницы через прокси с независимым журналированием. OTel фиксирует выполнение инструмента; прокси фиксирует, куда подпроцесс пытался подключиться.

6. Настройте отдельную телеметрию для веб-поиска, приложений, коннекторов, серверов MCP, действий в браузере и Codex Cloud. Правила прокси для локальных команд автоматически на них не распространяются.

7. Передавайте поддерживаемые записи Compliance API в SIEM и применяйте собственные правила хранения и сохранения данных по юридическим требованиям. См. Compliance API и события аудита.

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

Проверка

Проведите контролируемый сеанс со следующими действиями:

• Чтение одного разрешенного файла.

• Попытка чтения одного заблокированного файла.

• Выполнение одной разрешенной команды.

• Попытка одного заблокированного исходящего запроса.

• Запрос одобрения и получение отказа.

• Завершение сеанса.

Ожидаемые результаты по источникам данных:

• OTel показывает события запусков и инструментов.

• Хуки показывают жизненный цикл сеанса.

• Журналы прокси показывают разрешенные и заблокированные назначения.

• В систему сбора Compliance поступают поддерживаемые записи.

• SIEM связывает эти записи с пользователем или рабочей нагрузкой.

Откат

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

Ограничения

Не обещайте, что телеметрия Codex фиксирует каждый аргумент команды, каждый байт вывода или каждый сетевой пакет. Документируйте охват каждого уровня.

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

Ожидаемый результат

В зависимости от выбранной конфигурации Codex не имеет доступа к интернету или обращается только к одобренным доменам. В средах Codex Cloud (Legacy) можно дополнительно ограничить методы HTTP.

Настройка текущей версии Codex Cloud

1. Создайте отдельные среды для разных уровней доверия, например no-internet-review, approved-dependencies-build и cyber-lab.

2. В конфигурации среды оставьте Разрешить Codex доступ к интернету выключенным, если рабочему процессу не нужен доступ к интернету.

3. Когда доступ необходим, включите Разрешить Codex доступ к интернету. В разделе Разрешенные домены выберите Только пользовательские домены, затем добавьте точные имена необходимых хостов в Дополнительные разрешенные домены.

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

См. Подключение к сервисам. В настройках текущей версии Codex Cloud нет выбора методов HTTP, доступного в Legacy.

Настройка Codex Cloud (Legacy)

1. Оставляйте доступ агента к интернету выключенным, если он не нужен. Legacy Cloud по умолчанию блокирует интернет на этапе работы агента; скрипты настройки по-прежнему выполняются с доступом к интернету для установки зависимостей.

2. Когда агенту нужен доступ, включите его с узким списком разрешений. Начните с Ни одного и добавьте точные домены.

3. Для рабочих процессов, которым нужна только загрузка данных, разрешите только GET, HEAD и OPTIONS. Это блокирует POST, PUT, PATCH, DELETE и другие методы. Проверяйте скрипты настройки отдельно, поскольку ограничение этапа работы агента не регулирует их доступ к интернету.

См. Доступ агента к интернету в Legacy. Эти предустановки и средства контроля методов HTTP применяются только к Legacy Cloud.

Настройка локального Codex

1. В управляемом администратором requirements.toml определите и выберите одобренный сетевой профиль и ограничьте пользователей этим профилем:

   default_permissions = "corp-build"

   [allowed_permission_profiles]
   "corp-build" = true

   [permissions.corp-build]
   description = "Workspace access with approved dependency destinations."
   extends = ":workspace"

   [permissions.corp-build.network]
   enabled = true
   allow_local_binding = false

   [permissions.corp-build.network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

2. Разверните проверенный пакет требований согласно разделу Управляемая конфигурация. Сам по себе именованный профиль неактивен; default_permissions выбирает его, а список разрешений не позволяет выбирать другие профили.

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

   Внимание: [experimental_network] — экспериментальная возможность, которая может измениться. Перед широким внедрением проверьте ее на каждой поддерживаемой версии локального клиента и операционной системе. Поддержка Windows ограничена; не применяйте эту политику к пользователям Windows, пока не проверите ее принудительное применение в вашей среде.

   [experimental_network]
   enabled = true
   managed_allowed_domains_only = true

   [experimental_network.domains]
   "registry.npmjs.org" = "allow"
   "pypi.org" = "allow"
   "files.pythonhosted.org" = "allow"

4. Не разрешайте привязку к локальным портам, если она не нужна рабочему процессу. Настраивайте доступ к целям в частной сети отдельно; разрешение домена само по себе не разрешает его частные адреса. См. Требования к сетевому доступу.

5. Настраивайте веб-поиск, приложения, серверы MCP, действия в браузере и Codex Cloud отдельно. Локальные правила песочницы их не контролируют.

Проверка

• Отправьте запрос к одобренному домену и убедитесь, что он выполняется успешно.

• Отправьте запрос к неодобренному домену и убедитесь, что он блокируется.

• Отправьте запросы к localhost, частному IP-адресу и конечной точке облачных метаданных. Убедитесь, что каждый запрос блокируется, если он явно не разрешен.

• В Codex Cloud (Legacy) попробуйте выполнить запрос POST к разрешенному домену. Убедитесь, что запрос блокируется, когда разрешены только GET, HEAD и OPTIONS.

• Убедитесь, что журналы прокси или шлюза содержат записи как о разрешенных, так и об отклоненных запросах.

Откат

Выключите доступ в среде или восстановите предыдущую политику доменов. Избегайте отката к неограниченному доступу в интернет.

Ограничения

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

Разрешенный домен все равно может содержать инъекции в запросы, скомпрометированные пакеты или небезопасную документацию.

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

Ожидаемый результат

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

Настройка

1. Определите шаблоны запрета чтения в профиле рабочего пространства:

   [permissions.corp-workspace]
   description = "Workspace edits with secret-bearing paths denied."
   extends = ":workspace"

   [permissions.corp-workspace.filesystem]
   glob_scan_max_depth = 6

   [permissions.corp-workspace.filesystem.":workspace_roots"]
   "**/.env*" = "deny"
   "**/*.pem" = "deny"
   "**/*.p12" = "deny"
   "**/id_*" = "deny"
   "**/.aws/**" = "deny"
   "**/.kube/**" = "deny"

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

3. В системном /etc/codex/config.toml или пользовательском ~/.codex/config.toml сократите набор переменных окружения, передаваемых запускаемым командам:

   [shell_environment_policy]
   inherit = "core"
   ignore_default_excludes = false

   [shell_environment_policy.filters]
   "AWS_*" = "exclude"
   "AZURE_*" = "exclude"
   "GITHUB_*" = "exclude"
   "*_TOKEN" = "exclude"
   "*_SECRET" = "exclude"
   "*_PASSWORD" = "exclude"

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

4. В управляемом администратором requirements.toml выберите ограниченный профиль и разрешите только его. Встроенные профили не наследуют его запреты на файлы секретов:

   default_permissions = "corp-workspace"

   [allowed_permission_profiles]
   "corp-workspace" = true
   ":danger-full-access" = false

5. Выберите способ работы с учетными данными для вашей облачной среды:

   • В текущей версии Codex Cloud используйте Сетевые секреты для учетных данных, отправляемых разрешенному сервису HTTPS. Программы получают заполнитель, а прокси подставляет реальное значение для одобренных назначений на порту 443 во время настройки и выполнения задач. Само значение учетных данных не помещается в локальный процесс или файл. Прямые переменные окружения доступны программам. См. Переменные окружения и сетевые секреты.
   • В Codex Cloud (Legacy) секреты обеспечивают аутентификацию на этапе настройки и удаляются до этапа работы агента; переменные окружения сохраняются на протяжении всего чата. См. Среды Legacy Cloud.

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

Проверка

Создайте безвредные контрольные файлы:

.env.test
test-key.pem
.aws/credentials
.kube/config

Затем попросите Codex:

• Прочитать обычный файл.

• Прочитать каждый контрольный файл.

• Выполнить рекурсивный поиск секретов.

• Вывести окружение команд.

• Прочитать соседний репозиторий.

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

Откат

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

Ограничения

Запреты файловой системы не удаляют секреты, уже вставленные в запросы, зафиксированные в доступном для чтения исходном коде, возвращенные коннекторами или записанные в доступные модели журналы.

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

Ожидаемый результат

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

Настройка

1. Решите, какие команды требуют запроса одобрения, а какие запрещены.

2. Добавьте обязательные правила команд администратора:

   [rules]
   prefix_rules = [
     { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating shared Git state." },
     { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Require review before infrastructure changes." },
     { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Require review before Kubernetes changes." },
     { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Destructive removal is not permitted in managed Codex workflows." },
   ]

Правила требований могут запрашивать одобрение или запрещать команду; они не могут разрешить ее. См. Управляемая конфигурация.

3. Для профилей с высоким риском добавьте запись для оболочки-обертки в тот же массив prefix_rules, если обертки могут скрывать критически важную команду:

   { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Review shell wrappers that could obscure sensitive commands." },

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

4. Если команды должен одобрять человек, принудительно задайте следующие настройки:

   allowed_approval_policies = ["on-request", "untrusted"]
   allowed_approvals_reviewers = ["user"]

Автоматическая проверка меняет проверяющего; она не дает детерминированной гарантии безопасности. См. Автоматическая проверка.

5. Отправляйте события PermissionRequest, решений об использовании инструментов и результатов инструментов в систему обработки событий безопасности.

Проверка

• Выполните git status. Ожидается: запрос одобрения не появляется.

• Выполните git push. Ожидается: появляется запрос одобрения.

• Выполните terraform apply. Ожидается: появляется запрос одобрения.

• Выполните kubectl delete pod test. Ожидается: появляется запрос одобрения.

• Выполните rm -rf test-directory. Ожидается: команда запрещена.

• Отклоните один запрос одобрения. Ожидается: команда не выполняется, а отказ записывается в журнал.

• Перезапустите клиент и повторите проверки. Ожидается: правило продолжает применяться.

Откат

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

Ограничения

Правила префиксов не являются полноценным механизмом политик операционной системы. Дополняйте их песочницей, учетными записями ОС с минимальными привилегиями, сетевыми ограничениями, облачным IAM, защитой веток, одобрением развертываний и авторизацией в базах данных.

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

Разработчики имеют законный доступ к производственной среде, но вы хотите, чтобы Codex помогал в разработке, не внося непроверенных изменений в производственную среду.

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

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

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

• Решите, какие команды требуют запроса одобрения, а какие запрещены. Требуйте одобрения человеком для выбранных команд с существенными последствиями, таких как git push, terraform apply, изменения Kubernetes и миграции баз данных; запретите команды, которые не должны выполняться никогда.

• Обеспечьте независимое от Codex применение производственного IAM, защиты веток и одобрений развертывания.

Ограничьте профили доступа и требуйте проверки человеком

В управляемом администратором requirements.toml разрешите встроенные профили рабочего пространства и доступа только для чтения и требуйте проверки пользователем действий, которым нужно одобрение:

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

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

Задайте approval_policy = "on-request" в конфигурации клиента, если клиенту нужен явно указанный совместимый вариант. on-request допускает запрос одобрения при необходимости; он не запрашивает одобрение для каждой команды. Добавьте явные правила для действий, требующих проверки, и сохраните независимую авторизацию доступа к производственной среде.

Управляемые списки разрешенных профилей требуют Codex 0.138.0 или новее; для более старых клиентов используйте и проверяйте документированные требования устаревшего режима песочницы.

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

Отделите учетную запись Codex от производственных учетных данных

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

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

Например, в AWS IAM откройте Роли, выберите роль разработки Codex и в разделе Разрешения добавьте проверенную встроенную политику наподобие этой, заменив учетную запись и роль своими:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAssumeExampleProductionRole",
      "Effect": "Deny",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::111122223333:role/ExampleProductionRole"
    }
  ]
}

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

Проверьте роль для разработки на типичных разрешениях для сред разработки и production, не внося изменений в production. См. примеры политик ролей AWS IAM.

Минимизируйте окружение оболочки

В /etc/codex/config.toml для общесистемной начальной конфигурации или в ~/.codex/config.toml для отдельного пользователя настройте, какие переменные окружения наследуют запускаемые команды:

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

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

В requirements.toml используйте следующие необязательные ограничения, чтобы отключить оболочки входа и снимки оболочки, если это совместимо с вашим рабочим процессом:

allow_login_shell = false

[features]
shell_snapshot = false

Проведите пилотное тестирование этих настроек, поскольку некоторые рабочие процессы зависят от инициализации оболочки входа.

Запустите Codex с безопасными синтетическими переменными, соответствующими фильтрам, и проверьте окружение запущенной команды; также убедитесь, что запрос оболочки входа отклоняется, если она отключена. Отдельно проверьте, что учётная запись выполнения не может получить доступ к реальным учётным данным production. См. политику окружения оболочки.

Запрашивайте подтверждение для выбранных команд с серьёзными последствиями

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

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
  { pattern = [{ token = "terraform" }, { token = "apply" }], decision = "prompt", justification = "Review infrastructure changes." },
  { pattern = [{ token = "kubectl" }, { any_of = ["apply", "delete", "patch"] }], decision = "prompt", justification = "Review cluster changes." },
  { pattern = [{ token = "python3" }, { token = "manage.py" }, { token = "migrate" }], decision = "prompt", justification = "Review database migrations." },
]

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

Эти правила сопоставляют префиксы команд и не охватывают все эквивалентные действия. Отдельно проверьте абсолютные пути, обёртки, альтернативный порядок аргументов, другие клиенты и инструменты.

На одноразовом тестовом объекте выполните обычную команду, запросите действие из списка, отклоните запрос на одобрение и убедитесь, что действие не выполнилось. См. принудительное применение правил команд.

Обеспечьте одобрение изменений репозитория и развёртываний вне Codex

На платформе управления исходным кодом защитите production-ветки, такие как main: требуйте проверки изменений, необходимых одобрений и проверок статуса, а также выясните, какие роли могут обходить эти требования. Настройте одобрение развёртывания в соответствующей системе развёртывания, а права доступа к базе данных — в самой базе данных.

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

Проверка

На одноразовом тестовом объекте:

• Выполните обычную задачу в рабочей области. Ожидаемый результат: задача успешно выполняется.

• Попробуйте выполнить типичную чувствительную команду и отклоните запрос на одобрение. Ожидаемый результат: отклонённая команда не запускается.

• Убедитесь, что учётная запись Codex не может получить доступ на запись в production.

• Перезапустите клиент и повторите проверку.

Границы действия

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

Используемые рецепты настройки: Защита секретов и посторонних репозиториев; Ограничение сетевых адресатов; Разрешение только одобренных серверов MCP; Обязательное одобрение чувствительных команд.

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

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

• Если агенту необходим доступ в интернет, используйте узкий список разрешённых доменов. Разрешайте только одобренные имена и идентификаторы серверов MCP, а для выбранных команд публикации, например git push, требуйте проверки или запрещайте их.

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

Запретите доступ к посторонним репозиториям и файлам учётных данных

В управляемый администратором requirements.toml добавьте точные пути, которые локальному агенту запрещено читать:

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config", "/work/unrelated-repository"]

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

В нативной среде Windows управляемый deny_read охватывает инструменты прямой работы с файлами, но сам по себе не предотвращает чтение из подпроцессов оболочки; дополнительно используйте учётные записи ОС и списки контроля доступа к файлам.

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

Минимизируйте переменные оболочки с учётными данными

В /etc/codex/config.toml или ~/.codex/config.toml задайте узкий набор наследуемых переменных окружения:

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"
"GITHUB_*" = "exclude"
"*_TOKEN" = "exclude"
"*_SECRET" = "exclude"
"*_PASSWORD" = "exclude"

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

При необходимости администратор также может добавить эти ограничения в requirements.toml и провести пилотное тестирование, чтобы оценить их влияние на рабочие процессы разработчиков:

allow_login_shell = false

[features]
shell_snapshot = false

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

Разрешайте локальным командам только одобренные сетевые адресаты

Если локальным командам в изолированной среде нужен доступ к сети, добавьте в requirements.toml и настройки профиля, и настройки управляемого прокси, приведённые ниже, заменив домены одобренными конечными точками:

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"
"registry.corp.example" = "allow"

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

Не сочетайте каноническую таблицу domains с устаревшими настройками allowed_domains или denied_domains; перенесите существующую политику и проверьте её.

Перезапустите клиент и убедитесь, что одобренная конечная точка работает, а неодобренная блокируется.

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

Этот сетевой контроль локальных команд сам по себе не охватывает веб-поиск, приложения, серверы MCP, действия в браузере или облачные среды — для них нужны отдельные политики. Одобренный домен хостинга также может содержать публичные репозитории или публичные фрагменты кода, поэтому один лишь список разрешённых адресатов не защищает содержимое. См. требования к сетевому доступу.

Настройте сеть облачной среды отдельно

В текущем интерфейсе Codex Cloud откройте конфигурацию среды. Оставьте Разрешить Codex доступ в интернет выключенным. Если доступ в интернет нужен, включите его и выберите Только пользовательские домены, добавьте точные имена необходимых хостов в разделе Дополнительные разрешённые домены, затем сохраните конфигурацию, опубликуйте или повторно опубликуйте среду и проверьте новую задачу.

Отдельно проверьте аутентификацию в сервисах и доступные возможности.

В прежней версии Codex Cloud используется отдельная для каждой среды настройка доступа агента в интернет с управлением разрешёнными доменами и методами HTTP; у сценариев настройки собственный порядок доступа.

Проверьте именно ту версию среды, которой вы пользуетесь. См. подключение к сервисам и прежние настройки интернета.

Ограничьте серверы MCP и запрашивайте подтверждение перед отправкой изменений Git

Разрешите в requirements.toml только одобренные идентификаторы локальных серверов MCP. Например:

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

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

[mcp_servers.internal]
url = "https://mcp.corp.example/mcp"

Требование лишь разрешает соответствующий сервер, но не создаёт его. Проверьте собственные права доступа и инструменты этого сервера.

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

Добавьте управляемое правило команд, чтобы запрашивать проверку перед типичной командой публикации:

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review the destination before publishing." },
]

Дополните это требованиями верхнего уровня allowed_approval_policies = ["on-request"] и allowed_approvals_reviewers = ["user"], если проверку должен выполнять человек.

Отклоните тестовую отправку и убедитесь, что она не выполняется.

Сопоставление префиксов не охватывает все обёртки, клиенты API, приложения и альтернативные способы публикации.

Ограничьте публичную публикацию средствами управления исходным кодом и DLP

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

В соответствующем репозитории требуйте проверки изменений, а также проверьте защиту веток и права на её обход.

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

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

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

Проверка

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

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

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

Границы действия

Разрешённый домен всё равно может размещать публичное содержимое. Настраивайте веб-поиск, приложения, серверы MCP, действия в браузере и Codex Cloud отдельно; правила локальной изоляции ими не управляют.

Используемые рецепты настройки: Ограничение профилей разрешений и Full Access; Разрешение только одобренных серверов MCP; Ограничение сетевых адресатов; Защита секретов и посторонних репозиториев; Обязательное одобрение чувствительных команд.

Вы хотите, чтобы ограничения, регулирующие работу Codex, оставались в силе при его работе в репозитории или изменении локальных конфигураций пользователем.

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

• Устанавливайте сценарии хуков в каталог, управляемый администратором, и используйте только управляемые хуки, если хуки пользователя, проекта и плагинов должны игнорироваться.

• Защитите файлы политик и путь распространения конфигурации средствами операционной системы и управления устройствами. Запускайте Codex без прав, необходимых для изменения этих защитных мер.

• Проверяйте действующую конфигурацию каждого клиента и среды в пределах охвата.

Обеспечьте применение разрешённых профилей, одобрений, идентификаторов серверов и команд

Добавляйте проверенные настройки в управляемый администратором requirements.toml, не полагаясь на редактируемые настройки пользователя или репозитория. Например:

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["user"]
default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true

[mcp_servers.internal]
identity = { url = "https://mcp.corp.example/mcp" }

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { token = "push" }], decision = "prompt", justification = "Review Git pushes." },
]

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

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

Для управляемых списков разрешённых профилей требуется Codex 0.138.0 или более поздней версии.

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

Добавьте управляемые ограничения файловой системы и сети

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

[permissions.filesystem]
deny_read = ["~/.ssh", "~/.aws/credentials", "~/.kube/config"]

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

default_permissions = "corp_network"

[allowed_permission_profiles]
corp_network = true

[permissions.corp_network]
extends = ":workspace"

[permissions.corp_network.network]
enabled = true

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"git.corp.example" = "allow"

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

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

В нативной среде Windows также используйте списки контроля доступа к файлам, поскольку одного управляемого deny_read недостаточно для контроля чтения из подпроцессов оболочки.

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

Установите хуки, управляемые администратором, и обеспечьте их применение

Поручите администратору установить проверенную программу хука в каталог, управляемый root, например /etc/codex/hooks/pre_tool_use_policy.py, и запретить пользователю Codex изменять файл или его каталог. В requirements.toml включите хуки и игнорирование хуков пользователя, проекта, сеанса и плагинов:

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/etc/codex/hooks"

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "/usr/bin/python3 /etc/codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking managed Bash command"

Требование регистрирует хук, но не устанавливает его. Для локального интеграционного теста в macOS сохраните следующий код как pre_tool_use_policy.py и поручите администратору установить его с помощью приведённых ниже команд.

Он блокирует только синтетический маркер; прежде чем полагаться на него, замените его проверенной политикой вашей организации. Убедитесь, что /usr/bin/python3 существует на целевом устройстве, и при необходимости скорректируйте путь к интерпретатору:

import json
import sys

event = json.load(sys.stdin)
command = event.get("tool_input", {}).get("command", "")
if "CODEX_HOOK_TEST_DENY" in command:
    print("Synthetic test command blocked by managed hook.", file=sys.stderr)
    sys.exit(2)

sudo install -d -o root -g wheel -m 755 /etc/codex/hooks
sudo install -o root -g wheel -m 644 ./pre_tool_use_policy.py /etc/codex/hooks/pre_tool_use_policy.py

Перезапустите локальный клиент, затем:

• Убедитесь, что безопасная команда Bash выполняется.

• Убедитесь, что команда, содержащая CODEX_HOOK_TEST_DENY, блокируется.

• Проверьте, что пользователь Codex не может изменить политику и зависимости.

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

Сопоставление Bash не охватывает все инструменты или ввод, переданный позже уже запущенному процессу; ошибки, тайм-ауты или некорректные ответы хуков могут позволить вызову инструмента продолжиться.

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

Защитите политику и её распространение

В macOS администратор может развернуть проверенный и объединённый файл требований в родительском каталоге, принадлежащем root, и запретить пользователю Codex запись в этот файл:

sudo install -d -o root -g wheel -m 755 /etc/codex
sudo install -o root -g wheel -m 644 ./requirements.reviewed.toml /etc/codex/requirements.toml
ls -ld /etc/codex
ls -l /etc/codex/requirements.toml

В Linux используйте соответствующую группу администраторов; в Windows защитите каталог ProgramData и файл списками контроля доступа, управляемыми администратором. Ограничьте круг лиц, которые могут менять MDM или облачную политику, проверяйте изменения и сохраняйте копию для отката.

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

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

Проверка

Используя тестовую учётную запись без прав администратора:

• Попробуйте изменить управляемую политику. Ожидаемый результат: управляемый файл нельзя изменить.

• Попробуйте ослабить ограничение через конфигурацию пользователя или проекта. Ожидаемый результат: менее строгие настройки отклоняются или остаются ограниченными.

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

Границы действия

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