Ключевой показатель — ноль гарантий изоляции файловой системы и сети на уровне ОС: именно так следует понимать ограничения локальной Unix-песочницы OpenAI Agents SDK, описанные в официальной документации SDK. Поэтому не допускайте недоверенные Agent-команды к корпоративному Mac CI только на основании того, что для задачи создана рабочая область. На этой неделе сначала проверьте доступ процесса к файлам, сети и учётным данным, затем разделите недоверенное исполнение, сборку Xcode и производственную подпись.
Эта статья для руководителей IT и платформенной инженерии, которые подключают AI Agent к конвейерам iOS и macOS и должны определить границы исполнения.
Она также пригодится специалистам по безопасности, отвечающим за исходный код и секреты, и техническим руководителям, выбирающим Mac-узлы для задач с Xcode.
OpenAI Agents SDK и корпоративный Mac CI: границы вместо названий режимов
Создание рабочей области означает, что задача получила место для файлов; это само по себе не доказывает, что команды ограничены этой областью. В документации SDK отдельно описаны локальный Unix-режим, Docker и управляемая среда исполнения. Это разные варианты, а не единая гарантия безопасности: фактические ограничения зависят от выбранного бэкенда и его настройки. Сравнить понятия рабочей области, сессии и исполнения можно в руководстве SDK по рабочим областям и сессиям.
Полезно разделять четыре вещи:
- Рабочая область — место организации файлов задачи.
- Сессия Agent — состояние взаимодействия и выполнения задачи.
- Права хостовой учётной записи — доступ процесса к ресурсам Mac.
- Изоляция операционной системы — принудительное ограничение доступа к файлам, сети и другим ресурсам на уровне ОС или внешней среды исполнения.
Если вы смешаете эти уровни, проверка будет отвечать не на тот вопрос. Например, наличие отдельной папки не подтверждает, что команда не читает файл за её пределами. А новая сессия не означает, что изменились права пользователя, сетевые маршруты или доступные секреты.
| Модель исполнения | Что она описывает | Что нужно проверить перед корпоративным применением |
|---|---|---|
| Локальная Unix-песочница | Выполнение на локальном хосте с его пользовательским контекстом | Права учётной записи, доступ к путям и сети, переменные окружения, видимость секретов |
| Docker-среда | Исполнение с использованием настроенного контейнерного бэкенда | Смонтированные каталоги, привилегии, сетевые правила, доступ к хосту и фактическую конфигурацию контейнера |
| Управляемая среда исполнения | Внешний по отношению к локальному хосту вариант исполнения | Границы арендатора и задачи, доступные ресурсы, политики данных и реальные гарантии конкретного сервиса |
Эта таблица не ранжирует режимы как «безопасный» и «небезопасный». Она показывает, какие факты нужно подтвердить для каждого пути. Даже если компонент называется песочницей, не переносите его заявленные свойства на другой бэкенд или настройки. Документация SDK по клиентам песочницы и краткое руководство по sandbox agents полезны для проверки текущей терминологии и поведения SDK, но не заменяют испытания вашей конфигурации.
Рабочая область и права пользователя: разные уровни доступа
Для локального исполнения исходите из прав процесса, а не из имени каталога проекта. Если SDK запускает shell-команду на Mac, доступ команды определяется контекстом пользователя и правилами самого хоста. Переменная HOME и текущая рабочая папка помогают приложению выбирать место работы, но сами по себе не запрещают обратиться к другому пути.
Также важно различать разрешения файлового API SDK и произвольные команды оболочки. Ограничение, применяемое при чтении или изменении файлов через API, нельзя автоматически считать фильтром для любой команды, которую Agent запускает через shell. Команда может использовать иные системные инструменты и пути. Проверяйте это именно на том способе исполнения, который планируете использовать.
| Проверяемая граница | Что может создать ложное ощущение защиты | Что подтвердить на тестовом узле |
|---|---|---|
| Файлы | Рабочая папка или значение HOME |
Попытка чтения и записи за пределами рабочей области |
| Сеть | Наличие отдельной сессии Agent | Доступность внутренних адресов и внешних направлений для процесса |
| Учётные данные | Отдельный каталог проекта | Переменные окружения, доступные файлы, ключи и разрешения пользователя |
На практике проверяйте каждую границу отдельно. Запустите тестовые команды, которые пытаются прочитать заранее выбранный файл за пределами проекта, обратиться к разрешённому и запрещённому сетевому адресу, а также обнаружить тестовый секрет. Проверяйте не только ожидаемый отказ, но и журналы: видно ли в них, какой пользователь выполнил процесс, какой путь или адрес был затронут и какой контроль сработал.
Для защиты важен и способ запуска. Не используйте для Agent учётную запись, которая по привычке получила доступ к рабочим каталогам нескольких проектов, ключам сборки и административным инструментам. Выделите отдельный контекст с минимально необходимыми правами; если дополнительные ограничения обеспечивает внешний исполнитель или системная политика, документируйте их отдельно. Пока тест не подтверждает ожидаемые запреты, считайте доступ возможным.
Новая сессия и временная папка не очищают состояние хоста
Отдельная сессия упрощает разделение истории задачи, но не обязательно создаёт отдельного пользователя или изолированное состояние системы. Точно так же создание и удаление временной рабочей области не гарантирует очистку всех следов выполнения. Эти понятия нужно проверять независимо: жизненный цикл папки, состояние сессии Agent и полномочия процесса — не одно и то же.
Перед повторным использованием узла выясните, что остаётся после задания: исходники и промежуточные файлы, кэш зависимостей, журналы, временные ключи, переменные окружения и процессы, которые не завершились штатно. Проверьте фактический сценарий очистки, в том числе после прерванной или аварийно завершённой задачи. Если следующий запуск работает в том же пользовательском контексте, проверьте, может ли он увидеть остатки предыдущего задания.
Не принимайте надпись «новая сессия» за доказательство чистого окружения. Зафиксируйте в пилоте, кто создаёт рабочую область, когда она удаляется, какие данные сохраняются вне неё и как узел возвращается в допустимое состояние. Для разделения проектов и недоверенных задач предпочитайте отдельный проверенный контекст исполнения, а не только новые каталоги на одном постоянно работающем хосте.
Xcode CI требует Mac, но не требует размещать там весь Agent
Не вся задача, связанная с iOS, должна исполняться на Mac. Анализ текста, подготовка патча и часть независимых проверок могут выполняться там, где доступны необходимые инструменты и достаточная изоляция. А сборка, зависящая от macOS и Xcode, должна направляться на соответствующий Mac-узел. Командные инструменты Xcode и их назначение описаны в документации Apple по Xcode Command Line Tools.
Это различие важно для архитектуры: нельзя считать, что Linux-контейнер или управляемая среда автоматически выполняет нативную сборку Mac. Сначала определите системные требования каждой операции, затем привяжите её к исполнителю с нужной ОС, набором инструментов и полномочиями.
| Тип задачи | Где выполнять | Условие допуска |
|---|---|---|
| Анализ и подготовка изменений без зависимости от Xcode | Изолированная среда с подходящими инструментами | Проверены сетевые и файловые ограничения |
| Команда, требующая macOS или Xcode | Контролируемый Mac-узел | Права процесса ограничены, доступ к исходникам и результатам проверен |
| Подписание производственного артефакта | Отдельный доверенный этап или узел | Agent не имеет прямого доступа к производственным ключам |
Такое разделение не означает, что каждый этап обязан быть физически отдельной машиной: конкретную реализацию определяют ваши средства изоляции и модель угроз. Но границы должны быть принудительными, а не только описанными в документации проекта. Если недоверенный код и доверенная подпись находятся в одном пользовательском контексте, считайте, что доступ к этому контексту требует отдельной оценки.
Подписывающие ключи должны оставаться за границей Agent
При анализе доступа учитывайте не только исходный код. В сборочной цепочке есть учётные данные репозитория, токены для внутренних зависимостей, артефакты сборки и секреты подписи. Попадание одного из этих типов данных в среду исполнения может быть достаточным для блокировки промышленного запуска — даже если сама сборка завершается успешно.
Назначьте отдельные роли: Agent готовит или анализирует изменения; контролируемый Mac выполняет необходимую Xcode-сборку; доверенный этап получает только те полномочия для подписи, которые требуются для утверждённого результата. Удаление секрета из файла после выполнения не подтверждает, что он не был прочитан, скопирован в журнал или сохранён в другой доступной области.
Для macOS отдельно проверьте хранение и доступ к секретам. Apple описывает механизмы списков контроля доступа в Keychain; ориентируйтесь на фактические правила доступа в вашей конфигурации, а не на само наличие ключа в связке. Для выпуска также важно, кто и на каком этапе подписывает код: документация Apple о подписании кода для распространения macOS описывает соответствующий процесс, но не доказывает, что ваш Agent не видит сертификат или закрытый ключ.
| Актив | Риск для CI | Проверка перед пилотом |
|---|---|---|
| Доступ к репозиторию | Чтение других проектов или использование токена вне задачи | Область действия токена, срок действия и видимость процесса |
| Внутренние зависимости | Доступ к закрытым пакетам или регистрационным данным | Какие учётные данные доступны на этапе разрешения зависимостей |
| Артефакты | Сохранение исходников и результатов между заданиями | Пути хранения, получатели и процедура удаления |
| Материалы подписи | Подписание неподтверждённого кода или раскрытие ключа | Доступ процесса к Keychain и разделение этапа подписи |
Минимизируйте полномочия, держите Agent отдельно от доверенного подписывающего этапа и проверяйте очистку после успешного, отменённого и аварийного запуска. Требуйте доказательств из реальной настройки: результаты тестов доступа, журналы, правила выдачи секретов и подтверждение состояния узла после задания. Если нужная граница не подтверждена, не переносите туда производственные ключи.
Контрольные точки: от пилота к допуску в CI
Используйте этот список как критерии решения, а не как формальную отметку о включении SDK. Каждый пункт должен завершаться проверяемым результатом: тестом, журналом, конфигурацией или подтверждённым ограничением.
- [ ] Зафиксируйте, какой бэкенд выполняет задачу: локальный Unix, Docker или управляемая среда; отдельно запишите его настройки.
- [ ] Запустите процесс Agent под определённой учётной записью и подтвердите её полномочия на чтение, запись и запуск команд.
- [ ] Проверьте попытки доступа к файлам вне рабочей области, включая каталоги других проектов.
- [ ] Проверьте исходящие соединения и обращения к внутренним сетевым ресурсам именно из контекста процесса Agent.
- [ ] Установите, какие токены, переменные окружения, элементы Keychain и файлы доступны процессу во время выполнения.
- [ ] Разделите обычное исполнение Agent, Mac-сборку с Xcode и этап производственной подписи; подтвердите маршрут артефакта между этапами.
- [ ] Проверьте удаление временных данных и остаточное состояние узла после обычного и аварийного завершения задачи.
- [ ] Сохраните доказательства и определите владельца, который повторит проверки при изменении SDK, бэкенда или системной конфигурации.
Переход между этапами: сначала проверяется модель угроз и путь команды; затем выполняются тесты файлового, сетевого и учётного доступа; после этого — пробная сборка без производственных секретов. Только если результаты подтверждают ограничения, можно рассматривать следующий уровень допуска. Если какое-либо действие выходит за заявленную границу, верните его в изолированную среду и исправьте архитектуру до увеличения объёма заданий.
Ориентируйтесь на актуальные примечания к выпускам OpenAI Agents SDK: изменения в SDK могут повлиять на поведение и доступные варианты исполнения. После обновления повторно подтвердите именно те свойства, от которых зависит ваша защита, а не только успешный запуск тестового сценария.
Ответы на вопросы
Ограничивает ли локальная песочница SDK доступ к файлам и сети macOS?
Нет, сама по себе она не создаёт изоляцию файловой системы и сети на уровне операционной системы. Рабочая область организует файлы задачи, а разрешения файлового API относятся к этому API. Произвольная shell-команда может иметь иной доступ в соответствии с правами пользователя и внешними правилами хоста. Проверяйте реальное поведение команды, а не название режима.
Под какой учётной записью выполняются команды Agent на Mac?
Локальная команда выполняется с полномочиями того пользовательского контекста, в котором запущен процесс SDK. Поэтому важны не только переменные окружения и текущая папка, но и права учётной записи, доступные ей ключи, процессы и сетевые маршруты. Запускайте Agent под отдельной минимально привилегированной учётной записью и проверяйте доступ практическими тестами.
Как отделить рабочую область Agent от узла Xcode и подписи?
Размещайте обработку недоверенных инструкций и подготовку изменений отдельно от доверенного Mac-узла, который выполняет обязательную сборку Xcode. Не передавайте Agent доступ к учётным данным подписи. Если производственная подпись необходима, выдавайте её только отдельному доверенному этапу после проверки результата; доступ к связке ключей и сертификатам проверяйте в фактической конфигурации.
Можно ли выполнять недоверенные команды Agent непосредственно на хосте Mac CI?
Не считайте локальную песочницу достаточной защитой для такой команды. Сначала выясните, какие файлы и сетевые ресурсы доступны пользовательскому процессу, и подтвердите ограничения внешними средствами. Если команда недоверенная, направляйте её в отдельно проверенную среду исполнения; на Mac оставляйте только работу, которой действительно требуются macOS и Xcode.
Если задачи требуют настоящей macOS или Xcode, удалённый Mac может быть практичнее, чем расширение доступа Agent на рабочем CI-хосте. Но такой вариант не отменяет минимальных прав, проверки очистки и отдельного доверенного этапа подписи. Для планирования ресурсов сравните варианты удалённого Mac и условия аренды: покупка собственного Mac подходит, когда нагрузка постоянна и вам нужны физический доступ и полный контроль; аренда VMSPIN уместна для пилота или переменной потребности, когда вы не хотите заранее закреплять бюджет за отдельной машиной. До подключения к CI проверьте границы доступа и восстановления на выбранном узле — и не выдавайте производственные секреты, пока эти проверки не пройдены.