Как настроить сетевой доступ OpenAI Hosted Sandboxes? Руководство по безопасному развёртыванию Agent 2026

Если Agent видит файлы, но не может скачать пакет или вызвать API, не расширяйте сеть вслепую. Самое быстрое решение — сначала оставить Hosted Sandbox без сети, затем открыть только проверенный выход; для приватного API, базы данных или внутреннего сервиса заранее оцените самоуправляемую среду или контролируемый шлюз.

Кому нужен этот разбор

Эта статья предназначена независимым разработчикам, которые переводят кодовый Agent из демонстрационного сценария в повторяемые задания.

Она полезна инженерам AI-приложений, которым нужно устанавливать зависимости, читать и изменять файлы, вызывать бизнес-API, а также платформенным инженерам, отвечающим за сеть, ключи, рабочие каталоги и аудит.

Здесь настройка сети OpenAI Hosted Sandboxes рассматривается не как набор параметров, а как задача выбора границ доступа. Документация OpenAI подтверждает сценарии Linux-рабочего пространства, обработки файлов, выполнения кода и конфигурирования зависимостей, но конкретные сетевые возможности и параметры среды необходимо сверять с актуальными официальными материалами по Sandbox Agent.

Сначала классифицируйте задачу, а не открывайте интернет

У внешнего сетевого доступа есть цена, которая не ограничивается оплатой трафика. Он расширяет поверхность атаки, делает результат зависимым от DNS и доступности стороннего сервиса, усложняет воспроизводимость и позволяет ошибке Agent обратиться не к тому адресу. Поэтому перед настройкой ответьте на вопрос: что именно должна получить программа из сети?

Локальная обработка файлов

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

Преимущества такого режима:

• меньше направлений для утечки данных;
• проще повторить задание с тем же набором файлов;
• легче доказать, что Agent не отправлял содержимое наружу;
• меньше причин для случайного изменения результата из-за внешнего сервиса.

Ограничение очевидно: новые библиотеки, удалённые модели и справочные API не будут доступны. Это не недостаток конфигурации, а граница выбранного режима.

Установка библиотек и системных инструментов

Если задача требует Python-модуля, пакета Node.js или системной утилиты, не следует давать модели право самостоятельно выбирать произвольное зеркало, версию и команду установки. Подготовку лучше выполнять до основного задания через заранее проверенный setup command или другой поддерживаемый механизм конфигурации, описанный в документации Sandbox Agents.

Здесь сеть нужна не «вообще», а для конкретного этапа жизненного цикла:

• подготовить окружение;
• получить разрешённые зависимости;
• выполнить задачу;
• закрыть или ограничить последующие обращения.

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

Публичный API

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

Открывайте только необходимые хосты и методы, если текущая среда это позволяет. Если точный список направлений нельзя надёжно выразить средствами Hosted Sandbox, используйте промежуточный сервис, который сам проверяет адрес, метод, размер запроса и тип ответа.

Приватный API, база данных и внутренний webhook

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

Для такого класса задач приоритет обычно выглядит так:

• Hosted Sandbox без прямого доступа к внутренней сети;
• контролируемый backend-прокси с узким набором операций;
• самоуправляемый runner или облачное рабочее пространство с полной настройкой сети;
• прямой доступ к бизнес-сервису только после отдельного threat model и теста разрешений.

Как связаны рабочий каталог, зависимости и сеть

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

В конфигурации проверьте четыре независимых слоя.

Рабочий каталог. Зафиксируйте, где лежат входные файлы, куда записываются временные результаты и какой каталог можно выгружать после завершения. Не делайте корень файловой системы рабочей областью задачи. Чем шире каталог, тем сложнее доказать, что Agent не прочитал посторонний файл.

Среда выполнения. Уточните доступный интерпретатор, менеджер пакетов и команды подготовки. Python, Node.js и системная утилита не являются взаимозаменяемыми зависимостями. Установка Python-пакета не создаёт команду операционной системы, а npm-пакет не гарантирует наличие нужной версии Node.js.

Команды запуска. Разделите подготовку и пользовательское задание. В setup-разделе должны находиться фиксированные действия: установка конкретных зависимостей, проверка версий, создание каталогов и подготовка конфигурации без секретов. Модель может выбрать алгоритм обработки данных, но не должна каждый раз менять базовый стек.

Сетевой этап. Для каждой команды укажите, нужен ли ей выход. Установка зависимостей, вызов внешнего API и передача результата в webhook — разные действия. Не объединяйте их в одну широкую команду, если можно разделить разрешения и журналы.

Минимальная проверка готовности должна подтверждать не только факт создания среды:

