Песочницы для кода от ИИ: зачем изолировать вывод модели и чем отличаются E2B, Vercel Sandbox, Modal и Daytona
Написать черновик подсказки для большой языковой модели относительно просто; сложнее безопасно исполнять то, что она выдала, если рядом лежат ваши данные и секреты. На Dev.to разработчик alexcloudstar объясняет, почему для агентов и автогенерации кода нужна отдельная производственная песочница, и сопоставляет четыре облачных контура — E2B, Vercel Sandbox, Modal и Daytona — с позиции 2026 года: что действительно меняется при выборе платформы.
Материал вышел 1 мая 2026 года (UTC); ниже — пересказ тезисов публикации с опорой на первоисточник, без претензии заменить оригинал.
От удачного промпта до опасного запуска
Развёрнутая мотивация начинается с личного кейса: автоматический агент выполнял код на сервере с недостаточно ограниченной оболочкой и доступом к смонтированным dotfiles. Агент смог «увидеть» путь и удалить каталог во временной зоне (tmp) с незавершённым скриптом. Для практики с ИИ-агентами это сводится к резкому выводу: если код модели предполагается гонять автоматически, отдельная песочница — не опция, а условие.
Здесь же подчёркивается контраст: дать модели написать код легче, чем безопасно пропустить его исполнение на машине, которая имеет доступ к вашим данным. Перечислены классы рисков при «доверчивом» локальном запуске — от prompt injection через результат tool и typosquat зависимости до бесконечных циклов нагрузки, рекурсивных shell-сценариев и утечек через «вежливые» комментарии в коде. По оценке того же материала, подобное уже случалось у команд, выкатывавших продукты с агентами примерно за восемнадцать месяцев до момента повествования; спасало то, что исполнение было там, где не могло навредить критичному контуру.
Параллель с пайплайном сборки: уровень внимания к контейменту должен быть тот же, что для пользовательского кода в build pipeline; новизна в том, что агенты ИИ названы крупнейшим источником недоверенного кода во многих приложениях с агентами, а модель безопасности команд часто ещё не обновлена под этот поток.
Что считать «настоящей» песочницей для кода модели
Одиночный Docker с настройками по умолчанию, chroot или Linux-пользователь без sudo в исходном тексте отнесены к недостаточным мерам против целенаправленного скрипта: они снижают ущерб от ошибок, но не от злого умысла.
Порог безопасности сформулирован так: по возможности изоляция аппаратного уровня — microVM или сильно изолированный контейнер; файловая система эфемерная; сеть выключена или работает по whitelist; нет скрытого пути к хосту без явного открытия; время жизни — минуты или часы; после уничтожения среды ничего не остаётся, кроме того, что передано через контролируемый канал.
Код, который выдала модель, в этой рамке трактуется как недоверенный: его нельзя исполнять на хосте с доступом к секретам, базам, произвольной файловой системе или сети владельца — только во временном окружении с минимумом возможностей и последующим уничтожением.
Четыре готовых продукта и различие задач
На старте 2026 года в обсуждаемой публикации зафиксировано: есть не менее четырёх production-уровневых вариантов для выполнения по требованию недоверенного кода плюс низкоуровневые примитивы для самостройки; они не взаимозаменимы — различие про масштаб, экономику и blast radius.
E2B
E2B описан как один из первых продуктов, где песочничное исполнение похоже на вызов SDK, а не отдельный infra-проект: клиент, создание песочницы через API, запуск, чтение результата.
Технология — Firecracker microVM, записываемая ФС, настраиваемый lifetime; предустановлены Python, Node и типичный набор инструментов. Сильная сторона — опыт разработчика: потоковый stdout, монтирование файлов, возможность держать песочницу между ходами агента и убрать её в конце; упоминаются и персистентные песочницы для сессий с зависимостями и промежуточным состоянием.
Минусы в тексте завязаны на экономику: при тысячах параллельных песочниц в продукте ощущаются цена и unit economics — считать нужно до обещаний пользователям. Модель доверия — код на инфраструктуре третьей стороны; для клиентов с жёсткими ограничениями на вынос данных self-hosted возможен, но тот же текст относит этот путь к «не самым дешёвым».
Итоговый акцент: хорош для ранней стадии и прототипирования sandbox-фичи — быстрее прийти к работающему агенту.
Vercel Sandbox
Выведение в GA в январе 2026; это тоже Firecracker microVM, встроенная в тот же контур проекта, деплоя и биллинга, что и функции. Сценарий: порождение из Function или routing middleware, исполнение, возврат результата; lifetime — до нескольких часов; оплата укладывается в существующий compute budget.
Ключевой акцент — интеграция: без второго аккаунта, второго стека секретов и раздельной observability. Ограничения: не для долгого обучения ML и не для тяжёлого GPU; расчёт на минуты исполнения, а не часы inference. Продукт назван самым молодым из четырёх: API хорош, но «длинный хвост» граничных случаев ещё заполняется.
Если приложение уже на Vercel, для исполнения кода этот вариант назван дефолтным; упоминается связка Fluid Compute и Sandbox как разделение доверенного и недоверенного исполнения.
Modal
Modal позиционируется как ответ для нагрузок тяжелее, чем «классический» code-execution sandbox: путь от serverless Python для ML к сильным sandbox-примитивам; модель — serverless runtime для произвольного кода против «удалённого shell для агента» (декораторы задают среду, ресурсы, lifetime; Modal отвечает за provisioning, масштаб и teardown).
Плюсы: GPU, долгоживущие задачи, тома между запусками; если агент генерирует код под реальные вычисления — нативно, остальным из списка сложнее. Минусы: платформа сильнее задаёт рамки продуктового «мнения»; открытый REPL возможен, но не главный фокус; цены «реальные» — нужна cost model до масштабирования.
Daytona
Подход описан как dev-environment-as-a-service: workspace с редакторским слоем, файловой системой, терминалом и настраиваемой сетевой политикой; это не one-shot sandbox, а сессионный «дом» агента для кода, тестов, итераций и итогового diff; lifetime дольше, среда богаче.
Подчёркивается применимость к сценарию репозитория: клонирование, тесты, правки, pull request. Есть перекрёстная ссылка на материал DEV про инструменты AI code review — без разбора его содержания в этой подборке.
Ценовая модель отнесена ближе к «месту разработчика», чем к счётчику вызовов функций: при тысячах коротких задач в день может не сойтись; при десятках долгих сессий — может быть экономически разумной.
Своя сборка и почему четыре продукта — не заглушка
В 2026 перечисленные четыре решения названы теми, которые автор статьи реально рассматривал бы; roll your own — если жёсткие требования к резидентности данных и комплаенсу; если нагрузка слишком специфична; если модель безопасности требует полного контроля над инфраструктурой (например, self-hosted Firecracker в своём VPC). Упоминаются открытый Firecracker и gVisor. Аналогия: строить свою песочницу в 2026 — как строить свой auth в 2018 для большинства команд.
Операционные меры и паттерны для агентов
Независимо от вендора перечислены практики: по возможности закрыть исходящий трафик по умолчанию и открыть только нужные хосты (типичный вектор — curl с полезной нагрузкой из переменных окружения); монтировать тома read-only или с ограниченной записью; не класть секреты в окружение песочницы — вызывать граничный сервис; задавать явные лимиты CPU, памяти, времени и диска; логировать команды и вывод для отладки недетерминированных агентов; держать агрессивные lifetimes и помнить, что долгоживущие persistent-песочницы удобны, но расширяют поверхность атаки. Есть отсылка к отдельному материалу DEV про observability агентов в продакшене — здесь без пересказа того поста.
Из того же опыта выведены паттерны: одна песочница на пользователя, а не общая между пользователями (риск утечек; платить cold start); по возможности передавать модели план, а не давать ей самой открывать соединение с базой там, где можно выполнить структурированный запрос на своей стороне; артефакты сохранять через явный инструмент в контролируемое хранилище; поэтапно включать сеть после узкой стадии без неё; валидировать каждый результат tool как вектор prompt injection.
Дерево выбора и чем заканчивается история
В финале приведено явное дерево: на Vercel и задача — исполнение кода → Vercel Sandbox; не на Vercel, нужен code execution и «самый гладкий SDK» → E2B; вычислительный workload, CPU/GPU/долгие задачи → Modal; нужна поверхность «как у разработчика в workspace» → Daytona; если среда выполнения по политике должна жить только на вашей инфраструктуре → свой Firecracker и принятие операционных затрат. Ключевая мысль повторяется: гонять недоверенный код в своих контейнерах на хостах, которые имеют доступ к вашим данным, — неверный ответ для сценария «код от модели на каждый ход для каждого пользователя».
Инцидент из начала датируется как полтора года раньше относительно момента написания; вывод — инструменты догнали проблему: sandboxing AI-generated code в 2026 описан как решённая задача в смысле «можно купить готовое», но внедрение и политика всё равно остаются на команде. Отмечается сближение agent frameworks и sandbox-примитивов и ожидание более дешёвой совместной statefulness (warm pools, общие базовые образы); Fluid Compute приводится как пример переиспользования инстансов. Политика вида «агент может X, не может Y» пока не унифицирована между рантаймами и в материале названа ещё прототипируемой.
Там же есть ссылки на материалы DEV о рисках безопасности AI-generated code — как указание на связанную линию обсуждений, без подмены ими основного сюжета.
Источники
- alexcloudstar. Sandboxing AI-Generated Code: E2B vs Vercel Sandbox vs Modal vs Daytona in 2026 — Dev.to. URL: Dev.to — дата публикации записи: 2026-05-01T07:37:26Z; дата доступа к странице при верификации: 2026-05-02 (UTC).