Варианты песочниц для AI-агентов с открытым исходным кодом: что проверить перед самостоятельным развёртыванием

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

Что считается песочницей для AI-агента?

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

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

Для оценки разделите четыре уровня:

Уровень	Что определяет	Почему это важно
Фреймворк агента	Как модель планирует, вызывает инструменты и реагирует на результаты	Хороший фреймворк автоматически не создаёт безопасную среду выполнения
Среда выполнения песочницы	Где выполняются команды, файлы, сессии браузера и процессы	Это основная граница изоляции и жизненного цикла
Плоскость политик	Что песочница может читать, загружать, устанавливать, открывать или сохранять	Определяет, соответствует ли песочница вашей модели рисков
Плоскость проверки	Какие логи, diffs, артефакты и утверждения доступны после выполнения	Определяет, может ли человек проверить произошедшее

Варианты с самостоятельным размещением и открытым исходным кодом могут дать командам больше контроля над этими уровнями. Они также возлагают больше ответственности на команду, которая их эксплуатирует.

Когда самостоятельное развёртывание имеет смысл?

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

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

Используйте самостоятельное развёртывание, если верно хотя бы одно из этих утверждений:

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

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

Варианты песочниц с открытым исходным кодом для оценки

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

Вариант	Что проверить в первую очередь	Вопрос по самостоятельному развёртыванию
E2B	Компоненты песочницы/среды выполнения с открытым кодом, SDK, шаблоны и позиционирование песочницы на базе Firecracker	Какие части открыты, какие режимы развёртывания поддерживаются сегодня и какая операционная работа остаётся вашей команде?
Daytona	Инфраструктура рабочих пространств и песочниц для разработки и сценариев использования AI-агентов, с открытыми репозиториями и документацией по самостоятельному хостингу	Соответствует ли его модель рабочего пространства, API-интерфейс и архитектура развёртывания вашей нагрузке агента и политике безопасности?
OpenHands	Платформа для агентов с документированной архитектурой среды выполнения, использующая изолированные среды для выполнения действий агента	Вы внедряете полную платформу агента или только заимствуете паттерн среды выполнения?
SWE-ReX	Интерфейс среды выполнения с открытым кодом, используемый в исследованиях и оценочных рабочих процессах агентов программной инженерии	Подходит ли его абстракция для ваших производственных нужд или в основном полезна для контролируемых оценочных стендов?
Modal Sandbox	Управляемый API песочницы, а не среда выполнения с открытым кодом для самостоятельного хостинга	Полезен как точка сравнения эргономики API, выполнения процессов, файловой системы и поведения таймаутов, но не как вариант для самостоятельного хостинга

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

Граница изоляции: контейнеры, microVM и полноценные виртуальные машины

Первый вопрос не «это безопасно?». Полезный вопрос: «Какова граница изоляции?»

Контейнеры привлекательны, потому что они быстры, знакомы и легко собираются на основе образов Docker. Они подходят для доверенных внутренних задач, CI-подобных работ, краткосрочного анализа и рабочих процессов разработки, где модель угроз умеренная. Но контейнеры разделяют ядро хоста, поэтому командам, работающим с недоверенным кодом или многопользовательскими нагрузками, необходимо оценить доступ к ядру, профили seccomp/AppArmor, пространства имён пользователей, смонтированные тома, привилегированный режим и реакцию на побег.

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

Полноценные виртуальные машины могут подойти для более строгих корпоративных сред, автоматизации рабочего стола или рабочих процессов, которым требуется более широкая поверхность ОС. Компромисс — более тяжёлый запуск, управление образами и планирование ёмкости.

Задайте эти вопросы перед самостоятельным размещением:

Проверка	Что проверить
Граница ядра	Разделяет ли песочница ядро с другими нагрузками или каждая сессия получает отдельное ядро?
Граница клиентов	Могут ли две сессии разных клиентов разделять ресурсы на уровне хоста, тома, кэши, профили браузера или сетевые пространства имён?
Модель привилегий	Запускает ли песочница привилегированные контейнеры, root-пользователей, смонтированные Docker-сокеты или пути хоста?
Постура при побеге	Как патчатся и развёртываются уязвимости ядра, среды выполнения, контейнера и гипервизора?
Контроль ресурсов	Принуждаются ли ограничения на CPU, память, диск, количество процессов, открытых файлов и время выполнения для каждой сессии?
Побочные каналы	Требует ли ваша модель рисков смягчения для общего CPU, кэша, диска или поведения «шумного соседа»?

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