• импортируется нужный Python-модуль;
• команда Node.js возвращает ожидаемую версию;
• системная утилита находится в разрешённом пути;
• файл из рабочего каталога читается;
• тестовый сетевой вызов обращается к нужному адресу;
• результат записывается в каталог артефактов.

В официальном руководстве по клиентам Sandbox отдельно проверьте актуальные способы создания и управления средой. Имена интерфейсов, состояние окружения и поля конфигурации нельзя переносить из старого примера без повторной проверки.

Важно: успешное создание Sandbox не доказывает, что зависимость установлена, DNS работает, TLS доверен, а Agent получил нужный credential. Каждое из этих утверждений должно подтверждаться отдельной наблюдаемой проверкой.

Как подключать API и секреты без прямой выдачи модели

Безопасная архитектура начинается с разделения ролей. Agent решает, какую разрешённую операцию вызвать. Прокси проверяет аргументы, добавляет секрет и обращается к сервису. Сервис возвращает нормализованный результат. В такой схеме модель не получает постоянный ключ и не обязана знать внутренний адрес.

Публичный сервис через прокси

Прокси должен принимать структурированный запрос, а не произвольный URL. На входе полезно проверять:

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

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

Внутренняя система

Для CRM, базы данных или внутреннего webhook лучше выдавать не универсальный API-ключ, а короткоживущий credential с минимальным набором действий. Например, отдельный endpoint может разрешать получить статус задачи, но не выполнять произвольный SQL или изменять справочники.

Секреты нельзя помещать в prompt, текстовый файл, shell-команду, имя артефакта или отладочный вывод. Следите также за исключениями: многие библиотеки автоматически выводят URL с параметрами, заголовки или тело запроса при ошибке. Перед передачей журналов инженеру применяйте маскирование.

Вызов инструмента должен иметь отказоустойчивый контракт. Если API вернул HTTP 401, это обычно проблема авторизации или срока действия credential; HTTP 403 указывает на запрет, но не доказывает, что сеть недоступна; HTTP 429 требует обработки ограничения частоты; ошибка TLS относится к проверке соединения, а не к правам пользователя. Эти состояния нельзя сводить к одной подсказке «повторите запрос».

Подход OpenAI к инструментам и агентным вызовам меняется вместе с SDK, поэтому перед реализацией проверяйте актуальную документацию инструментов Agents SDK. Для рабочих систем полезно отдельно фиксировать версию SDK и тестировать контракт после обновления, а не считать совместимость автоматической.

Порядок диагностики сетевого сбоя

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

Сбой создания окружения. Проверьте конфигурацию рабочей области, команды подготовки, доступность выбранного runtime и итоговое состояние Sandbox. Если среда не перешла в готовое состояние, тестировать DNS и API преждевременно.

Соединение отклонено или заблокировано. Сопоставьте адрес и порт с разрешённой политикой. Убедитесь, что Agent не сгенерировал другой hostname, добавил редирект или использовал прокси, которого нет в конфигурации. Сохраните команду и фактический адрес без секретов.

Ошибка DNS. Разделите неправильное имя, отсутствие маршрута к корпоративному DNS и временную недоступность резолвера. Проверяйте имя из самой Sandbox, а не только с ноутбука разработчика: разные среды могут использовать разные DNS-правила.

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

Ошибка авторизации. Сравните область действия credential, срок жизни, нужный HTTP-метод и заголовки. Ключ, действующий на локальном компьютере, не обязательно разрешён для прокси или конкретного endpoint.

Зависимость не устанавливается. Зафиксируйте имя пакета, версию, источник, команду и весь безопасный вывод установки. Проверьте, не пытается ли менеджер пакетов скачать платформенный бинарник, который не поддерживается текущим Linux-окружением. Если пакет нужен постоянно, вынесите установку из динамического решения Agent.

Тайм-аут. Сначала установите, где он произошёл: DNS, TLS, прокси, внешний API или обработка результата. Уменьшите размер тестового запроса, задайте ограничение времени и проверьте, не повторяет ли Agent одну операцию без идемпотентного идентификатора.

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

FAQ: частые вопросы о Hosted Sandbox

Доступен ли интернет по умолчанию?

Не используйте предположение о свободном интернете как основу архитектуры. Проверьте актуальную политику Hosted Sandbox и подтвердите её минимальным сетевым тестом. Если задание не требует внешнего источника, оставьте сеть закрытой. При необходимости доступа сначала задайте конкретный маршрут или вынесите вызов в прокси, который можно наблюдать и ограничивать.

Как установить Python, Node.js и системные пакеты?

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

