Внутри обвязки: разрешения, привязанные к ходу, становятся базовым примитивом среды выполнения агентов

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

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

Ключевые выводы - Разрешения, привязанные к ходу, означают, что при начале хода среда выполнения фиксирует снимок политики подтверждений, политики песочницы и профиля разрешений, а каждый вызов инструмента внутри этого хода выполняется по зафиксированному снимку. - Модель угроз здесь не злонамеренный пользователь. Это способный агент, который выполняет враждебную инструкцию из-за инъекции промпта или отклоняется от задачи, работая на вашей машине с вашими учётными данными. - Codex реализует границу тремя независимыми регуляторами: политика подтверждений, то есть нужно ли спрашивать; режим песочницы, то есть чего могут касаться команды; и профили разрешений с детальными правилами файловой системы и сети. Принуждение выполняет ОС, а не модель. - Контроль находится ниже модели: Seatbelt на macOS, bubblewrap плюс seccomp на Linux и отдельная песочница на Windows. Если политику невозможно обеспечить, Codex отказывается выполнять команду. - Нерешённая граница сейчас это изменение разрешений внутри хода: сегодня снимок неизменяем до конца хода, что безопасно и временами ужасно раздражает.

Что произошло

В конце июля и начале августа поверхность разрешений Codex выросла из пары грубых настроек во что-то уже похожее на движок политик, а документация догнала код. Старая модель состояла из двух регуляторов в config.toml: sandbox_mode (read-only, workspace-write, danger-full-access) и approval_policy (untrusted, on-request, never). Новая добавляет профили разрешений, пока в бете: именованные составные политики, объединяющие правила файловой системы (read, write, deny для каждого пути, причём запрет имеет приоритет) и сетевые правила, то есть списки разрешённых доменов, принудительно применяемые через локальный прокси. Вместе со средой выполнения поставляются три встроенных профиля: :read-only, :workspace и :danger-full-access. Их предполагается расширять, а не собирать всё с нуля.

Одновременно с конфигурацией модель взаимодействия стала сильнее ориентирована на отдельные ходы. /permissions переключает режимы внутри уже идущей сессии. Детальная политика подтверждений позволяет оставить некоторые категории запросов интерактивными, например расширение песочницы и запросы MCP, а другие автоматически отклонять. Среди них есть отдельная категория request_permissions, когда сам агент просит больше доступа посреди задачи. Запросы на подтверждение также можно направлять автоматическому агенту-рецензенту, который проверяет их на эксфильтрацию, поиск учётных данных и разрушительные действия ещё до того, как запрос увидит человек, согласно документации OpenAI о подтверждениях и безопасности.

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

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

Что на самом деле означает «привязано к ходу»

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

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

Зачем вообще делать снимок? Потому что альтернатива хуже. Если разрешения представляют собой изменяемое глобальное состояние, тогда всё, что способно влиять на это состояние, включая контент, прочитанный агентом, получает рычаг над тем, что агент сможет сделать дальше. Неизменяемый снимок на один ход означает, что решение о правах принимается один раз человеком или политикой в момент ясного намерения, а агент не может уговорить систему пропустить его дальше уже в процессе работы. Ход становится минимальной единицей доверия, что совпадает с реальным разбиением агентной работы: «проверь эти изменения» и «отправь изменения в main» не должны иметь один контекст разрешений, даже если выполняются в одной сессии.

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

Какую модель угроз это закрывает

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

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

Тихая угроза это уход в сторону и чрезмерная инициативность. Способный агент, выполняющий вполне легитимную работу, всё равно может начать блуждать: установить что-нибудь, скачать зависимость, «полезно» подчистить каталог. Песочница закрывает проблему, не требуя злого умысла от агента. Именно поэтому границу обеспечивает ОС, Seatbelt на macOS, bubblewrap плюс seccomp на Linux и нативная песочница на Windows, а не здравый смысл модели. Если платформа не может обеспечить запрошенную политику, Codex отказывается запускать команду вместо того, чтобы запустить её без песочницы. Безопасный отказ, а не надежда на лучшее.

Доступ к учётным данным умножает ущерб. Руководство по devcontainer формулирует это без обиняков: запустите Codex с полным доступом внутри контейнера, и вредоносный проект сможет вынести всё, что в контейнере есть, включая учётные данные Codex. Поэтому новые примитивы так конкретны в отношении секретов: шаблоны "**/*.env" = "deny", которые вырезают файлы с учётными данными из доступных на запись рабочих пространств; .git, .codex и .agents, защищённые как доступные только для чтения внутри записываемых корней; и сетевой прокси, по умолчанию блокирующий локальные и приватные адреса в качестве защиты от повторной привязки DNS. По форме это та же архитектурная идея, что и в более широком вопросе архитектуры агентного ИИ: модель предлагает, обвязка решает, а секреты должны храниться у обвязки.

Документированная модель угроз Codex сосредоточена на инъекции промпта, где сеть по умолчанию отключена, а кэшированный веб-поиск снижает контакт с враждебным живым контентом; уходе агента от задачи, где песочницы на уровне ОС отказываются исполнять команды, ограничения которых не могут обеспечить; и утечке учётных данных, где применяются шаблоны запрета для .env, пути только для чтения .git и .codex и блокировка локальной сети, согласно документации OpenAI по безопасности.

