Как запереть код ИИ-агента: subprocess, Docker и microVM — три уровня защиты

Вы дали агенту инструмент «выполни Python-код» — и в этот момент у вас появился не просто ассистент, а удалённое исполнение кода, пусть и по просьбе модели. Модель может ошибиться, а может получить вредную инструкцию из подсунутой страницы или файла. Поэтому вопрос не «умный ли агент», а «что сможет достать плохая программа, когда она запустится». Авторы разбора на Machine Learning Mastery отвечают на него практически: строят три песочницы и гоняют по каждой одни и те же атаки.

Один инструмент, сменные бэкенды

Архитектура простая. Агент знает один инструмент, run_python: он принимает строку с кодом и возвращает stdout, stderr и код выхода. Код модели никогда не исполняется в процессе самого агента. Он уходит в объект песочницы с методом run(code), и любой класс с таким методом подойдёт. Поэтому смена уровня изоляции не требует трогать логику агента: подменили бэкенд и всё. Код возврата, отличный от нуля, помечается как ошибка, и модель видит это и может исправиться.

Важный принцип из блога Docker, который авторы относят ко всем уровням: доступ к файлам, сетевая политика и секреты задаются инфраструктурой до запуска агента, а не самим агентом.

Три границы

Subprocess — самый лёгкий вариант. Это дочерний процесс с лимитами на процессорное время, память (адресное пространство) и размер записываемых файлов. Вокруг него:

• запуск в изолированном режиме python -I во временной папке;
• чистое окружение без API-ключей и домашней директории;
• unshare --net, то есть приватная пустая сеть;
• вывод в файлы, чтобы лимит размера файла заодно защищал от потока print;
• по таймауту убивается вся группа процессов.

Если конструктор не может включить сетевую изоляцию, он падает с ошибкой, а не молча оставляет сеть открытой. Под root код сначала понижается до пользователя nobody.

Но у этого уровня честная оговорка: ядро и файловая система остаются хостовыми. Код работает от вашего имени на вашей файловой системе и ваших файлов не скрывает. Лимит числа процессов считает всех процессов пользователя, поэтому имеет смысл только для отдельного пользователя, на обычном ноутбуке он пропускается.

Docker-контейнер добавляет пространства имён и cgroups, но это всё те же процессы на ядре хоста. Документация Docker прямо говорит, что без явных настроек у контейнера нет ресурсных лимитов, поэтому в песочнице задаются память, число CPU и число процессов (в примере 256 МБ, один CPU, 64 pid). И побеги случаются: в ноябре 2025 года три уязвимости в runc позволяли выйти из контейнера.

MicroVM на Firecracker (в примере через E2B) выдаёт каждой песочнице собственное ядро за гипервизором. Docker называет это аппаратной границей, а AWS утверждает, что в Lambda на Firecracker ядро между сессиями не разделяется. Это самый дорогой по задержке вариант, и для него нужен аккаунт E2B с ключом.

Что с этим делать

Авторы тестируют каждый уровень на одинаковых враждебных программах: исчерпание CPU, памяти, процессов, диска, попытки читать файлы и ходить в сеть. Затем в bench.py они измеряют цену усиления изоляции в задержке. Цифр замеров в доступной части материала нет, поэтому прогоните бенчмарк на своём железе: задержка сильно зависит от окружения.

Практическая логика выбора такая:

• Subprocess годится для локальных экспериментов и кода, которому вы почти доверяете. Нужен Linux или WSL.
• Docker с жёсткими флагами подходит для внутренних инструментов, где риск побега вы готовы принять.
• MicroVM — выбор для чужого и недоверенного ввода и для мультитенантных продуктов, где побег означает инцидент.

И главное: не отдавайте агенту решение о собственной песочнице. Секреты, сеть и файлы определяет тот, кто разворачивает инфраструктуру. Если хотите готовое, а не самосборное, у авторов есть отдельная статья про пять хостинговых песочниц; здесь же всё собирается вручную, чтобы было видно, что именно эти платформы делают под капотом.