ИИ-агент, который пишет и выполняет свой собственный код, безопасен лишь настолько, насколько безопасна среда, в которой этот код работает. В руководстве, опубликованном Machine Learning Mastery, автор показывает, как изолировать этот код на трех уровнях: ограниченный подпроцесс, усиленный контейнер Docker и микро-ВМ Firecracker, а затем сравнивает их безопасность и задержки.
Подпроцесс — самый легкий уровень: это дочерний процесс с ограничениями на время вычислений, память и размер файлов, но он использует ядро и файлы хост-машины. Контейнер добавляет пространства имен и контрольные группы (cgroups), но остается набором процессов на ядре хоста. В статье напоминают, что в ноябре 2025 года три уязвимости в механизме выполнения runc позволили злоумышленникам вырваться из контейнеров. Микро-ВМ дает каждой среде собственное ядро, работающее под управлением гипервизора — программного обеспечения, запускающего виртуальные машины.
Устройство основано на одном инструменте run_python, предоставляемом агенту. Каждый код, сгенерированный моделью, проходит через объект «песочницы» с методом run(code), так что смена уровня изоляции не меняет агента. Для руководства требуется Python 3.10 или новее, Linux или WSL для уровня подпроцесса, Docker для контейнера, а также учетная запись и API-ключ E2B для микро-ВМ. Ключ API Anthropic полезен для агента, но для тестов можно обойтись без него.
Шесть одинаковых атак на каждом уровне
Для сравнения трех уровней выполняются одни и те же шесть враждебных программ: бесконечный цикл, выделение 512 МБ памяти, «флуд форков» на 200 процессов, запись файла размером 50 МБ, чтение поддельного файла с учетными данными и подключение к поддельному внутреннему сервису. Атака считается заблокированной, если маркерное слово не появляется в выводе, или, в случае бесконечного цикла, если выполнение превышает лимит времени.
На уровне подпроцесса, выполняемого под обычным пользователем Linux, четыре атаки блокируются, а две проходят. Ограничение на процессы применяется только к выделенному пользователю, поэтому флуд форков разрешен, а поддельный файл с учетными данными остается читаемым, поскольку код выполняется под идентификатором этого пользователя. Автор делает вывод, что этот уровень подходит в основном для доверенного кода.
Для контейнера Docker автор указывает, что при выбранных настройках Docker должен блокировать все шесть атак, поскольку контейнер не имеет сети, его файловая система не содержит файлов пользователя, а ограничения на память, процессы и диск применяются. В микро-ВМ атаки на память, процессы и диск могут достигать пределов виртуальной машины, но остаются внутри нее, а секретный файл и локальный сервис в ней отсутствуют.
Задержка и выбор уровня
Подпроцесс должен быть самым быстрым, поскольку он просто запускает Python. Для двух других уровней автор уточняет, что опубликованные цифры являются утверждениями, а не гарантиями: в одной из цитируемых статей говорится, что E2B запускается примерно за 150 мс, в то время как AWS и Docker описывают почти мгновенный запуск для своих продуктов на основе микро-ВМ. Скрипт bench.py позволяет измерить на своей машине медиану и максимальное время выполнения программы print(1) за десять запусков.
Автор рекомендует оставлять подпроцесс для доверенного кода, например, личных скриптов разработки, а усиленный контейнер — для случаев, когда вы контролируете хост и риски невелики, следя за своевременным обновлением runc. Микро-ВМ необходима для кода от нескольких пользователей, для всего, что связано с секретами, и когда агенту нужно самостоятельно создавать и запускать контейнеры, что, по словам Docker, плохо реализуется в классических контейнерах. Docker запустил свои Docker Sandboxes на микро-ВМ в апреле 2026 года, а AWS предлагает Lambda MicroVMs, которые сохраняют состояние до 8 часов и приостанавливаются при бездействии. По словам Docker, файлы, сетевые правила и секреты должны определяться инфраструктурой, а не агентом, до его выполнения.