Как реализация устроена внутри

Три детали реализации стоит позаимствовать для собственного мышления о среде выполнения.

При одинаковой специфичности запрет сильнее записи, а запись сильнее чтения. Профили разрешений позволяют сначала выдать широкий доступ, а потом вырезать исключения: рабочее пространство доступно на запись, **/*.env запрещён, .devcontainer только для чтения. Более конкретные пути переопределяют широкие, а запрещённый подпуть остаётся запрещённым внутри родителя, доступного на запись. Можно даже снова открыть узкое поддерево внутри широкого запрета, например запретить ~/Documents, но разрешить запись в ~/Documents/codex. Это правильная модель приоритетов, потому что она позволяет наращивать принцип минимальных привилегий поверх доступа на запись, а не пытаться вычитать его из памяти.

Сетевой доступ и фильтрация сети это два разных переключателя. network.enabled = true разрешает командам выходить в сеть; features.network_proxy = true фактически обеспечивает ваши доменные правила через локальный прокси. Первое без второго даёт неограниченный исходящий доступ и ложное ощущение управления. Для доменов сначала действует список разрешений, запрет имеет приоритет, а localhost и родственные адреса заблокированы, пока вы явно их не разрешите, потому что агент в песочнице с доступом к вашим локальным демонам в содержательном смысле уже не в песочнице.

Старая и новая системы не складываются. Профили и устаревшие настройки sandbox_mode взаимоисключающие: если любой загруженный слой конфигурации задаёт sandbox_mode, профили игнорируются. Корпоративные администраторы могут принудительно включить новую модель через управляемый список allowed_permission_profiles, который одновременно запрещает встроенные профили, не вошедшие в список. Если из всей схемы вынести один операционный урок, то вот он: две системы разрешений, которые «обе как-то применяются», это отличный способ быть уверенным, что вы что-то запретили, когда на самом деле нет. Выберите одну, проверьте её через /permissions и /status, и только потом расширяйте.

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

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

Что делать сейчас

1. Сегодня: выполните /permissions и /status в следующей сессии Codex и посмотрите, что действует на самом деле, а не что, как вам кажется, должно действовать. Если любой слой конфигурации всё ещё задаёт sandbox_mode, вы незаметно отказались от профилей разрешений. Определитесь, какую систему используете.

2. На этой неделе: создайте один собственный профиль на базе :workspace, запретите **/*.env и разрешите только те API-домены, к которым действительно обращаетесь, при включённом network_proxy. Протестируйте его командой песочницы codex debug, прежде чем доверять. Если вы проверяете сторонний код, закрепите такие проекты за профилем, производным от :read-only, в их проектной конфигурации.

3. В этом месяце: если вы строите среду выполнения агентов или оборачиваете готовую, сделайте ход единицей разрешений: снимок в начале хода, отзыв в конце, секреты вне контекста модели и безопасный отказ при невозможности обеспечить политику. Затем письменно ответьте на открытый вопрос, который сам Codex ещё не решил: что должно происходить, если разрешения меняются посреди хода? «Ничего до следующего хода» безопасно, но пользователи будут ожидать, что интерфейс действительно означает то, что показывает.

Частые вопросы

Что такое разрешения, привязанные к ходу?

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

Чем это отличается от запуска агента под ограниченным пользователем ОС?

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

Может ли инъекция промпта изменить разрешения Codex?

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

Профили разрешений уже достаточно стабильны, чтобы на них строить?

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

Итог

Разрешения агентов взрослеют примерно так же, как когда-то права Unix: от «root или ничего» к детальным, минимально необходимым и аудируемым границам. Только единицей здесь становится не процесс и не пользователь, а ход. Codex сейчас самая наглядная реализация для изучения, а его самый шероховатый край, неизменяемый снимок внутри хода, одновременно самый поучительный: даже эталонная среда выполнения всё ещё выясняет, насколько динамичным может быть разрешение, прежде чем само понятие перестанет что-либо значить. Если вы строите или эксплуатируете агентов, разберитесь в форме этого примитива сейчас. Через год он будет в каждой серьёзной среде выполнения, а те, кто ошибётся в семантике снимков, узнают об этом публично.

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

Источники

• OpenAI Developers, «Разрешения Codex»: https://developers.openai.com/codex/permissions (получено 29.08.2026)

• OpenAI Developers, «Подтверждения агентов и безопасность»: https://developers.openai.com/codex/agent-approvals-security (получено 29.08.2026)

• GitHub, обсуждение #32612 в openai/codex, «Применять изменения контроля доступа к текущему выполняющемуся ходу»: https://github.com/openai/codex/issues/32612 (создано 12.07.2026, получено 29.08.2026)

• GitHub, обсуждение #23626 в openai/codex, «Codex CLI /permissions не показывает режим только для чтения в WSL2, но показывает в Windows PowerShell»: https://github.com/openai/codex/issues/23626 (создано 20.05.2026, получено 29.08.2026)

• Репозиторий OpenAI Codex: https://github.com/openai/codex (получено 29.08.2026)