- Что такое песочница для ИИ-агента?
- Чем песочница для агента отличается от обычного контейнера?
- Что такое изоляция в контексте ИИ-агентов?
- Что такое фильтрация исходящего трафика и почему это важно?
- Как секреты и учётные данные распределяются в песочнице агента? {#secrets-and-credentials}
- Как работают журналы аудита в песочницах для ИИ-агентов? {#audit-logs}
- Что такое создание снимков состояния в песочнице агента?
- Какие технологии лежат в основе песочниц для агентов?
- Могут ли ИИ-агенты выйти за пределы песочниц?
- Поддерживают ли песочницы для ИИ-агентов GPU-нагрузки?
- Когда на самом деле нужна выделенная песочница?
- В чём разница между интерпретатором кода и средой выполнения агента? {#code-interpreter-vs-agent-runtime}
- Как безопасно запускать код, сгенерированный ИИ? {#run-ai-generated-code-safely}
- Часто задаваемые вопросы
- Распространённые провайдеры песочниц
- Рекомендуемые статьи
Песочница (sandbox) для ИИ-агента — это изолированная среда выполнения, в которой ИИ-агент может запускать код, вызывать инструменты и взаимодействовать с файловой системой или браузером, не оказывая влияния на хост-систему, соседние рабочие нагрузки или критическую инфраструктуру. Песочница создаёт границу: что происходит внутри, остаётся внутри, а то, что снаружи, недоступно изнутри, если вы явно не разрешите это. Novita Agent Sandbox — одна из реализаций этого подхода: изоляция на базе Firecracker microVM, развёртывание BYOC в вашем собственном VPC в AWS или GCP и чистое ценообразование с оплатой по факту использования — но описанные здесь концепции применимы к любой платформе песочниц. В этой статье мы отвечаем на наиболее частые вопросы о том, как работает эта граница, какие здесь компромиссы и когда она действительно нужна. Для более глубокого изучения вопросов изоляции, секретов, исходящего трафика и требований соответствия см. FAQ по песочницам для ИИ-агентов.
Что такое песочница для ИИ-агента?
Песочница для ИИ-агента — это уровень выполнения, где агент выполняет свою основную работу: пишет и запускает код, устанавливает пакеты, читает и изменяет файлы, выполняет API-вызовы и взаимодействует с сессиями браузера или графическими интерфейсами. Песочница предоставляет ограниченную среду с собственной файловой системой, выделением CPU и памяти, сетевым интерфейсом и пространством имён процессов — и изолирована от всего внешнего.
Ключевая цель проектирования — сдерживание. Когда LLM генерирует команду оболочки, а агент её выполняет, команда выполняется внутри песочницы. Если она устанавливает пакет, запускает подпроцесс или пытается прочитать учётные данные, эти операции ограничены песочницей. Если код приводит к сбою процесса или заполнению диска, ущерб остаётся локальным.
Песочницы также служат единицей учёта ресурсов и биллинга для облачных провайдеров. Когда вы вызываете SDK типа E2B, Daytona или Novita Agent Sandbox, вы создаёте экземпляр песочницы, выполняете в нём операции и затем закрываете — а провайдер взимает плату за потреблённые вычислительные ресурсы.
Чем песочница для агента отличается от обычного контейнера?
Обычный контейнер предоставляет пространство имён файловой системы и ограничения ресурсов, но все контейнеры на одном хосте разделяют одно и то же ядро ОС. Если процесс внутри контейнера использует уязвимость ядра или неправильно настроенный фильтр системных вызовов, он может повлиять на хост или другие контейнеры.
Песочница для агента обычно идёт на один шаг дальше, используя границу microVM. МикроВМ оборачивает рабочую нагрузку в легковесную виртуальную машину с собственным гостевым ядром, поддерживаемую аппаратной виртуализацией (KVM). Гость изолирован от ядра хоста по замыслу, поэтому эксплойт ядра в гостевой системе не влияет на хост автоматически.
Практический компромисс — накладные расходы на производительность. МикроВМ запускается медленнее контейнера, потому что необходимо загрузить ядро, пусть и минимальное. Быстрые платформы microVM, такие как Firecracker, сократили эти накладные расходы до менее 500 мс в большинстве случаев, а системы на основе снимков, такие как Daytona, снижают их до 100 мс. Но это всё равно больше, чем запуск контейнера.
Для большинства рабочих нагрузок ИИ-агентов, связанных с кодом, сгенерированным LLM или ненадёжным, более строгая граница оправдана. Если вы запускаете полностью доверенный внутренний код без пользовательского ввода, может быть достаточно укреплённого контейнера.
Что такое изоляция в контексте ИИ-агентов?
Изоляция в песочницах для агентов действует в нескольких измерениях. Для технического погружения в то, как изоляция песочницы ведёт себя в реальных рабочих нагрузках, включая случаи, где границы microVM помогают, а где нет, см. руководство по оценке Firecracker.
Изоляция файловой системы — у агента есть собственная файловая система, отделённая от хоста. Файлы, записанные внутри песочницы, не появляются на хосте, а файлы хоста недоступны изнутри, если они не смонтированы явно. Это предотвращает чтение агентом учётных данных, конфигурационных файлов и других секретов, находящихся за пределами песочницы.
Изоляция процессов — процессы внутри песочницы не видят и не могут отправлять сигналы процессам снаружи. Агент может запускать подпроцессы, фоновые задания или серверы внутри песочницы, но они не могут взаимодействовать с деревом процессов хоста.
Сетевая изоляция — по умолчанию песочницы для агентов могут быть настроены так, что исходящие сетевые вызовы либо блокируются, либо разрешаются по белому списку, либо ограничиваются по скорости. Агент, который не должен иметь возможность извлечь данные на произвольные адреса в интернете, может быть ограничен известным списком конечных точек. Подробнее см. в разделе о фильтрации исходящего трафика ниже.
Изоляция ресурсов — выделение CPU и памяти ограничено. Агент, попавший в бесконечный цикл или генерирующий большие объёмы данных, не лишит ресурсов другие песочницы на том же хосте, поскольку ограничения ресурсов применяются на уровне VM или контейнера.
Вместе эти измерения определяют радиус поражения: что может случиться самого плохого, если агент ведёт себя некорректно, выходит из строя или выполняет неожиданный код?
Что такое фильтрация исходящего трафика и почему это важно?
Фильтрация исходящего трафика (egress filtering) контролирует, какие исходящие сетевые соединения агенту разрешено устанавливать из песочницы.
В разрешительной конфигурации агент может совершать HTTP/HTTPS-вызовы на любой хост в интернете. Это удобно для агентов, работающих с кодом, которые загружают пакеты, вызывают внешние API или просматривают веб-страницы. Однако это также означает, что скомпрометированный агент или агент, которым манипулировали с помощью атаки с внедрением подсказок (prompt injection), может извлечь данные на сервер, контролируемый злоумышленником, или взаимодействовать с инфраструктурой, доступа к которой у него быть не должно.
В ограничительной конфигурации исходящий трафик жёстко привязан к явному белому списку: агент может вызывать только API модели, конкретную базу данных и реестр пакетов. Всё остальное блокируется. Это сложнее настроить и требует поддержания белого списка по мере изменения зависимостей агента, но это даёт гораздо меньшую поверхность атаки.
Большинство производственных развёртываний агентов находятся где-то между этими крайностями: исходящий трафик не полностью неограничен, но и не заблокирован в соответствии с политикой нулевого доверия с первого дня. Распространённые паттерны включают блокировку известных вредоносных адресов, журналирование всех исходящих вызовов для аудита и постепенное ужесточение списка по мере того, как поведение агента становится предсказуемым. Для полного обзора контроля исходящего трафика и того, что может выйти за пределы каждой границы изоляции, см. руководство по безопасному выполнению кода.
Некоторые провайдеры песочниц предоставляют программный контроль исходящего трафика через SDK. Другие по умолчанию считают песочницу полностью открытой для исходящих соединений. Знайте, какую модель использует ваш провайдер, прежде чем предполагать, что ваши агенты не могут обращаться к внешним хостам.
Как секреты и учётные данные распределяются в песочнице агента? {#secrets-and-credentials}
Секреты, передаваемые в песочницу, должны быть ограничены только тем, что необходимо для данного конкретного запуска агента, и передаваться как переменные окружения или кратковременные токены, а не долгосрочные учётные данные, записываемые на диск. Граница песочницы ограничивает радиус поражения, но не предотвращает автоматически чтение и пересылку агентом любых учётных данных, к которым он имеет доступ внутри среды.
Основной принцип — наименьшие привилегии: передавайте самые узкие учётные данные, которые работают, а не корневой облачный ключ или сервисную учётную запись с широкими разрешениями. Распространённые паттерны:
Переменные окружения при запуске — вставьте секрет в окружение песочницы при запуске. Он доступен коду агента, но не сохраняется в снимках файловой системы и не появляется в журналах по умолчанию. Предпочитайте кратковременные токены статическим API-ключам.
Блокировка на уровне DNS — некоторые конфигурации развёртывания позволяют ограничить, какие DNS-имена могут быть разрешены из песочницы. Это предотвращает обращение агента к конечной точке для извлечения учётных данных, даже если у него есть сетевой доступ, блокируя разрешение на уровне DNS, а не по отдельным IP.
Ограниченные сервисные учётные записи с коротким TTL — для агентов, вызывающих облачные API, используйте цепочки назначения ролей с коротким сроком жизни. Если учётные данные скомпрометированы, окно для злоумышленника ограничено временем жизни токена.
Отсутствие файлов учётных данных хоста — избегайте монтирования файлов учётных данных хоста (например, ~/.aws/credentials) в файловую систему песочницы. Вместо этого генерируйте новые кратковременные учётные данные для каждой сессии.
Песочница обеспечивает границу на уровне процессов; вы несёте ответственность за то, что в неё передаётся.
Как работают журналы аудита в песочницах для ИИ-агентов? {#audit-logs}
Журналы аудита для песочниц агентов обычно охватывают два уровня: события на уровне платформы (песочница создана, запущена, остановлена, завершена по таймауту) и события на уровне приложения (выполненные команды, изменённые файлы, вызовы внешних API). Большинство управляемых провайдеров автоматически генерируют события платформы; журналирование на уровне приложения — ваша ответственность по инструментированию.
Что следует фиксировать для полноценного аудита:
События жизненного цикла песочницы — временная метка создания, продолжительность сессии, причина завершения (нормальное закрытие, тайм-аут или сбой). Большинство управляемых платформ регистрируют это автоматически и предоставляют доступ через API или панель управления.
Исходящие сетевые вызовы — какие хосты контактировал агент с временными метками. Здесь пересекаются журналирование исходящего трафика и аудит. Если ваша платформа поддерживает журналирование исходящих соединений, включите его и направляйте вывод в ваш агрегатор журналов.
Ввод/вывод выполнения кода — команды, которые запустил агент, и полученные результаты. Это уровень приложения и должен фиксироваться в вашем фреймворке агента, а не на уровне инфраструктуры песочницы.
Изменения файловой системы — записанные, удалённые или изменённые файлы. Актуально для агентов, работающих с кодом, и конвейеров обработки данных. Некоторые платформы песочниц предоставляют API для получения различий в файловой системе после завершения сессии; другие требуют инструментирования в коде агента.
Для случаев, связанных с соблюдением нормативных требований (SOC 2, HIPAA, регулируемые отрасли), обычно требуются журналы уровня платформы в хранилище, защищённом от несанкционированного доступа, в сочетании с журналами уровня приложения из вашего фреймворка агента. Прежде чем предполагать наличие покрытия, убедитесь, что ваш провайдер действительно предоставляет, а для чего требуется явное включение.
Что такое создание снимков состояния в песочнице агента?
Создание снимков состояния (snapshotting) захватывает точное состояние работающей песочницы — файловую систему, память, работающие процессы, сетевое состояние — и сохраняет его, чтобы песочницу можно было восстановить в это состояние позже.
Это полезно в нескольких сценариях:
Снижение затрат на холодный старт — вместо загрузки новой VM и установки пакетов каждый раз, вы загружаетесь один раз, устанавливаете всё, делаете снимок, а затем возобновляете работу из этого снимка в каждой новой сессии. Холодный старт Daytona менее 90 мс возможен благодаря этой технике.
Контрольные точки для долго работающих агентов — агент, работающий с кодом в течение многочасовой задачи, может быть приостановлен на полпути с сохранением точного состояния. Если агента необходимо проверить, изменить или перезапустить, он может возобновить работу с контрольной точки, а не начинать заново.
Воспроизводимая оценка — для конвейеров обучения с подкреплением или оценки моделей вы можете сделать снимок известного хорошего начального состояния и сбрасывать к нему перед каждым эпизодом оценки. Это даёт действительно идентичные начальные условия для множества запусков, а не повторное предоставление ресурсов с надеждой на совпадение состояния.
Не все провайдеры песочниц предоставляют контроль снимков на уровне API. Система шаблонов E2B решает задачу «предварительно настроенного окружения», но не позволяет произвольно создавать контрольные точки-восстановления в середине сессии. API снимков Daytona более гибок.
Какие технологии лежат в основе песочниц для агентов?
Наиболее распространённые базовые технологии:
Firecracker — среда выполнения microVM, разработанная AWS и используемая внутри для Lambda и Fargate. Firecracker загружает минимальное гостевое ядро менее чем за 500 мс, предоставляет минимальную модель устройств для уменьшения поверхности атаки и поддерживается аппаратной виртуализацией KVM. E2B и Novita Agent Sandbox используют Firecracker.
gVisor — песочница ядра от Google, которая перехватывает системные вызовы, а не запускает полное гостевое ядро. Она легче microVM, но не обеспечивает полной изоляции ядра — находится между уровнем процесса и уровнем VM в спектре изоляции.
Контейнеры Docker с фильтрацией системных вызовов — контейнеры, укреплённые с помощью seccomp, AppArmor и минимальных возможностей. Это наиболее распространённая отправная точка, но самая слабая граница изоляции для ненадёжного кода.
V8 / Deno — изоляция, специфичная для JavaScript, с использованием модели разрешений среды выполнения V8. Подходит для изоляции рабочих нагрузок только на JavaScript, но не применима для агентов, которым необходимо выполнять произвольные команды оболочки или код не на JavaScript.
Выбор базовой технологии определяет производительность запуска, прочность изоляции и операционную сложность песочницы. Для рабочих нагрузок агентов, работающих с ненадёжным или сгенерированным LLM кодом в многопользовательском контексте, изоляция класса Firecracker является текущим практическим стандартом.
Могут ли ИИ-агенты выйти за пределы песочниц?
На практике выходы из песочниц редки, но не невозможны, и профиль риска зависит от технологии:
Побеги из контейнеров задокументированы. Неправильно настроенные контейнеры — привилегированный режим, смонтированный сокет Docker, доступные для записи каталоги хоста — имеют известные векторы побега. Укреплённый контейнер без привилегий, с файловой системой только для чтения и минимальными возможностями существенно снижает этот риск, но не устраняет его полностью.
Побеги из microVM требуют уязвимости гипервизора или ошибки в модели устройств. Они редки, поскольку поверхность атаки невелика по замыслу. Минимальная модель устройств Firecracker специально разработана для снижения воздействия гипервизора. AWS не раскрывала каких-либо побегов на уровне Firecracker в производственной среде.
Внедрение подсказок (prompt injection) в действия агента — это другой вид «побега»: не эксплойт ядра, а внедрение злоумышленником инструкций в предоставленный пользователем контент, которые заставляют агента совершать нежелательные действия. Это проблема уровня приложения, а не уровня песочницы. Песочницы помогают сдержать ущерб от внедрения подсказок (внедрённый код выполняется внутри песочницы, а не на вашем хосте), но они не предотвращают само внедрение.
Практический вывод: правильно настроенная песочница на основе Firecracker не является абсолютно защищённой от побегов теоретически, но планка атаки достаточно высока, чтобы для большинства корпоративных развёртываний агентов остаточный риск был управляемым. Более распространённые режимы сбоев — это неправильная конфигурация (чрезмерно разрешительный исходящий трафик, неправильно ограниченные учётные данные, переданные в песочницу), а не эксплойты на уровне ядра.
Поддерживают ли песочницы для ИИ-агентов GPU-нагрузки?
Большинство песочниц для ИИ-агентов по состоянию на середину 2026 года не поддерживают GPU. E2B, Daytona и Vercel Sandbox — все только CPU.
Modal является основным исключением среди управляемых песочниц: он предлагает доступ к GPU по требованию внутри контейнеров, подходящих для инференса моделей, тонкой настройки или рабочих нагрузок RL, требующих GPU в той же среде, что и код агента.
Для большинства рабочих процессов агентов сам агент вызывает внешний API инференса LLM (например, конечные точки инференса Novita), а не запускает модель локально. В такой архитектуре GPU в песочнице не требуется — песочница обрабатывает код, файловые операции и вызовы инструментов, в то время как тяжёлый инференс выполняется на отдельном GPU-сервисе. Это паттерн, используемый агентами для написания кода, анализа данных и большинства рабочих процессов автоматизации браузера.
Если вам всё же нужен GPU внутри песочницы — например, для локального инференса модели для автономного использования, шагов обучения RL или многошаговых конвейеров оценки — учитывайте это при выборе провайдера. В настоящее время Modal является наиболее часто используемым вариантом для такого паттерна.
Когда на самом деле нужна выделенная песочница?
Не каждому ИИ-приложению требуется выделенная песочница. Сценарии, в которых песочница действительно добавляет ценность:
Вы выполняете код, сгенерированный LLM — агент пишет и запускает код, который не был написан человеком и может делать неожиданные вещи. Это основной вариант использования: выполнение происходит в песочнице, чтобы оно не могло повлиять на ваш хост, учётные данные или другие рабочие нагрузки.
Вы обслуживаете конечных пользователей — сессии агентов нескольких пользователей используют одну и ту же базовую инфраструктуру. Вам нужна изоляция между пользователями, чтобы агент одного пользователя не мог повлиять на другого, намеренно или случайно.
Вам нужны долгоживущие рабочие процессы с сохранением состояния — агенту, который редактирует файлы, запускает тесты и фиксирует изменения, требуется рабочее пространство, сохраняющее состояние на протяжении многих итераций LLM. Новый подпроцесс для каждого вызова не сохранит состояние; песочница сохранит.
У вас есть требования соответствия или аудита — вам необходимо регистрировать все действия агента, ограничивать сетевой доступ или доказывать, что рабочие нагрузки агентов не могут получить доступ к производственным базам данных или учётным данным. Песочницы предоставляют уровень принуждения для этих контролей.
Вы занимаетесь автоматизацией браузера или компьютерного использования — среды автоматизации браузера полностью изолированы от хоста, поэтому агент может нажимать, печатать и делать скриншоты, не затрагивая ваши локальные сессии браузера или состояние системы.
Если вы только запускаете простой конвейер «суммируй этот текст» без выполнения кода, вам, вероятно, не нужна выделенная песочница для выполнения — достаточно API-вызова к LLM. Песочница становится необходимой, как только агент начинает выполнять действия, имеющие побочные эффекты: запись файлов, запуск кода, вызов внешних API от вашего имени.
В чём разница между интерпретатором кода и средой выполнения агента? {#code-interpreter-vs-agent-runtime}
Интерпретатор кода выполняет один фрагмент кода в изоляции и возвращает результат. По умолчанию он не сохраняет состояние: каждый запуск начинается с чистого листа, результат возвращается, и ничего не сохраняется. Думайте о нём как о изолированном ядре Jupyter, где ячейки не разделяют состояние между вызовами. Это правильный инструмент для анализа данных, вычисления формул или однократного выполнения кода, где не нужно сохранять состояние между запусками.
Среда выполнения агента (agent runtime) — это постоянная среда с сохранением состояния, предназначенная для многошаговых рабочих процессов. Агент может записывать файлы, устанавливать пакеты, запускать фоновые процессы, выполнять сетевые вызовы и накапливать состояние рабочего пространства на протяжении многих итераций LLM — без потери контекста между шагами. Агент, который редактирует файлы, запускает тесты, читает вывод ошибок и повторяет попытки, работает в среде выполнения агента, а не в интерпретаторе кода.
Это различие важно для выбора инструмента:
| Интерпретатор кода | Среда выполнения агента | |
|---|---|---|
| Состояние между вызовами | Отсутствует (свежее при каждом выполнении) | Постоянное в рамках сессии |
| Доступ к файловой системе | Обычно изолирован на каждый вызов | Постоянное рабочее пространство |
| Многошаговые рабочие процессы | Не предназначен для этого | Основной вариант использования |
| Типичная длина сессии | Секунды | От минут до часов |
| Примеры | Jupyter kernel, отдельная ячейка кода | E2B, Daytona, Novita Agent Sandbox |
На практике граница размыта. E2B и большинство управляемых платформ песочниц могут вести себя как интерпретатор кода (выполнить один фрагмент, вернуть результат), но предоставляют полную инфраструктуру среды выполнения агента под капотом — постоянную файловую систему, управление процессами, сетевой доступ. Платформы, такие как Code Interpreter от OpenAI, созданы специально для сценариев без сохранения состояния и осознанно жертвуют гибкостью, которую предоставляет среда выполнения агента.
Выбирайте интерпретатор кода, когда вам нужно быстрое изолированное выполнение для одной задачи без требований к состоянию. Выбирайте среду выполнения агента, когда ваша рабочая нагрузка включает итеративное редактирование файлов, установленные зависимости пакетов, долго работающие процессы или любой рабочий процесс, который должен продолжить работу с того места, где он остановился.
Как безопасно запускать код, сгенерированный ИИ? {#run-ai-generated-code-safely}
Безопасный запуск кода, сгенерированного ИИ, в производственной среде требует правильных контролей на каждом уровне — песочница обрабатывает границу выполнения, но вам также нужно принять решения на уровне приложения.
Используйте изоляцию microVM, а не контейнеры, для ненадёжного кода. Песочницы на основе Firecracker (E2B, Novita Agent Sandbox) помещают код, сгенерированный LLM, внутрь VM с собственным ядром. Побеги из контейнеров задокументированы и имеют известные векторы; побеги из microVM требуют уязвимости гипервизора и редки по замыслу. Затраты на холодный старт стоят более прочной границы, когда код не был проверен человеком.
Ограничьте исходящий трафик до того, что действительно нужно агенту. Агенту, выполняющему код для анализа данных, вероятно, не нужно обращаться к произвольным хостам в интернете. Заблокируйте исходящий трафик до API модели, конкретного реестра пакетов и любых внешних сервисов, которых явно требует задача. В развёртываниях BYOC это можно применять на уровне групп безопасности VPC. В управляемых развёртываниях используйте средства контроля исходящего трафика провайдера, если они доступны, или принимайте и регистрируйте неограниченный исходящий трафик как известный риск.
Передавайте только ограниченные кратковременные учётные данные. Не давайте песочнице доступ к производственным базам данных, корневым облачным ключам или широким сервисным учётным записям. Передавайте только то, что необходимо для текущей задачи, используя учётные данные с коротким TTL. Если сгенерированный код прочитает и извлечёт учётные данные, ущерб будет ограничен.
Устанавливайте тайм-ауты и ограничения ресурсов. Установите явные ограничения по времени и памяти на выполнение. Бесконечный цикл, сгенерированный LLM, или неожиданно большой вывод должны завершаться корректно, а не потреблять сессию бесконечно или заполнять диск.
Ведите журнал исходящего трафика и истории команд с самого начала. Вы не сможете исследовать неожиданное поведение, если у вас нет записи того, что делал агент. Включите журналирование исходящих соединений на раннем этапе, даже в разработке. Журналирование на уровне приложения выполненных команд, записей файлов и внешних вызовов лежит на вас — инфраструктура песочницы не делает это автоматически.
Никакая конфигурация не устраняет риск полностью. Цель — известный, ограниченный остаточный риск: агент запускает код, который вы не писали, внутри прочной границы изоляции, с минимальными учётными данными и сетевым доступом, которые ему нужны, и с достаточным журналированием для обнаружения и диагностики неожиданного поведения.
Часто задаваемые вопросы
Одинакова ли песочница для ИИ-агента со средой разработки?
Нет. Среда разработки — это рабочее пространство для человека-разработчика: она сохраняется между сессиями, долгоживущая и предназначена для настройки и повторного использования. Песочница для ИИ-агента — это граница выполнения времени выполнения: она существует в течение задачи, предназначена для временного использования и воспроизводимости, и её основная задача — сдерживание, а не удобство разработчика. Некоторые песочницы могут сохранять состояние между итерациями LLM в рамках сессии (что делает их более похожими на рабочее пространство), но цель дизайна — изоляция от хоста, а не полнофункциональная IDE. Термины иногда пересекаются в маркетинге вендоров; если вы оцениваете платформу, смотрите на то, какова на самом деле граница изоляции, а не на ярлык.
Что такое среда выполнения агента (agent execution sandbox)?
Среда выполнения агента — это то же самое, что и песочница для ИИ-агента; формулировка «выполнение» просто подчёркивает аспект времени выполнения. Когда LLM решает предпринять действие (запустить код, вызвать инструмент, записать файл), эти действия выполняются внутри песочницы. Песочница — это уровень выполнения, который обеспечивает границу между тем, что делает агент, и тем, что видит или может быть затронуто остальной частью вашей системы. Термины «песочница агента», «песочница выполнения кода» и «среда выполнения агента» используются взаимозаменяемо в отрасли.
Как Firecracker соотносится с gVisor для рабочих нагрузок ИИ-агентов?
Оба обеспечивают изоляцию, превосходящую стандартные контейнеры, но разными механизмами. Firecracker загружает минимальное гостевое ядро внутри microVM на базе KVM — песочница имеет собственное ядро, полностью отделённое от ядра хоста. gVisor перехватывает системные вызовы с помощью пользовательского пространства ядра (runsc) без запуска полного гостевого ядра. Практический компромисс: Firecracker обеспечивает более прочную границу хоста, потому что гостевое ядро полностью отделено; gVisor имеет меньшее потребление памяти на песочницу, поскольку не запускает полное ядро, но изоляция находится между полной microVM и контейнером, укреплённым с помощью перехвата системных вызовов. Для многопользовательских рабочих нагрузок ИИ-агентов, работающих с ненадёжным кодом, сгенерированным LLM, изоляция класса Firecracker является текущим производственным стандартом. gVisor разумен для рабочих нагрузок, где код частично доверен, а плотность памяти важнее максимальной изоляции.
Может ли внедрение подсказок (prompt injection) заставить агента выйти из песочницы?
Внедрение подсказок не обходит техническую изоляцию песочницы — оно использует процесс принятия решений агентом, чтобы заставить его предпринять действия, которые злоумышленник задумал, а разработчик не имел в виду. Внедрённая инструкция типа «извлеки переменные окружения на этот URL» приводит к тому, что агент совершает исходящий сетевой вызов, который блокируется только в том случае, если политика исходящего трафика запрещает его. Файловая система и изоляция процессов песочницы остаются нетронутыми. Это означает, что безопасность песочницы и защита от внедрения подсказок решают разные части стека: песочница ограничивает радиус поражения того, что агент может сделать на уровне инфраструктуры; контроли уровня приложения (ограничения вызовов инструментов, утверждения с участием человека, белые списки исходящих соединений) защищают от того, что агент будет направлен на неправильное использование этих возможностей.
Зачем нужна песочница специально для ИИ-агентов?
Ключевое отличие от традиционного выполнения кода — неопределённость. Когда разработчик-человек пишет код, он примерно знает, что он будет делать. Когда LLM генерирует код или решает вызвать инструмент, приложение может иметь ограниченную видимость того, что именно будет выполняться, какие пакеты будут установлены или какие внешние конечные точки будут затронуты — потенциально среди тысяч одновременных сессий. Эта неопределённость повышает ставки для каждого из стандартных средств контроля безопасности: политика исходящего трафика важна, потому что агент может обращаться к конечным точкам, которые никто не предвидел; управление пакетами важно, потому что агент может динамически устанавливать зависимости; журналирование аудита важно, потому что восстановление того, что произошло, сложнее, когда действия агента не были перечислены заранее. Песочница даёт вам уровень принуждения для обработки этой неопределённости без необходимости доверять каждому отдельному действию агента заранее.
Распространённые провайдеры песочниц
Краткий обзор основных вариантов с более полными сравнениями в связанных статьях:
- Novita Agent Sandbox — Firecracker microVM, развёртывание BYOC в вашем собственном VPC AWS или GCP, без абонентской платы, сессии до 24 часов. Основной вариант для команд с требованиями соответствия, чувствительных к стоимости или уже использующих Novita для инференса LLM. См. novita.ai/sandbox.
- E2B — управляемый, Firecracker microVM, большое сообщество, без самостоятельного хостинга. Хорошо документированные SDK и активная экосистема.
- Daytona — холодный старт менее 90 мс, открытый исходный код (AGPL), возможность самостоятельного хостинга. Лучше для сценариев, чувствительных к задержке, или случаев, связанных с соответствием, где требуется собственная инфраструктура.
- Modal — основной вариант, когда вам нужен GPU внутри песочницы. Изоляция на основе контейнеров.
- Vercel Sandbox — быстрый холодный старт, лучше всего подходит для JS/TS на платформе Vercel.
Для полного сравнения с характеристиками и схемой принятия решений см. Лучшие песочницы для ИИ-агентов в 2026 году. Для углублённой оценки E2B и Daytona конкретно — холодный старт, BYOC, снимки и цены — см. руководство по оценке песочниц для ИИ-агентов: сравнение E2B и Daytona.