Какой способ подходит для внешнего API?

Для публичного API допустим ограниченный выход при наличии проверки адреса, метода, размера запроса и ответа. Для внутреннего сервиса используйте backend-прокси или самоуправляемый runner. Базовая модель — Agent выбирает операцию, а не URL и credential. Так вы сохраняете контроль над маршрутом, журналом и отзывом доступа.

Как защитить API Key?

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

Как отличить сетевую блокировку от ошибки Agent?

Повторите минимальный запрос с теми же параметрами вне модельного цикла и сравните адрес, метод, статус и время ответа. Если простой тест проходит, исследуйте сформированные Agent аргументы. Если он не проходит, проверяйте DNS, TLS, маршрут и политику выхода. Без сохранения версии среды и команды эти причины легко перепутать.

Что проверить перед запуском в рабочем контуре

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

• Сеть закрыта, если внешние вызовы не входят в задачу.
• Для разрешённого выхода определены конкретные направления, методы и ограничения времени.
• Рабочий каталог содержит только необходимые файлы.
• Каталог результатов отделён от временных данных и конфигурации.
• Версии Python, Node.js, системных пакетов и SDK зафиксированы либо контролируемо обновляются.
• Команды подготовки не получают секреты через открытый текст.
• Credential имеет минимальные права и ограниченный срок действия.
• Логи очищаются от ключей, заголовков, токенов и чувствительного тела запроса.
• Ответ внешнего сервиса проверяется до того, как Agent использует его в следующем действии.
• Внешний webhook и база данных не доступны через произвольный URL.
• Сбой одного запроса не запускает бесконечный цикл повторов.
• Артефакты перед выгрузкой проверяются на секреты и лишние файлы.
• Есть процедура отзыва ключа и повторного запуска задания.

Если вам нужна дополнительная проверка архитектуры или помощь с границами удалённой среды, можно использовать раздел справки kvmboot. Для длительных задач, которым нужны постоянный рабочий каталог, собственные маршруты, фоновые процессы или физические инструменты, заранее сравните Hosted Sandbox с управляемым облачным рабочим пространством.

Как выбрать среду для конкретного типа задачи

У этой таблицы нет универсального победителя. Настройка сети OpenAI Hosted Sandboxes рациональна, когда изолированный запуск, короткий жизненный цикл и ограниченный набор файлов важнее постоянного состояния. Если же задача зависит от частной сети и долгоживущих данных, расширение Hosted Sandbox может оказаться менее управляемым, чем самоуправляемая среда с отдельным шлюзом.

Дерево решения перед выдачей доступа

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

• Если задача работает только с переданными файлами — выбирайте запрет сети; при ошибке установки переносите подготовку зависимостей в этап создания среды.
• Если нужен пакет из публичного источника — выбирайте ограниченный подготовительный выход, фиксируйте версию и проверяйте импорт; если источник нельзя ограничить, используйте заранее подготовленную среду.
• Если нужен публичный API — выбирайте прокси или минимальный разрешённый маршрут; если сервис требует произвольных перенаправлений, не выдавайте прямой доступ Agent.
• Если нужен приватный API или база данных — выбирайте контролируемый backend-прокси; если операция требует постоянного сетевого присутствия и нескольких внутренних сегментов, переходите к самоуправляемой среде.
• Если задача должна работать долго, сохранять состояние и принимать фоновые события — выбирайте облачное рабочее пространство с управляемой сетью; если достаточно короткого запуска и выгружаемого результата, оставайтесь в Hosted Sandbox.
• Если вы не можете получить наблюдаемый тест доступа, версии зависимости и безопасный журнал — не переводите сценарий в рабочий контур.

Когда облачное рабочее пространство практичнее Hosted Sandbox

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

Текущая альтернатива — собственная виртуальная среда или облачный Mac — тоже не бесплатна с точки зрения эксплуатации: вам придётся самим управлять обновлениями, SSH или удалённым доступом, firewall, резервными копиями, секретами и очисткой рабочих каталогов. При этом прямой контроль над сетью и долгоживущим состоянием может быть важнее компактности Sandbox.

Если вы выбираете облачную среду через kvmboot, заранее зафиксируйте требуемую операционную систему, способ удалённого подключения, правила выдачи ключей и срок хранения данных; описание сервиса и доступных вариантов можно сверить на странице о kvmboot. Для временного тестирования такой путь часто удобнее, чем расширять права краткоживущего Agent. Для постоянной тяжёлой нагрузки, строгих требований к физическим интерфейсам или полностью изолированной корпоративной сети аренда тоже может не подойти — тогда оправдана собственная инфраструктура.

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