- Что такое песочница для ИИ-агента?
- Чем песочница агента отличается от обычного контейнера?
- Что такое изоляция в контексте ИИ-агентов?
- Что такое фильтрация исходящего трафика и почему это важно?
- Что такое создание снимков состояния в песочнице агента?
- Какие технологии лежат в основе песочниц агентов?
- Могут ли ИИ-агенты выйти из песочницы?
- Поддерживают ли песочницы ИИ-агентов графические процессоры (GPU)?
- Когда вам действительно нужна выделенная песочница?
- Часто задаваемые вопросы
- Распространенные провайдеры песочниц
- Рекомендованные статьи
Песочница для ИИ-агента — это изолированная среда выполнения, в которой ИИ-агент может запускать код, вызывать инструменты и взаимодействовать с файловой системой или браузером, не имея возможности повлиять на хост-систему, соседние рабочие нагрузки или чувствительную инфраструктуру. Песочница создает границу: что происходит внутри, остается внутри, а то, что снаружи, недоступно изнутри, если вы явно этого не разрешите. Novita Agent Sandbox — одна из реализаций такого подхода: изоляция на основе microVM Firecracker, развертывание BYOC в вашем собственном VPC в AWS или GCP и чистая оплата по мере использования, — но концепции, описанные здесь, применимы к любой платформе песочниц. Эта статья отвечает на наиболее частые вопросы о том, как работает эта граница, какие есть компромиссы и когда она действительно нужна. Более подробные ответы на вопросы об изоляции, секретах, исходящем трафике и требованиях соответствия см. в FAQ по песочницам ИИ-агентов.
Что такое песочница для ИИ-агента?
Песочница для ИИ-агента — это уровень выполнения, на котором ИИ-агент выполняет свою реальную работу: пишет и запускает код, устанавливает пакеты, читает и изменяет файлы, выполняет API-вызовы и взаимодействует с сеансами браузера или графическими интерфейсами рабочего стола. Песочница предоставляет ограниченную среду с собственной файловой системой, выделением CPU и памяти, сетевым интерфейсом и пространством имен процессов — и она изолирована от всего внешнего.
Ключевая цель дизайна — сдерживание. Когда LLM генерирует команду оболочки, а агент ее выполняет, команда запускается внутри песочницы. Если она устанавливает пакет, запускает подпроцесс или пытается прочитать учетные данные, эти операции ограничены песочницей. Если код приводит к сбою процесса или заполняет диск, ущерб остается локальным.
Песочницы также служат единицей учета ресурсов и биллинга для облачных провайдеров. Когда вы вызываете SDK, например E2B, Daytona или Novita Agent Sandbox, вы создаете экземпляр песочницы, выполняете в нем операции, а затем закрываете его — и провайдер взимает плату в зависимости от потребленных вычислительных ресурсов.
Чем песочница агента отличается от обычного контейнера?
Обычный контейнер предоставляет пространство имен файловой системы и ограничения ресурсов, но все контейнеры на одном хосте используют одно и то же ядро ОС. Если процесс внутри контейнера использует уязвимость ядра или неправильно настроенный фильтр системных вызовов, он потенциально может повлиять на хост или другие контейнеры.
Песочница агента обычно идет на шаг дальше, используя границу microVM. MicroVM помещает рабочую нагрузку в легковесную виртуальную машину с собственным гостевым ядром, поддерживаемую аппаратной виртуализацией (KVM). Гость изолирован от ядра хоста по дизайну, поэтому эксплойт ядра в гостевой системе не влияет автоматически на хост.
Практическим компромиссом является накладные расходы на производительность. MicroVM запускается медленнее, чем контейнер, потому что необходимо загрузить ядро, даже минимальное. Быстрые платформы microVM, такие как Firecracker, сократили эти накладные расходы до менее 500 мс в большинстве случаев, а системы на основе снимков, такие как Daytona, снижают их до менее 100 мс. Но это все равно больше, чем запуск контейнера.
Для большинства рабочих нагрузок ИИ-агентов, включающих код, сгенерированный LLM или ненадежный, более сильная граница оправдана. Если вы запускаете полностью доверенный внутренний код без пользовательского ввода, может быть достаточно усиленного контейнера.
Что такое изоляция в контексте ИИ-агентов?
Изоляция в песочницах агентов работает в нескольких измерениях. Для технического углубленного анализа того, как изоляция песочницы работает при реальных нагрузках, включая то, где границы microVM помогают, а где нет, см. руководство по оценке Firecracker.
Изоляция файловой системы — у агента есть собственная файловая система, отдельная от хостовой. Файлы, записанные внутри песочницы, не появляются на хосте, а файлы хоста недоступны изнутри, если они не смонтированы явно. Это предотвращает чтение агентом учетных данных, конфигурационных файлов или других секретов, находящихся вне песочницы.
Изоляция процессов — процессы внутри песочницы не могут видеть или отправлять сигналы процессам снаружи. Агент может запускать подпроцессы, фоновые задания или серверы внутри песочницы, но они не могут взаимодействовать с деревом процессов хоста.
Сетевая изоляция — по умолчанию песочницы агентов можно настроить так, чтобы исходящие сетевые вызовы были заблокированы, разрешены по белому списку или ограничены по скорости. Агент, который не должен иметь возможность извлекать данные на произвольные интернет-адреса, может быть ограничен известным списком конечных точек. Подробнее см. в разделе о фильтрации исходящего трафика ниже.
Изоляция ресурсов — выделение CPU и памяти ограничено. Агент, попавший в бесконечный цикл или генерирующий большие объемы данных, не будет “голодать” другие песочницы на том же хосте, поскольку ограничения ресурсов применяются на уровне ВМ или контейнера.
Эти измерения вместе определяют радиус поражения: что может произойти в худшем случае, если агент поведет себя неправильно, выйдет из строя или выполнит неожиданный код?
Что такое фильтрация исходящего трафика и почему это важно?
Фильтрация исходящего трафика контролирует, какие исходящие сетевые соединения агент может устанавливать изнутри песочницы.
В разрешительной конфигурации агент может совершать HTTP/HTTPS-вызовы к любому хосту в интернете. Это удобно для агентов-программистов, которые загружают пакеты, вызывают внешние API или просматривают веб-страницы. Однако это также означает, что скомпрометированный агент или агент, подвергшийся атаке с внедрением промпта, может извлечь данные на сервер, контролируемый злоумышленником, или взаимодействовать с инфраструктурой, до которой ему не следует добираться.
В ограничительной конфигурации исходящий трафик заблокирован явным белым списком: агент может вызывать только API модели, определенную базу данных и реестр пакетов. Все остальное отбрасывается. Это сложнее настроить и требует поддержания белого списка по мере изменения зависимостей агента, но это дает гораздо меньшую поверхность атаки.
Большинство производственных развертываний агентов находятся где-то между этими крайностями: исходящий трафик не полностью неограничен, но и не заблокирован белым списком с первого дня. Распространенные шаблоны включают блокировку известных вредоносных адресов, регистрацию всех исходящих вызовов для аудита и постепенное ужесточение списка по мере того, как поведение агента становится предсказуемым. Полный обзор контроля исходящего трафика и того, что все еще может обойти каждую границу изоляции, см. в руководстве по безопасному выполнению кода.
Некоторые провайдеры песочниц предоставляют программный контроль исходящего трафика через SDK. Другие по умолчанию оставляют исходящий трафик полностью открытым. Знайте, какую модель использует ваш провайдер, прежде чем предполагать, что ваши агенты не могут связаться с внешними хостами.
Что такое создание снимков состояния в песочнице агента?
Создание снимков состояния (snapshotting) захватывает точное состояние работающей песочницы — файловую систему, память, запущенные процессы, сетевое состояние — и сохраняет его, чтобы песочницу можно было восстановить в это состояние позже.
Это полезно в нескольких сценариях:
Снижение затрат на холодный старт — вместо того чтобы каждый раз загружать новую ВМ и устанавливать пакеты, вы загружаетесь один раз, устанавливаете все, делаете снимок, а затем возобновляете работу с этого снимка для каждого нового сеанса. Холодный старт Daytona менее 90 мс возможен именно благодаря этой технике.
Сохранение контрольных точек для долго работающих агентов — агент-программист, работающий над многочасовой задачей, может быть приостановлен на полпути с сохранением точного состояния. Если агента нужно проверить, изменить или перезапустить, он может возобновить работу с контрольной точки, а не начинать заново.
Воспроизводимая оценка — для конвейеров обучения с подкреплением или оценки моделей вы можете создать снимок известного хорошего начального состояния и сбрасывать к нему перед каждым эпизодом оценки. Это дает действительно идентичные начальные условия для многих запусков, а не повторное выделение ресурсов с надеждой, что состояние совпадет.
Не все провайдеры песочниц предоставляют управление снимками на уровне API. Шаблонная система E2B обрабатывает сценарий “предустановленная среда”, но не дает произвольного восстановления с контрольной точки в середине сеанса. API снимков Daytona более гибок.
Какие технологии лежат в основе песочниц агентов?
Наиболее распространенные базовые технологии:
Firecracker — среда выполнения microVM, разработанная AWS, используется внутри для Lambda и Fargate. Firecracker загружает минимальное гостевой ядро за менее чем 500 мс, использует минимальную модель устройств для уменьшения поверхности атаки и поддерживается аппаратной виртуализацией KVM. E2B и Novita Agent Sandbox используют Firecracker.
gVisor — песочница ядра, разработанная Google, которая перехватывает системные вызовы, а не запускает полноценное гостевой ядро. Она легче, чем microVM, но не обеспечивает полной изоляции ядра — она находится между процессом и ВМ в спектре изоляции.
Docker-контейнеры с фильтрацией системных вызовов — контейнеры, усиленные seccomp, AppArmor и минимальными возможностями. Это самая распространенная отправная точка, но самая слабая граница изоляции для ненадежного кода.
V8 / Deno — изоляция для JavaScript с использованием модели разрешений среды выполнения V8. Подходит для изоляции рабочих нагрузок только на JavaScript, но не применима для агентов, которым нужно запускать произвольные команды оболочки или код не на JS.
Выбор базовой технологии определяет производительность запуска, силу изоляции и операционную сложность песочницы. Для рабочих нагрузок агентов, запускающих ненадежный или сгенерированный LLM код в мультитенантном контексте, изоляция класса Firecracker является современным практическим стандартом.
Могут ли ИИ-агенты выйти из песочницы?
На практике побеги из песочницы редки, но не невозможны, и профиль риска зависит от технологии:
Побеги из контейнера задокументированы. Неправильно настроенные контейнеры — привилегированный режим, смонтированный Docker-сокет, доступные для записи каталоги хоста — имеют известные векторы побега. Усиленный контейнер без привилегий, с корневой файловой системой только для чтения и минимальными возможностями значительно снижает этот риск, но не устраняет его.
Побеги из microVM требуют уязвимости гипервизора или ошибки в модели устройств. Они редки, потому что поверхность атаки мала по дизайну. Минимальная модель устройств Firecracker специально разработана для снижения воздействия на гипервизор. AWS не раскрыла ни одного случая побега из Firecracker в производственной среде.
Внедрение промпта в действия песочницы — это другой вид “побега”: не эксплойт ядра, а внедрение злоумышленником инструкций в предоставленный пользователем контент, что заставляет агента совершать действия, которые он не должен. Это проблема уровня приложения, а не песочницы. Песочницы помогают сдержать ущерб от внедрения промпта (внедренный код выполняется внутри песочницы, а не на вашем хосте), но они не предотвращают само внедрение.
Практический вывод: хорошо настроенная песочница на основе Firecracker теоретически не является защищенной от побега, но планка атаки достаточно высока, чтобы для большинства корпоративных развертываний агентов остаточный риск был управляемым. Более распространенные сценарии отказов — это неправильная конфигурация (чрезмерно разрешительный исходящий трафик, неправильно ограниченные учетные данные, передаваемые в песочницу), а не эксплойты на уровне ядра.
Поддерживают ли песочницы ИИ-агентов графические процессоры (GPU)?
Большинство песочниц ИИ-агентов по состоянию на середину 2026 года не включают поддержку GPU. E2B, Daytona и Vercel Sandbox — все только на CPU.
Modal является основным исключением в сфере управляемых песочниц — он предлагает доступ к GPU по требованию внутри контейнеров, подходящий для инференса моделей, тонкой настройки или рабочих нагрузок с подкреплением, требующих GPU в той же среде, что и код агента.
Для большинства рабочих процессов агентов сам агент вызывает внешний API инференса LLM (например, конечные точки инференса Novita), а не запускает модель локально. В такой архитектуре GPU в песочнице не нужен — песочница обрабатывает код, файловые операции и вызовы инструментов, в то время как тяжелый инференс выполняется на отдельном сервисе GPU. Этот шаблон используется агентами-программистами, агентами анализа данных и большинством рабочих процессов автоматизации браузера.
Если вам действительно нужен GPU внутри песочницы — например, локальный инференс модели для автономного использования, шаги обучения с подкреплением или многоэтапные конвейеры оценки — учитывайте это при выборе провайдера. Modal в настоящее время является наиболее часто используемым вариантом для этого шаблона.
Когда вам действительно нужна выделенная песочница?
Не каждое приложение ИИ нуждается в выделенной песочнице. Сценарии, в которых песочница добавляет реальную ценность:
Вы выполняете код, сгенерированный LLM — агент пишет и запускает код, который не был написан человеком и может сделать неожиданные вещи. Это основной вариант использования: выполнение происходит в песочнице, чтобы оно не могло повлиять на ваш хост, учетные данные или другие рабочие нагрузки.
Вы обслуживаете конечных пользователей — запуски агентов разных пользователей используют одну и ту же базовую инфраструктуру. Вам нужна изоляция между пользователями, чтобы агент одного пользователя не мог повлиять на другого, намеренно или случайно.
Вам нужны долго работающие рабочие процессы с сохранением состояния — агенту-программисту, который редактирует файлы, запускает тесты и совершает коммиты, требуется рабочее пространство, которое сохраняется между многими вызовами LLM. Новый подпроцесс для каждого вызова не сохранит состояние; песочница сохранит.
У вас есть требования соответствия или аудита — вам нужно регистрировать все действия агента, ограничивать сетевой доступ или доказывать, что рабочие нагрузки агента не могут получить доступ к производственным базам данных или учетным данным. Песочницы предоставляют уровень принудительного применения этих средств контроля.
Вы занимаетесь автоматизацией браузера или компьютера — среды автоматизации браузера полностью изолированы от хоста, поэтому агент может нажимать, печатать и делать скриншоты, не влияя на ваши локальные сеансы браузера или состояние системы.
Если вы запускаете только простой пайплайн “резюмируй этот текст” без выполнения кода, вам, вероятно, не нужна выделенная песочница для выполнения — достаточно API-вызова к LLM. Песочница становится необходимой, как только агент начинает совершать действия, имеющие побочные эффекты: запись файлов, запуск кода, вызов внешних API от вашего имени.
Часто задаваемые вопросы
Одинаковы ли песочница ИИ-агента и среда разработки?
Нет. Среда разработки — это рабочее пространство для разработчика-человека: она сохраняется между сеансами, является долгоживущей и предназначена для настройки и повторного использования. Песочница ИИ-агента — это граница выполнения во время исполнения: она существует на время выполнения задачи, предназначена для эфемерности и воспроизводимости, и ее основная задача — сдерживание, а не комфорт разработчика. Некоторые песочницы могут сохранять состояние между вызовами LLM в рамках одного сеанса (что делает их более похожими на рабочее пространство), но цель дизайна — изоляция от хоста, а не полнофункциональная IDE. Термины иногда пересекаются в маркетинге поставщиков; если вы оцениваете платформу, смотрите на то, какова на самом деле граница изоляции, а не на ярлык.
Что такое песочница выполнения агента?
Песочница выполнения агента — это то же самое, что и песочница ИИ-агента — формулировка “выполнение” просто подчеркивает аспект времени выполнения. Когда LLM решает выполнить действие (запустить код, вызвать инструмент, записать файл), эти действия выполняются внутри песочницы. Песочница — это уровень выполнения, который обеспечивает границу между тем, что делает агент, и тем, что может видеть или на что может влиять остальная часть вашей системы. Термины “песочница агента”, “песочница выполнения кода” и “среда выполнения агента” используются взаимозаменяемо в индустрии.
Как Firecracker сравнивается с gVisor для рабочих нагрузок ИИ-агентов?
Оба обеспечивают изоляцию, выходящую за рамки стандартных контейнеров, но с помощью разных механизмов. Firecracker загружает минимальное гостевой ядро внутри microVM на основе KVM — песочница имеет собственное ядро, полностью отделенное от ядра хоста. gVisor перехватывает системные вызовы с помощью пользовательского ядра (runsc), не запуская полноценное гостевой ядро. Практический компромисс: Firecracker обеспечивает более сильную границу хоста, потому что гостевой ядро полностью отделено; gVisor имеет меньшие накладные расходы памяти на песочницу, потому что не запускает полное ядро, но изоляция находится между полноценной microVM и контейнером, усиленным перехватом системных вызовов. Для мультитенантных рабочих нагрузок ИИ-агентов, запускающих ненадежный код, сгенерированный LLM, изоляция класса Firecracker является современным производственным стандартом. gVisor разумен для рабочих нагрузок, где код частично доверенный и важна плотность памяти больше, чем максимальная изоляция.
Может ли внедрение промпта заставить агента выйти из его песочницы?
Внедрение промпта не обходит техническую изоляцию песочницы — оно использует процесс принятия решений агентом для выполнения действий, которые задумал злоумышленник, но не предусмотрел разработчик. Внедренная инструкция, например “извлеки переменные окружения на этот URL”, заставляет агента совершать исходящий сетевой вызов, который блокируется только в том случае, если политика исходящего трафика это предотвращает. Файловая система и изоляция процессов песочницы остаются нетронутыми. Это означает, что безопасность песочницы и защита от внедрения промпта решают разные части стека: песочница ограничивает радиус поражения того, что агент может сделать на уровне инфраструктуры; средства контроля на уровне приложения (ограничения вызовов инструментов, утверждение с участием человека, белый список исходящих соединений) защищают от того, чтобы агент был направлен на неправомерное использование этих возможностей.
Зачем нужна песочница специально для ИИ-агентов?
Ключевое отличие от традиционного выполнения кода — неопределенность. Когда разработчик-человек пишет код, он примерно знает, что этот код будет делать. Когда LLM генерирует код или решает вызвать инструмент, у приложения может быть ограниченная видимость того, что именно будет выполняться, какие пакеты будут установлены или какие внешние конечные точки будут затронуты — потенциально в тысячах параллельных сеансов. Эта неопределенность повышает ставки для каждого из стандартных средств безопасности: политика исходящего трафика важна, потому что агент может достичь конечных точек, которых никто не ожидал; управление пакетами важно, потому что агент может динамически устанавливать зависимости; регистрация аудита важна, потому что восстановить события сложнее, когда действия агента не были заранее перечислены. Песочница предоставляет уровень принудительного применения для обработки этой неопределенности без необходимости доверять каждому отдельному действию агента заранее.
Распространенные провайдеры песочниц
Краткий обзор основных вариантов, с более полными сравнениями в связанных статьях:
- Novita Agent Sandbox — microVM Firecracker, развертывание BYOC в вашем собственном VPC в AWS или GCP, без абонентской платы, сеансы до 24 часов. Основной вариант для команд с требованиями соответствия, чувствительностью к стоимости или тех, кто уже использует Novita для инференса LLM. См. novita.ai/sandbox.
- E2B — управляемый, microVM Firecracker, большое сообщество, без самостоятельного хостинга. Хорошо документированные SDK и активная экосистема.
- Daytona — холодный старт менее 90 мс, open-source (AGPL), возможность самостоятельного хостинга. Лучше подходит для случаев, чувствительных к задержке или с требованиями соответствия, где необходима собственная инфраструктура.
- Modal — основной вариант, когда вам нужен GPU внутри песочницы. Изоляция на основе контейнеров.
- Vercel Sandbox — быстрый холодный старт, лучше всего подходит для JS/TS на платформе Vercel.
Для полного сравнения с характеристиками и системой принятия решений см. Лучшие песочницы ИИ-агентов в 2026. Для углубленной оценки E2B и Daytona — холодный старт, BYOC, снимки и цены — см. Руководство по оценке песочниц ИИ-агентов: сравнение E2B и Daytona.
