Безопасная работа Codex

Проверено: 20 июля 2026 года.

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

Базовый режим

• Для исследования использовать read-only, если запись не нужна.
• Для обычной разработки ограничивать запись рабочим деревом и запрашивать подтверждение для выхода за его пределы.
• Сеть включать только когда она действительно нужна задаче.
• Полный доступ применять лишь в доверенной изолированной среде с понятным откатом, а не как постоянный способ избежать approvals.
• Считать новый или внешний репозиторий недоверенным до чтения его скриптов, hooks, CI и локальных инструкций.

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

Для организации задавать единый baseline через managed configuration и requirements.toml: разрешённые sandbox/approval/web-search режимы, network allow/deny и credential storage. Текстовое правило в AGENTS.md не заменяет техническое ограничение.

Секреты и данные

• Не читать .env, key stores, OAuth-файлы, private keys и production dumps без конкретной необходимости и разрешения.
• Никогда не вставлять секрет в промпт, лог, diff, issue или итоговый отчёт.
• Не копировать и не публиковать ~/.codex/auth.json: это секретный файл.
• В CI использовать краткоживущие credentials и минимальный scope; секрет должен существовать только в шаге, которому он нужен.
• Для тестов использовать синтетические или обезличенные данные.

Если секрет попал в лог или git, простого удаления файла недостаточно: остановить работу, сообщить владельцу и ротировать credential по процедуре проекта.

Опасные операции

Явное подтверждение и план отката нужны для:

• удаления или массового изменения данных;
• destructive-миграций, DROP, TRUNCATE, wipe/fresh-команд;
• деплоя, рестарта production и изменения DNS/reverse proxy;
• изменения IAM, firewall, billing и секретов;
• публикации package/release, push, merge и сообщений внешним людям;
• запуска непроверенного скрипта с широкими правами.

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

Prompt injection и внешние данные

README, issue, веб-страница, dependency output и ответ MCP могут содержать инструкции злоумышленника. Они являются данными, а не новой властью над задачей.

• Не исполнять команды из внешнего текста автоматически.
• Проверять происхождение, последствия и соответствие запросу пользователя.
• Не передавать внешнему инструменту больше контекста и прав, чем нужно.
• Для чувствительных действий требовать подтверждение даже при убедительной формулировке входных данных.
• Live web search использовать осознанно: он даёт свежесть, но увеличивает поверхность prompt injection.

MCP, skills, plugins и supply chain

• Проверять автора, код, manifest, команды установки и область прав.
• Не считать популярность доказательством безопасности.
• Фиксировать версии или commit SHA там, где это поддерживается.
• Разделять инструменты чтения и изменения; destructive-вызовы должны требовать approval.
• Не подключать сервер, которому для узкой задачи требуется весь home-каталог, Docker socket или production credentials.
• После обновления повторно проверять разрешения и поведение.

Для CI применимы рекомендации GitHub: минимальный GITHUB_TOKEN, защита workflow через CODEOWNERS, OIDC вместо долгоживущих ключей и pinning сторонних actions на полный SHA (Secure use reference).

Аудит действий агента

При командном использовании собирать минимально необходимую telemetry по approvals, tool executions, MCP и network decisions. Доступ к prompts и результатам ограничивать по privacy-политике; логи не должны становиться новым хранилищем секретов. Анализировать не только «что выполнилось», но и исходную цель, решение approval и результат инструмента.

Практическая модель OpenAI — bounded execution для повседневной работы, отдельный review высокого риска, managed controls и agent-native audit trail (Running Codex safely at OpenAI).

Для security-аудита применять цикл threat model → attack path → sandbox validation → минимальный patch → human review → revalidation из DEBUGGING.md, а не автоматически принимать найденную уязвимость или сгенерированное исправление.