Песочницы для ИИ-агентов: чем изолировать код, который пишет модель

Когда ИИ-агент не просто предлагает код в чате, а сам создаёт файлы, ставит зависимости и выполняет команды в терминале, встаёт вопрос, который раньше касался только серверов с чужим кодом: где всё это запускать, чтобы одна неудачная команда rm -rf или скачанный из npm пакет с закладкой не снёс рабочую систему. За 2024–2025 годы у команд, продающих запуск кода от агентов, сложился набор ответов — от простого Docker до микровиртуальных машин с загрузкой за десятки миллисекунд. Ниже — чем они отличаются и что выбрать под конкретную задачу.

Почему обычного запуска уже недостаточно

Агент с доступом к оболочке — это программа, которой вы заранее не знаете, какую команду она выполнит. Модель может решить установить зависимость, чтобы "проверить гипотезу", выкачать датасет по ссылке из промпта или выполнить скрипт, сгенерированный по инструкции из README. Каждое из этих действий — потенциальный вектор атаки: prompt injection[1] из содержимого файла может заставить агента отправить ваши переменные окружения на чужой сервер.

Отсюда три требования к среде, где живёт агент:

• Изоляция файловой системы — агент не должен видеть ~/.ssh, ~/.aws и остальной хост.
• Контроль сети — по умолчанию либо запрет исходящих соединений, либо белый список доменов.
• Ограничение ресурсов и времени — чтобы бесконечный цикл или форк-бомба не положили машину.

Четыре уровня изоляции

Права ОС: seccomp, namespaces, gVisor

Самый лёгкий уровень — ограничить процесс средствами ядра Linux: пространства имён (namespaces), seccomp-фильтры системных вызовов, cgroups для памяти и CPU. Google gVisor идёт дальше — это перехватчик системных вызовов в пользовательском пространстве, который подставляет процессу собственную реализацию ядра. Накладные расходы минимальны, но и граница защиты — общее хост-ядро, а значит уязвимость в ядре теоретически пробивает изоляцию.

Контейнеры: Docker и его собратья

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

Микровиртуальные машины: Firecracker и e2b

Firecracker — движок микро-ВМ от Amazon, на котором построены AWS Lambda и Fargate. Он даёт полноценную виртуализацию (отдельное ядро гостя) при времени старта в десятки миллисекунд и малом расходе памяти на инстанс. На нём же построены облачные песочницы для агентов — например, e2b, который предоставляет API для запуска изолированных сред под кодогенерацию.

WebAssembly-песочницы

WASM даёт изоляцию на уровне языка выполнения: код компилируется в переносимый байт-код и работает в среде без доступа к системным вызовам, если их явно не пробросить через WASI. Подходит для запуска отдельных функций и плагинов, хуже — для полноценного "поставь пакеты и запусти тесты", где нужен настоящий POSIX-окружение.

Сравнение подходов

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

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

Как это устроено в популярных агентах

Инструменты для кодинга подходят к изоляции по-разному, и это стоит понимать до того, как дать агенту доступ к терминалу:

• Claude Code (Anthropic) запускается локально и по умолчанию спрашивает подтверждение перед выполнением команд; есть режим автоматического подтверждения, который включают на свой риск. Для изоляции разработчики предлагают запускать его внутри контейнера.
• OpenAI Codex в облачном режиме выполняет задачи в изолированной среде на стороне сервиса; локальный CLI работает с вашей файловой системой.
• Облачные песочницы (e2b и аналоги) дают готовый API: агент через них создаёт эфемерную среду, гоняет код и получает результат, а среда уничтожается.

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

Кому это пригодится и кому нет

Пригодится, если вы:

• Строите сервис, где ИИ-агент выполняет код по запросу пользователей — здесь без микро-ВМ или облачной песочницы с мультиарендностью не обойтись.
• Даёте агенту право самостоятельно ставить зависимости и запускать тесты в CI — контейнер с отключённой сетью и белым списком реестров закрывает основные риски.
• Работаете с чужими репозиториями и запускаете их скрипты — отдельное ядро защищает хост от закладок в билд-скриптах.

Скорее не нужно, если вы:

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

Минимальная безопасная конфигурация

Если хочется быстро закрыть основные дыры для локального агента, порядок такой:

1. Запустите агента в контейнере, а не на голом хосте.
2. Пробросьте внутрь только рабочую папку проекта — не весь домашний каталог.
3. Не передавайте в среду боевые ключи и токены; используйте отдельные тестовые.
4. Отключите исходящую сеть либо оставьте белый список нужных доменов (реестр пакетов, внутренние сервисы).
5. Ограничьте память, CPU и время выполнения команды.
6. Оставьте подтверждение опасных команд включённым, пока не убедитесь, что среда действительно эфемерна.

[1] Prompt injection — атака, при которой вредоносная инструкция прячется в данных, которые обрабатывает модель (в файле, на веб-странице, в тексте письма), и заставляет агента выполнить действие, которого пользователь не заказывал. Вернуться