OpenAI Hosted Sandboxes стоит использовать для быстрой проверки Agent, который выполняет код, создаёт файлы или обрабатывает данные, но не следует считать такую среду готовой продуктивной инфраструктурой без приёмки прав, зависимостей, постоянства файлов, сети, восстановления, аудита и лимитов затрат. Если Agent работает с чувствительными данными или должен менять внешние системы, до запуска сравните Hosted Sandboxes с собственной песочницей, VPC-средой и облачным Mac.
Эта статья предназначена для трёх групп:
- разработчиков Agent, которым нужно безопасно запускать код и работать с файлами;
- инженеров платформы, отвечающих за секреты, сеть, журналы и жизненный цикл задач;
- технических руководителей, принимающих решение о допуске Hosted Sandboxes в рабочий процесс.
Последнее обновление — 22 сентября 2026 года. Актуальность проверяйте по официальному описанию Agents API, документации Sandbox Agents и текущим материалам OpenAI по вычислительной среде. Конкретные ресурсы, регионы, цены и модель разрешений могут меняться, поэтому их нельзя принимать по старому примеру или пересказу.
Граница применимости Hosted Sandboxes
Что можно принять быстро
Hosted Sandboxes разумно рассматривать как первый слой для задач, где результат можно проверить по входным данным и полученным артефактам:
- запуск скриптов для преобразования документов;
- генерация таблиц, отчётов, изображений или архивов;
- локальная обработка набора файлов;
- анализ данных без права записи во внешнюю систему;
- воспроизводимый шаг CI/CD, который получает входные файлы и возвращает результат;
- экспериментальная оркестрация инструментов в OpenAI Agents API.
В таких сценариях главным объектом приёмки становится не красота демонстрации, а повторяемость. Один удачный запуск показывает только то, что путь возможен. Он не подтверждает наличие зависимостей после перезапуска, корректность рабочей директории, сохранность артефакта, поведение при отмене и безопасность секретов.
Где требуется осторожность
Задача уже не является простой «кодовой» операцией, если Agent должен:
- отправлять изменения в производственную базу данных;
- публиковать данные через внешнюю CRM, Git-сервис или платёжную систему;
- читать персональные, медицинские, финансовые или внутренние документы без предварительного обезличивания;
- поддерживать долгую сессию с гарантированным состоянием;
- работать внутри сложной сетевой топологии с частными адресами, прокси и allowlist;
- принимать решения, после которых невозможно быстро отменить действие.
Модель может корректно выбрать инструмент и сформировать правильный аргумент, но это не означает, что инструменту нужно выдавать полный доступ к системе. Право вызвать функцию и право изменить реальный ресурс должны быть разделены. Для опасных действий используйте отдельный контролируемый шлюз, предварительную проверку параметров и явное подтверждение человека.
Быстрое решение по сценарию
Подходит для быстрой проверки, если входные данные можно скопировать в изолированную среду, задача не требует постоянного внешнего состояния, а результат можно скачать и проверить хешем, схемой или автоматическим тестом.
Подходит для ограниченного серого запуска, если у вас есть временные секреты, ограниченный список исходящих адресов, журнал действий, лимит времени и процедура повторного запуска. Такой запуск должен начинаться с небольшого набора некритичных задач, а не с полного рабочего потока.
Не следует отдавать Hosted Sandboxes напрямую, если Agent имеет неограниченный доступ к внутренней сети, хранит долгоживущие ключи, записывает данные в продуктивную систему без шлюза или должен гарантировать состояние после любого сбоя. В этом случае сравнивайте собственную песочницу или VPC с облачным Mac, особенно когда нужны специфические инструменты разработки, графическая сессия или Mac-окружение.
Подготовка к запуску: права, данные и зависимости
Изоляция полномочий
До первого запуска составьте карту инструментов. Для каждого инструмента зафиксируйте:
- какие параметры он принимает;
- какие ресурсы читает;
- какие ресурсы изменяет;
- нужен ли ему интернет;
- какой ущерб возникнет при повторном вызове;
- как действие отменяется;
- где появляется запись аудита.
Разделяйте секреты по назначению. Токен для чтения тестового хранилища не должен одновременно разрешать удаление файлов и публикацию результата. Секреты не следует помещать в исходные файлы, пользовательский prompt, логи аргументов или создаваемые Agent отчёты. В тестовом прогоне используйте специально выпущенные ключи с коротким сроком действия и заранее проверьте, что они не попадают в скачиваемый артефакт.
Официальные материалы OpenAI описывают Agent как систему, которая может планировать действия и пользоваться инструментами; это не является гарантией того, что конкретная интеграция автоматически ограничит опасные операции. Сопоставляйте эволюцию Agents SDK и модель инструментального выполнения со своей политикой разрешений, а не заменяйте политикой сам факт наличия SDK.
Файлы и обезличивание
Перед загрузкой данных определите четыре зоны:
- входные файлы, которые Agent может только читать;
- временные файлы, которые можно удалить после задания;
- выходные артефакты, которые разрешено скачать;
- служебные файлы, недоступные модели и пользователю.
Проверьте имена, расширения, символические ссылки, архивы и скрытые файлы. Архив с вредоносным или неожиданным содержимым должен проходить отдельную проверку до распаковки. Если модель должна анализировать реальные документы, сначала замените идентификаторы клиентов, токены, адреса и другие чувствительные поля тестовыми значениями.
Не делайте предположение, что файл автоматически становится постоянным. Для каждого артефакта задайте владельца, срок хранения и способ удаления. Если задача прерывается, должно быть понятно, остался ли неполный файл, где он находится и можно ли его безопасно использовать.
Зависимости и точка входа
Повторяемая проверка должна начинаться с чистого состояния. Зафиксируйте:
- версию runtime;
- список пакетов и способ их установки;
- точку входа скрипта;
- переменные окружения;
- рабочую директорию;
- формат входа и выхода;
- команду проверки результата.
Установка пакетов во время каждого запуска удобна для демонстрации, но создаёт неопределённость: меняется источник пакета, длительность установки и результат при недоступности сети. Там, где это разрешено средой, подготовьте воспроизводимый lock-файл или заранее собранное окружение. Если установка выполняется во время задания, журналируйте команду, версию и ошибку, а не только итоговый статус.
Минимальный повторяемый тест должен включать одинаковый вход, ожидаемый тип результата и проверку содержимого. Запустите его после чистого старта, после удаления временной директории и после прерывания. Успешная демонстрация в уже прогретой среде не считается доказательством готовности.
Важно. Если в документации не обещаны постоянные файлы, конкретный сетевой маршрут или фиксированный срок жизни среды, не превращайте поведение текущего запуска в контракт. Зафиксируйте наблюдение как тестовый результат и добавьте повторную проверку после обновления платформы.
Серая эксплуатация: сеть, сбои и наблюдаемость
Сетевые режимы
Проверьте Agent минимум в трёх логических режимах:
- без исходящего доступа;
- с ограниченным доступом к заранее разрешённым адресам;
- с вызовом внешнего сервиса через контролируемый шлюз.
В каждом режиме должен быть отдельный ожидаемый результат. Например, отсутствие сети должно приводить к понятной ошибке и безопасному завершению, а не к бесконечным повторам. Ограниченный доступ должен подтверждаться наблюдаемым правилом, а не только тем, что «нужный URL открылся». Внешний сервис должен получать только необходимые поля, с отдельным тайм-аутом и идентификатором корреляции.
Не проверяйте сеть одним запросом к публичному сайту. Для приёмки важнее установить, что запрещённые направления недоступны, DNS и прокси ведут себя ожидаемо, а ошибка внешнего сервиса не превращается в повторную запись в продуктивную систему.
Тайм-ауты, отмена и повтор
Для каждой операции определите отдельные пределы:
- время ожидания инструмента;
- время всей задачи;
- срок ожидания внешнего сервиса;
- число безопасных повторов;
- условие окончательного отказа.
Не используйте автоматический повтор для неидемпотентной операции без ключа идемпотентности. Если первый вызов создал объект, а ответ потерялся, второй вызов может создать дубликат. Для файлов применяйте временное имя и атомарную публикацию только после проверки результата. Для внешних API сохраняйте идентификатор попытки и статус вызова.
Проверьте ручное прерывание, обрыв процесса, исчерпание времени и недоступность зависимости. После каждого сценария ответьте на вопросы: какой статус видит оператор, какие файлы остались, можно ли безопасно возобновить задачу и кто отвечает за очистку.
Логи и аудит
Минимальный журнал должен связывать один запрос с полным жизненным циклом Agent:
- идентификатор задачи;
- время начала и завершения;
- версия приложения и окружения;
- входной набор или его безопасный отпечаток;
- выбранный инструмент;
- нормализованные аргументы без секретов;
- результат или тип ошибки;
- созданные артефакты;
- сведения о повторах и отмене;
- решение о финальном статусе.
Документация по запуску и трассировке Agents SDK и описание tracing полезны как ориентир для структуры наблюдаемости. Однако встроенная трассировка не отменяет требований к вашей системе аудита: запрещённые поля нужно маскировать, доступ к журналам ограничивать, а срок хранения согласовать с политикой данных.
Отдельно проверьте стоимость и расход ресурсов. Лимит должен существовать на уровне задачи, очереди и команды: максимальная длительность, разрешённая параллельность, объём входа, объём артефактов и бюджетный сигнал. Конкретные цены не стоит переносить из статьи или старого интерфейса — сверяйте их с актуальной страницей OpenAI и собственной телеметрией. Документация по учёту использования Agents SDK показывает, какие показатели можно собирать для контроля расхода.
Чек-лист приёмки OpenAI Hosted Sandboxes
Ниже — не перечень API-параметров, а рабочий порядок допуска. Пункт можно отметить только тогда, когда у него есть наблюдаемое доказательство: журнал, тестовый артефакт, отказ с ожидаемым кодом или подтверждённая конфигурация.
Подготовительный этап
- [ ] Описана задача и указано, какие действия Agent не имеет права выполнять.
- [ ] Для каждого инструмента назначены минимальные права чтения и записи.
- [ ] Тестовые секреты выпущены отдельно от продуктивных.
- [ ] Проверено отсутствие секретов во входных файлах, prompt и журналах.
- [ ] Определены входные, временные, выходные и служебные каталоги.
- [ ] Зафиксированы runtime, зависимости, точка входа и команда проверки.
- [ ] Описано, какие файлы должны сохраниться после завершения, а какие удаляются.
- [ ] Для сетевого режима есть явный список разрешённых направлений.
- [ ] Для каждой внешней операции определены тайм-аут и безопасный повтор.
Первый запуск
- [ ] Один и тот же тестовый вход запускается из чистого состояния.
- [ ] Проверяется не только код завершения, но и содержимое результата.
- [ ] Полученный артефакт можно скачать и открыть вне среды.
- [ ] После перезапуска понятна судьба временных и постоянных файлов.
- [ ] Ошибка установки зависимости попадает в журнал с причиной.
- [ ] Прерывание процесса не оставляет артефакт, который выглядит готовым.
- [ ] В логах есть связь между запросом, инструментом, результатом и ошибкой.
Серый режим
- [ ] Проверено отсутствие сети.
- [ ] Проверена ограниченная сеть.
- [ ] Проверен отказ внешнего сервиса.
- [ ] Проверен тайм-аут инструмента.
- [ ] Проверена отмена задачи оператором.
- [ ] Проверен повтор после потери ответа.
- [ ] Проверена защита от повторной записи.
- [ ] Проверена очистка неполных файлов.
- [ ] Владелец задачи может найти весь журнал по одному идентификатору.
- [ ] Установлены лимиты длительности, параллельности и расхода.
Таблица решения
| Сценарий | Hosted Sandboxes | Собственная песочница или VPC | Облачный Mac |
|---|---|---|---|
| Одноразовое выполнение кода и файловая обработка | Первый выбор для проверки | Избыточно, если нет чувствительных данных | Обычно не требуется |
| Ограниченный серый запуск | Возможен при секретах, логах и сетевых правилах | Предпочтителен при сложной топологии | Подходит, если нужен Mac-специфичный runtime |
| Доступ к внутренним системам | Только через отдельный контролируемый шлюз | Более естественный вариант | Возможен, но сеть и права нужно проектировать отдельно |
| Чувствительные данные | Только после подтверждения политики хранения и очистки | Часто лучше для полного контроля | Зависит от модели изоляции и доступа |
| Долгоживущее состояние | Не считать гарантированным без подтверждения документацией и тестом | Проще спроектировать самостоятельно | Нужны отдельные правила диска, сессии и резервирования |
| Графические или Mac-зависимые инструменты | Не основной сценарий | Зависит от выбранной инфраструктуры | Практичный вариант |
Матрица Go/No-Go
| Наблюдение при проверке | Решение | Следующее действие |
|---|---|---|
| Код запускается повторно, файлы проверяются, права минимальны | Go для ограниченного запуска | Увеличивать нагрузку постепенно и сохранять аудит |
| Зависимости ставятся случайно или только в прогретой среде | No-Go | Зафиксировать окружение и повторить чистый тест |
| Ошибка внешнего сервиса вызывает повторную запись | No-Go | Добавить идемпотентность, шлюз и ручное подтверждение |
| Секрет появляется в логе или артефакте | No-Go | Отозвать ключ, очистить данные и изменить маскирование |
| Нельзя доказать, что произошло после отмены | No-Go | Добавить события жизненного цикла и проверку очистки |
| Нужны частные маршруты и постоянное состояние | Условный No-Go | Сравнить собственную песочницу и VPC |
| Нужны Mac-инструменты или удалённая среда разработки | Сравнительный выбор | Протестировать облачный Mac по отдельной модели прав |
Решение о переносе и следующий запуск
Не смешивайте четыре разных вопроса: может ли Agent выполнить код, может ли он безопасно получить файл, может ли он обратиться к внешней системе и сможете ли вы расследовать сбой. Hosted Sandboxes могут хорошо отвечать на первый вопрос, но остальные требуют самостоятельной инженерной проверки.
Если ваш текущий путь — локальный Windows или Linux-сервер, его недостатки проявляются при командной работе: окружения расходятся, доступ к машине часто шире необходимого, а удалённый разбор сбоя зависит от конкретного администратора. VPC даёт больше контроля, но требует проектирования сети, секретов, образов и обновлений. Облачный Mac не заменяет изоляцию автоматически, зато может быть удобнее для задач, которым нужны Mac-инструменты, удалённая разработка или воспроизводимое рабочее место.
Для временного тестового Agent, короткого серого запуска и проверки кода Hosted Sandboxes остаются рациональной отправной точкой. Если вам нужен удалённый Mac для проверки локального Agent-потока, можно сравнить аренду Mac mini для разработки и вариант с Mac mini для использования. Для сценариев, где особенно важны разделение секретов и файлов, сначала изучите изоляцию доступа в удалённой Mac-среде, а затем повторите тот же тестовый набор.
Возьмите минимальную задачу, пройдите чек-лист от чистого запуска до искусственного сбоя и сохраните доказательства каждого решения. Если после этого остаются неизвестными судьба файлов, границы сети или последствия повтора, не называйте Agent готовым к эксплуатации: сначала перенесите спорный участок в собственную песочницу, VPC или контролируемую среду Kvmzen и только затем расширяйте доступ.