Состояние, файлы и жизненный цикл рабочего пространства

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

Начните с жизненного цикла:

1. Создание песочницы из базового образа или шаблона.
2. Монтирование или клонирование разрешённого рабочего пространства.
3. Выполнение команд настройки в соответствии с политикой.
4. Выполнение агентом команд, действий в браузере и операций с файлами.
5. Извлечение результатов: diff, логи, скриншоты, отчёты или загруженные файлы.
6. Остановка, приостановка, создание снимка, архивирование или уничтожение песочницы.

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

Перед самостоятельным размещением определите:

• Получает ли каждая задача агента свежую файловую систему.
• Являются ли кэши пакетов общими, ограниченными или пересобираемыми.
• Сохраняются ли профили браузера между запусками.
• Копируются, монтируются или передаются ли пользовательские загрузки.
• Включают ли снимки секреты, токены, куки или внутренние логи.
• Как долго хранятся логи и артефакты.
• Кто может возобновить приостановленную сессию.

Хорошая песочница делает жизненный цикл по умолчанию скучным. Вы должны уметь объяснить, что существует до начала задачи, что меняется во время задачи и что остаётся после очистки.

Сеть, пакеты и политика исходящего трафика

Сетевой доступ — это то, где многие дизайны песочниц становятся расплывчатыми. Агентам часто нужен интернет, но «доступ в интернет» — это не одно разрешение.

Программирующему агенту могут понадобиться реестры пакетов, публичная документация, удалённые Git-репозитории и URL для предварительного просмотра. Браузерному агенту могут понадобиться тестовое приложение, staging API и хранилище скриншотов. Агенту данных могут понадобиться объектное хранилище, реплика базы данных или ограниченный SaaS API. Это разные разрешения с разными рисками.

Используйте категории:

Тип исходящего трафика	Типичная потребность	Вопрос политики
Реестры пакетов	npm, pip, apt, cargo, зависимости моделей/инструментов	Белые списки, кэширование, сканирование и логирование?
Публичный веб	Поиск документации, задачи в браузере, сбор публичных данных	Разрешён ли произвольный просмотр, проксируется ли, есть ли ограничение скорости и аудит?
Git-доступ	Клонирование репозиториев, отправка веток, получение подмодулей	Токены только для чтения, где это возможно, и ограничены задачей?
Внутренние API	Staging-сервисы, тестовые приложения, частные зеркала пакетов	Ограничен ли доступ окружением, сервисом, маршрутом и учётными данными?
Предварительный просмотр (входящий)	Просмотр человеком локальных веб-приложений или сгенерированных отчётов	Какой порт открыт, кому, как долго и с какой аутентификацией?
Вебхуки	Обратные вызовы агента, события CI, интеграция внешних инструментов	Может ли песочница отправлять исходящие обратные вызовы на произвольные хосты?

Политика пакетов заслуживает особого внимания. Многие задачи агентов не выполняются без установки зависимостей, но установка пакетов приносит post-install-скрипты, нативные бинарники, риск компрометации реестра, риск typo-squatting и долгое время жизни кэша. Предпочитайте установку на основе lock-файлов, одобренные реестры, токены с коротким сроком жизни и логи установки.

Для самостоятельно развёрнутых систем также решите, кто отвечает за DNS-логи, конфигурацию прокси, хранилища сертификатов и реагирование на сетевые инциденты.

Секреты, логи и аудиторские следы

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

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

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

Логирование должно быть достаточно детальным для проверки и реагирования на инциденты:

• Запрошенные, одобренные, отклонённые и выполненные команды.
• Рабочая директория, код возврата, stdout, stderr, таймаут и использование ресурсов.
• Файловые артефакты, созданные задачей.
• Сетевые назначения с детализацией, поддерживаемой вашей политикой.
• Имена пакетов, версии, реестры и вывод установки.
• Решения по редактированию секретов и сбои редактирования.
• Утверждения человеком для рискованных действий.

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

