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

У любого агента, который умеет писать код, рано или поздно возникает момент истины: код написан, и его надо запустить. Скрипт для обработки данных, миграция, тест, сборка проекта. И здесь самый простой вариант — выполнить прямо там, где работает агент, — оказывается самым опасным. Модель может ошибиться, может быть обманута через промпт-инъекцию, а может просто честно выполнить инструкцию, последствий которой никто не просчитал.

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

Почему нельзя просто выполнить

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

Разрушительные действия. Одна ошибка в пути — и rm -rf вычищает не временную папку, а корень проекта. Модель не отличает «удалить кеш» от «удалить всё», если контекст ей это не объяснил.

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

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

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

Уровни изоляции: от процесса до виртуальной машины

Слово «песочница» скрывает очень разные технологии, и главное различие — сколько общего у изолированного кода с хост-системой.

Отдельный процесс. Запустить код через subprocess с ограничением по времени — это не изоляция. Процесс видит ту же файловую систему, те же переменные окружения и ту же сеть. Годится только для доверенного кода.

Контейнер (Docker). Изоляция на уровне пространств имён ядра: своя файловая система, свои процессы, при желании — отсутствие сети. Быстро стартует, всем знакомо. Слабое место в том, что ядро общее с хостом: уязвимость в ядре позволяет выбраться из контейнера. Для большинства задач достаточно, для враждебного кода — с оговорками.

gVisor. Прослойка между контейнером и ядром: системные вызовы перехватываются и обрабатываются пользовательским «ядром-заглушкой», так что реальное ядро хоста код почти не трогает. Заметно безопаснее контейнера, немного медленнее на интенсивном вводе-выводе. Ставится как альтернативный рантайм Docker.

Микровиртуалка (Firecracker). Полноценная виртуальная машина со своим ядром, но настолько облегчённая, что стартует за десятки миллисекунд. Именно на Firecracker работают AWS Lambda и большинство облачных песочниц для агентов. Это самая сильная изоляция из практически применимых: чтобы навредить хосту, коду нужно выбраться из виртуальной машины.

Правило выбора простое: чем менее доверенный код и чем больше на хосте ценного, тем выше по этой лестнице стоит подняться.

Что нужно от песочницы именно для агента

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

Сеть выключена по умолчанию. Большинству скриптов сеть не нужна вовсе. Если нужна — открывать точечно, по списку разрешённых адресов: зеркало пакетов, конкретный API. Открытая сеть превращает утечку данных в вопрос одной строки кода.

Внутри нет секретов. Ключи и токены живут снаружи, у оркестратора. Если задаче нужно обратиться к внешнему сервису, лучше дать ей узкий одноразовый токен, чем ваш основной ключ.

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

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

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

Готовые сервисы

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

Vercel Sandbox. Микровиртуалки на Firecracker, SDK для JavaScript и Python, образ по умолчанию уже содержит Node.js, Python и кодинг-агентов. Из интересного — сохранение состояния между запусками, снимки, и возможность выдать каждому агенту отдельного Linux-пользователя внутри одной песочницы, чтобы несколько агентов работали над задачей, не мешая друг другу. С 10 сентября 2026 года песочницы доступны во всех 20 регионах Vercel с выбором региона на любом тарифе; на Pro и Enterprise можно задать резервные регионы на случай, если основной недоступен. Оплата — за активное процессорное время и выделенную память, ставки зависят от региона.

E2B. Открытый проект, тоже на Firecracker, с заявленным стартом менее чем за 200 мс. Поддерживает Python, JavaScript и TypeScript, R, Java и Bash. Есть бесплатный тариф с разовым кредитом на использование и ограничением по длительности сессии, платный — с суточными сессиями и настраиваемыми ресурсами. Тарификация посекундная, порядка нескольких центов в час за виртуальное ядро.

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

Общее у всех троих: быстрый старт, SDK, оплата за фактическое время, встроенная поддержка сценария «агент → код → результат». Различаются деталями: Vercel логично брать, если проект уже живёт на Vercel; E2B — если важна открытость и возможность самостоятельного развёртывания; Modal — если агенту нужны GPU.

Что доступно из России

Честный раздел, без которого статья была бы неполной. Все три сервиса выше — американские, и у них общая проблема для нашей аудитории: оплата картами российских банков, как правило, не проходит, а регионов размещения в России нет ни у одного. Технически подключиться можно, но рассчитывать на них как на основу продакшена — рискованно: доступ может закончиться в любой момент по независящим от вас причинам.

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

Своя песочница на обычном сервере

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

docker run --rm \
  --network none \
  --read-only \
  --tmpfs /tmp:size=256m \
  --memory 512m \
  --cpus 1 \
  --pids-limit 128 \
  --user 65534:65534 \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  -v /srv/sandbox/task-42:/work \
  -w /work \
  python:3.12-slim \
  timeout 60 python main.py

Что делает каждая строка. --network none отрезает сеть целиком. --read-only запрещает писать куда-либо, кроме явно разрешённых мест — временной папки в памяти и рабочего каталога задачи. --memory, --cpus и --pids-limit не дают съесть ресурсы хоста. --user запускает код от непривилегированного пользователя, --cap-drop ALL снимает все расширенные права, no-new-privileges запрещает их вернуть. Внешний timeout убивает задачу через минуту. Флаг --rm уничтожает контейнер после завершения — одна задача, одна среда.

Рабочий каталог /srv/sandbox/task-42 — единственное, что связывает песочницу с хостом: туда оркестратор кладёт файлы задачи, оттуда забирает результат. В нём не должно быть ничего, кроме этой задачи.

Следующая ступень — gVisor. Устанавливается как дополнительный рантайм, после чего к той же команде добавляется --runtime runsc. Код перестаёт напрямую трогать ядро хоста — и вы получаете изоляцию заметно ближе к виртуальной машине, не меняя остального.

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

Как это встраивается в агента

С точки зрения агента песочница — это просто инструмент, обычно с именем вроде run_code. Оркестратор, получив вызов, создаёт каталог задачи, кладёт туда файлы, запускает контейнер с таймаутом, собирает вывод и созданные файлы, уничтожает контейнер и возвращает результат модели. Механика вызова инструментов описана в статье про tool calling — песочница ничем не отличается от любого другого инструмента, кроме того, что происходит внутри.

Полезно заметить, что существует и другая философия. Локальные среды вроде Claude Code или ZCode выполняют код прямо на машине разработчика, но с подтверждением человеком каждого опасного действия. Это не изоляция, а контроль — он работает, пока за столом сидит человек. Как только агент начинает работать автономно, по расписанию или от имени пользователей, контроль надо заменять изоляцией.

Частые ошибки

Выполнять на машине разработчика с полными правами — самая частая. Удобно до первого инцидента.

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

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

Одна долгоживущая песочница на все задачи — состояние копится, компрометация живёт вечно, отладка превращается в археологию.

Нет таймаута — зависший скрипт держит ресурсы, пока его не заметят вручную. Иногда неделями.

Коротко

Код, написанный моделью, — недоверенный код, и выполнять его надо в изоляции. Лестница изоляции идёт от контейнера через gVisor к микровиртуалкам Firecracker, и подниматься по ней стоит по мере того, как растёт цена ошибки. Облачные песочницы — Vercel Sandbox, E2B, Modal — решают задачу под ключ, но из России на них полагаться рискованно; своя песочница на Docker с жёсткими флагами собирается за вечер и закрывает большинство сценариев. А главное правило не зависит от технологии: сеть выключена, секретов внутри нет, лимиты на всё, одна задача — одна среда.