Sandbox для Codex на Windows: как OpenAI решила задачу безопасности

Когда AI-агент получает доступ к файловой системе вашего компьютера, возникает закономерный вопрос: где проходит граница между полезным инструментом и угрозой безопасности? OpenAI подробно рассказала о том, как инженеры компании строили изолированную среду (sandbox — защищённое окружение для выполнения кода) для Codex на Windows — и с какими неожиданными трудностями столкнулись.

Проблема: Codex без изоляции

Когда в сентябре 2025 года разработчик присоединился к команде Codex, у версии для Windows вообще не было реализации sandbox. Это вынуждало пользователей Windows выбирать между двумя неудобными вариантами.

Первый вариант — включить режим Full Access (полный доступ), позволяя Codex выполнять все команды без ограничений и подтверждений. Второй — вручную подтверждать почти каждую команду агента, что полностью лишало смысла само использование инструмента.

Codex — это coding agent (агент написания кода), который работает непосредственно на ноутбуке разработчика через CLI, расширение для IDE или десктопное приложение. Он управляет диалогом между человеком за клавиатурой и моделью в облаке. По умолчанию Codex работает с правами реального пользователя — то есть может делать всё, что может делать сам пользователь.

Почему стандартные решения Windows не подошли

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

AppContainer — встроенный sandbox Windows — привлекателен тем, что создаёт реальную границу на уровне ОС. Однако Codex — не одно узкоспециализированное приложение. Он управляет открытыми рабочими процессами разработчика: оболочками, Git, Python, менеджерами пакетов, инструментами сборки и любыми бинарными файлами. AppContainer оказался неподходящей формой для задачи.

Windows Sandbox — одноразовая лёгкая VM от Microsoft, где всё происходящее внутри исчезает по завершении сессии. Она привлекательна с точки зрения безопасности, но Codex должен работать напрямую с реальной кодовой базой пользователя, его инструментами и окружением — а не внутри отдельного изолированного рабочего стола, требующего настройки и сложного взаимодействия хоста с гостем.

Ключевые строительные блоки: SID и restricted token

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

Это означало необходимость разумно ограничить две вещи: запись файлов и сетевой доступ. Без ограничений на запись файлов возникает угроза безопасности. Если ограничить запись слишком жёстко — sandbox будет постоянно запрашивать подтверждения, снижая продуктивность разработчика.

Для решения этой проблемы были задействованы два важных механизма Windows: SID (security identifier — идентификатор безопасности) и write-restricted token (токен с ограниченной записью). SID — это идентификатор, с которым Windows связывает разрешения. Каждый пользователь имеет свой SID, группы тоже имеют SID, и даже отдельный сеанс входа получает собственный SID.

Когда команды выполняются через sandbox, лаунчер настраивает restricted Windows token (ограниченный токен Windows) и политику разрешённых путей, привязанную к объявленным корневым директориям рабочего пространства. Запись блокируется везде, кроме этих корней (плюс %TEMP% в режиме workspace-write), а распространённые векторы обхода — альтернативные потоки данных, UNC-пути и дескрипторы устройств — блокируются превентивно.

CLI также внедряет stub-исполняемые файлы (заглушки), например для ssh, в начало системного PATH, чтобы перехватывать потенциально опасные инструменты до того, как они покинут пределы sandbox.

Проблема сетевого доступа

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

Для надёжного сетевого контроля было принято решение использовать Windows Firewall (брандмауэр Windows), позволяющий блокировать исходящий трафик для конкретных пользователей или программ. Однако возникло техническое ограничение: Windows не позволяет привязать правило брандмауэра к «не основной» идентичности restricted token — то есть нельзя применить правило ко «всем токенам, включающим наш синтетический SID в списке restricted SIDs».

Решением стало введение двух типов пользователей sandbox — offline (офлайн) и online (онлайн) — чтобы задачи по умолчанию выполнялись без доступа к внешней сети.

Архитектура нового sandbox: четыре этапа выполнения

Прежде чем команда достигает дочернего процесса, система проходит четырёхэтапный путь выполнения: исполняемый файл установки создаёт аккаунты sandbox, проверяет состояние брандмауэра, сохраняет учётные данные с помощью DPAPI, затем передаёт управление codex-command-runner.exe.

flowchart TD
    A[Запрос от Codex] --> B[Setup executable\nСоздание sandbox-аккаунтов]
    B --> C[Проверка состояния\nбрандмауэра Windows]
    C --> D[Сохранение учётных данных\nчерез DPAPI]
    D --> E[codex-command-runner.exe]
    E --> F{Действие в рамках\nсandbox?}
    F -- Да --> G[Выполнение команды]
    F -- Нет --> H[Запрос подтверждения\nу пользователя]

DPAPI (Data Protection API) — это механизм защиты учётных данных Windows, а не отдельный облачный шлюз. Он привязывает сохранённые учётные данные к идентификатору локального компьютера, а значит, sandbox-аккаунты не смогут украсть их с устройства, даже если вредоносный промпт попытается это сделать.

Три ключевых ограничения sandbox

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

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

Контексты использования: native Windows vs WSL2

Codex использует платформенные механизмы принудительного исполнения на каждой ОС. Реализация различается для macOS, Linux, WSL2 и нативного Windows, но идея одна: дать агенту ограниченное пространство для работы, чтобы рутинные задачи выполнялись автономно в чётко заданных рамках.

Нативный Windows sandbox обеспечивает максимальную производительность, сохраняя при этом тот же уровень безопасности. WSL2 стоит выбрать, если вам нужна Linux-среда на Windows или ваш рабочий процесс уже живёт в WSL2.

Открытый исходный код и прозрачность

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

OpenAI открыто приглашает разработчиков, озабоченных безопасностью, помочь с доработкой: улучшенные реализации smoke-тестов существенно сократят поверхность возможных «побегов» из sandbox.

Текущие ограничения и честность о пробелах

При запуске smoke-тестов с полным доступом к файловой системе и сети текущая реализация проходит 37 из 41 тест-кейса. OpenAI не скрывает, что работа продолжается.

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

Заключение

Разработка sandbox для Codex на Windows — показательный пример того, как сложно обеспечить безопасность AI-агента, которому для эффективной работы требуется доступ к реальной среде разработчика. Стандартные механизмы изоляции Windows оказались либо слишком жёсткими, либо слишком слабыми. OpenAI пришлось комбинировать несколько слоёв защиты: SID, restricted token, ACL, брандмауэр и DPAPI.

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

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