Сброс, снимки и риск мультитенантности

Поведение сброса — это производственная функция, а не скрипт очистки в конце демонстрации.

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

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

• Установленные пакеты и кэши.
• Историю команд или состояние процессов.
• Куки браузера, локальное хранилище и загрузки.
• Временные файлы и сгенерированные результаты.
• Учётные данные или конфигурационные файлы.
• Логи предыдущих задач.

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

Доступ разработчиков и пути отладки

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

Полезные пути отладки включают:

• Способ воспроизвести команды из того же базового образа.
• Структурированные логи выполнения команд и вызовов инструментов.
• Загружаемые артефакты и скриншоты.
• Явные ошибки таймаута и превышения лимитов ресурсов.
• Контролируемый способ для разработчика подключиться к живой сессии, если политика разрешает.
• Версионированные шаблоны или образы, чтобы сбои можно было привязать к версии окружения.
• Чёткое разделение между выводом, видимым пользователю, и внутренними логами среды выполнения.

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

Где подходит Novita Agent Sandbox

Novita Agent Sandbox — это управляемая среда выполнения для агентов для выполнения кода, автоматизации браузера, рабочих процессов в стиле computer-use, анализа данных, оценок и длительных рабочих процессов агентов. Документация Novita Agent Sandbox описывает хранящую состояние среду песочницы с SDK и CLI для управления жизненным циклом, командами, файлами, сессиями браузера и связанными примитивами рабочих процессов.

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

Держите границу чёткой:

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

Не рассматривайте ни одно имя провайдера как гарантию безопасности. Относитесь к этому как к выбору среды выполнения, который всё равно требует архитектурного анализа.

Контрольный список для самостоятельного развёртывания

Используйте этот контрольный список перед перемещением песочницы для AI-агента с открытым кодом в продакшн.

Область	Минимальный вопрос перед продакшном
Изоляция	Является ли граница контейнером, microVM, полноценной VM или чем-то ещё, и достаточно ли этого для нагрузки?
Рабочее пространство	Начинается ли каждая задача с известного состояния файловой системы, и можно ли её сбросить?
Сохранение состояния	Явные ли пауза, возобновление, снимки и хранение, а не случайные?
Сеть	Контролируются ли отдельно загрузка пакетов, просмотр веб-страниц, вызовы API, Git, вебхуки и входящий превью?
Пакеты	Управляются ли lock-файлы, реестры, post-install-скрипты, нативные бинарники и кэши?
Секреты	Ограничены ли учётные данные задачей, редактируются ли, ротируются ли и недоступны ли для несвязанных команд?
Логи	Может ли проверяющий восстановить команды, результаты, изменения файлов, сетевые пути и утверждения?
Мультитенантность	Поняты ли совместное использование хоста, совместное использование кэша, очистка диска, квоты и поведение «шумного соседа»?
Отладка	Могут ли инженеры воспроизвести сбои, не обходя модель безопасности?
Эксплуатация	Кто патчит образы, среды выполнения, ядра, зависимости и контроллеры песочниц?
Контроль злоупотреблений	Применяются ли таймауты, лимиты ресурсов, лимиты скорости и пути принудительного завершения?
Путь выхода	Можно ли экспортировать и проверить артефакты, даже если песочница вылетает или истекает по таймауту?

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

FAQ

Какая песочница для AI-агента с открытым исходным кодом лучшая?

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

Достаточно ли Docker для песочницы AI-агента?

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

Безопаснее ли microVM, чем контейнеры для нагрузок агентов?

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

Что следует протестировать перед самостоятельным размещением песочницы агента?

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

Когда следует использовать управляемую песочницу вместо самостоятельного размещения?

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

Рекомендуемые статьи

• Запуск Codex или программирующего агента в безопасной песочнице
• Как песочницы агентов обеспечивают безопасную и масштабируемую инновацию AI
• Создание программирующего агента с помощью песочницы агента Novita