Модель безопасности: песочница, сеть, одобрения

Безопасность агента нельзя строить на том, что модель «будет вести себя хорошо». Её строят на технических границах, которые действуют, даже если агента обманули. У Codex таких границ несколько, и у каждой есть дыры, о которых документация пишет честно. В уроке — модель целиком, глазами того, кто отвечает за риск.

Две оси: песочница и одобрения

Документация разделяет два слоя (approvals and security):

• Песочница (sandbox) решает, что технически возможно: какие файлы читать и писать, есть ли сеть.
• Политика одобрений (approval policy) решает, когда агент должен остановиться и спросить человека.

Это независимые рычаги. Можно разрешить запись в рабочую папку и требовать одобрения на всё остальное, а можно запретить запись и никогда не спрашивать — так работает CI.

Режимы песочницы: read-only, workspace-write и danger-full-access. В новых версиях они выражаются профилями прав :read-only, :workspace, :danger-full-access (функция в статусе beta). Для папки под git Codex по умолчанию предлагает запись в рабочую папку плюс одобрения по запросу; сеть в этом режиме выключена. Даже внутри рабочей папки защищены от записи .git, .agents, .codex и .aws.

Политики одобрений: on-request (агент спрашивает, когда нужно выйти за границы), never (никогда не спрашивает — но и не получает лишних прав) и гранулярная политика, где отдельно настраиваются категории запросов. Политика untrusted выведена из употребления — если она встречается в ваших конфигах, её нужно убрать.

Чем обеспечена песочница

Песочницу обеспечивает операционная система, и ограничения наследуются всеми дочерними процессами: на macOS это Seatbelt, на Linux — bubblewrap и seccomp, на Windows — собственная песочница. WSL1 не поддерживается. Если агент запустил composer install, а тот — скрипт пакета, ограничения действуют и на скрипт.

Отсюда практическое следствие: Linux-песочница внутри Docker может не заработать, если контейнер не даёт нужных возможностей. Тогда внешней границей становится сам контейнер, а Codex запускают с полным доступом внутри него. Документация предупреждает: в таком режиме вредоносный проект может вынести всё, что есть в контейнере, включая учётные данные Codex. Этот вариант — только для доверенных репозиториев.

Сеть и её слепые зоны

Для локальных команд сеть контролируется прокси с правилами allow и deny; запрет всегда побеждает, локальные и приватные адреса по умолчанию заблокированы. Но вот что прокси не фильтрует — по документации: веб-поиск, вызовы приложений и коннекторов, соединения MCP-серверов, браузер и Computer Use, облачные задачи, а также собственные запросы клиента к модели.

Для техдира это главный пункт урока. Сетевой allowlist не защищает от утечки через MCP-сервер, который ходит куда угодно, или через браузер агента. Эти каналы закрываются другими настройками: списком разрешённых MCP-серверов, режимом веб-поиска, флагами функций браузера и Computer Use в требованиях (см. урок про администрирование).

Ещё одна тонкость из документации Agent Security: одобренное повышение до полного доступа может обойти управляемый allowlist прокси. Проверяйте политику и на обычных, и на повышенных командах.

Веб-поиск по умолчанию работает через кэш — заранее проиндексированные результаты, а не живые страницы. Это снижает риск prompt injection, но результаты всё равно считаются недоверенными. В режиме полного доступа поиск по умолчанию переключается на живые результаты.

Облачные задачи

В облаке своя модель. Для старого облачного режима документация указывает, что доступ в интернет на этапе работы агента по умолчанию закрыт, а скрипт настройки окружения выполняется с сетью, чтобы поставить зависимости; секреты доступны только на этапе настройки (internet access). В текущих облачных окружениях доступ в интернет включается переключателем с пресетами, а сетевые секреты подставляются прокси только для разрешённых HTTPS-адресов — сам ключ не попадает ни в процесс, ни в файл (cloud environments). Сетевые правила Agent Security действуют поверх настроек окружения.

Автоматический ревьюер — не граница

Режим approvals_reviewer = "auto_review" заменяет человека, одобряющего запросы, агентом-ревьюером. Он нацелен на отправку секретов в недоверенные места, поиск учётных данных, ослабление защиты и разрушительные действия. Документация формулирует жёстко: это замена ревьюера, а не выдача прав, и не детерминированная гарантия безопасности (auto-review). Сбои ревьюера закрывают действие, а не пропускают, — но полагаться на него вместо песочницы нельзя. То же про мониторинг безопасности модели: он может поставить задачу на паузу, но не заменяет песочницу и права.

Какие режимы выбрать

Документация даёт типовые сочетания; вот как они ложатся на агентство:

Флаг --dangerously-bypass-approvals-and-sandbox (он же --yolo) вне изолированного окружения запрещайте политикой: профиль :danger-full-access просто не включайте в список разрешённых.

Модель угроз агентства

Соберите для себя список того, что агент может достать на машине разработчика: .env с ключами клиентских CRM и платёжных систем, SSH-ключи к серверам клиентов, дампы баз с персональными данными, токены Git-хостинга. Минимальный набор мер:

• deny_read на .env, ~/.ssh и папки с дампами — через требования, а не просьбой в AGENTS.md.
• Боевые ключи клиентов не живут на ноутбуках. Для разработки — тестовые ключи интеграций.
• Список разрешённых MCP-серверов и запрет живого веб-поиска, пока он не нужен.
• Сеть для агента — только по allowlist: реестры пакетов и ваш Git-хостинг.

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