В эпоху, когда генеративный искусственный интеллект перестал быть просто инструментом для генерации текста и превратился в активного участника вычислительных процессов, вопрос безопасности стал критическим. AI-агенты, способные писать и выполнять код, открывают невероятные возможности для автоматизации, но одновременно создают уязвимости, которые могут привести к компрометации данных или ресурсов. Классические подходы к изоляции, такие как Docker-контейнеры, часто оказываются недостаточными, так как они разделяют ядро хост-системы, что оставляет риск эскалации привилегий. На фоне этого решения, основанные на аппаратной изоляции, такие как Firecracker и проект smolmachines (smolvm), выглядят как следующий эволюционный шаг в обеспечении безопасности облачных и локальных вычислений.
В августе 2026 года исследователь Саймон Уиллисон (Simon Willison) провел детальный анализ проекта smolmachines, позиционируя его как идеальную песочницу для выполнения ненадежного кода на Python и JavaScript. Целью было не просто запустить скрипт, а создать среду, где пользовательский код ограничен в потреблении ресурсов (CPU и RAM), не имеет доступа к сети и может работать только с заранее разрешенными файлами. Это особенно актуально для сценариев трансформации данных, где пользователи загружают свои скрипты или конфигурации, доверять которым на 100% нельзя.
Тестирование версии 1.8.3 smolvm показало впечатляющие результаты: холодный старт занимает от 0,6 до 1,5 секунд, а повторное выполнение (warm execution) происходит за 50 миллисекунд. Эти показатели делают технологию пригодной для использования в реальном времени, например, в веб-интерфейсах или API, где задержка должна быть минимальной. Однако путь к этим результатам был непростым, и он ярко демонстрирует современные вызовы при работе с ИИ-агентами и сложными средами выполнения.
01Инициатива ИИ-агента: от идеи к реализации
Саймон Уиллисон поставил перед своим ИИ-агентом Claude Fable 5 (работающим в среде Claude Code for Web) конкретную исследовательскую задачу. Агента попросили «проверить на прочность» сайт smolmachines.com и оценить, насколько он подходит для песочницы. Ключевые требования к среде были сформулированы четко: выполнение ненадежного Python и JavaScript кода, жесткое ограничение оперативной памяти и времени процессора (защита от бесконечных циклов типа while true), полное отсутствие сетевого доступа и изолированная файловая система, доступная только для назначенных файлов.
Первая попытка столкнулась с техническим тупиком. Среда Claude Code for Web, в которой работал агент, сама по себе является контейнером на базе Linux (версия ядра 6.18.5-fc-v20), работающим на виртуальной машине Firecracker. У этого контейнера было 4 виртуальных процессора и 15 ГБ оперативной памяти, но критически отсутствовали необходимые для виртуализации компоненты: не было устройства /dev/kvm и флагов vmx/svm в процессоре. Это означало отсутствие поддержки вложенной виртуализации (nested virt). Команда smolvm machine run завершилась ошибкой «kvm not available», так как smolvm требует прямого доступа к аппаратной виртуализации для создания изолированных гостевых машин.
02Обходные пути: GitHub Actions как полигон
Вместо того чтобы сдаваться, агент проявил инициативу и разработал план «Б». Он обнаружил, что стандартные раннеры GitHub Actions (ubuntu runners) предоставляют доступ к /dev/kvm. Это стало ключевым открытием, позволившим обойти ограничения локальной среды разработки. Агент создал временный рабочий процесс (workflow) в GitHub Actions, установил smolvm и запустил полный набор тестов непосредственно на раннере.
Этот подход демонстрирует новую парадигму разработки: ИИ-агенты способны не только писать код, но и диагностировать инфраструктурные ограничения, находить обходные пути и настраивать облачную инфраструктуру для решения локальных проблем. После успешного прохождения тестов агент собрал логи, подтвердил работоспособность всех функций безопасности и удалил временный workflow, оставив только чистый код и отчет.
03Архитектура безопасности smolvm
Успех тестирования smolvm 1.8.3 базируется на нескольких столпах безопасности, которые делают эту технологию привлекательной для разработчиков, работающих с пользовательским кодом. В отличие от контейнеров, которые изолируют процессы на уровне ядра, smolvm использует микро-виртуальные машины (microVMs), построенные на базе Firecracker. Это обеспечивает аппаратную изоляцию: если злоумышленник сможет скомпрометировать гостевую ОС, он все равно не получит доступа к хост-системе или другим гостевым машинам.
Ограничение ресурсов: защита от DoS
Одной из главных угроз при запуске пользовательского кода является атака типа «отказ в обслуживании» (DoS) через исчерпание ресурсов. Например, простой скрипт на Python:
while True:
passМожет занять 100% CPU и зависнуть систему. smolvm позволяет задать жесткие лимиты на использование CPU и RAM. Если скрипт превышает выделенные квоты, виртуальная машина принудительно завершается. Это гарантирует, что один пользовательский запрос не повлияет на стабильность работы всего сервиса.
Сетевая изоляция
По умолчанию smolvm запускает гостевые машины без сетевого доступа. Это критически важно для предотвращения утечки данных, загрузки вредоносного ПО извне или использования скомпрометированной машины для атак на другие ресурсы. Если сетевой доступ необходим, он должен быть явно разрешен и строго контролироваться, но в сценариях трансформации данных он чаще всего не требуется.
Файловая система: принцип наименьших привилегий
Доступ к файловой системе в smolvm настраивается через монтирование томов. Входные данные (input mounts) могут быть смонтированы в режиме только для чтения (read-only), что предотвращает случайное или намеренное изменение исходных данных. Выходные данные (output mounts) доступны для записи, позволяя скрипту сохранять результаты. Такая структура исключает возможность чтения конфиденциальных файлов хоста или записи в системные каталоги.
Таймауты и привилегии
Дополнительным слоем защиты является параметр --unprivileged, который запускает процессы внутри гостевой машины без прав root. Это снижает риск эскалации привилегий внутри самой виртуальной машины. Кроме того, smolvm поддерживает гостевые таймауты (guest-enforced timeouts), которые принудительно завершают выполнение скрипта, если он работает дольше заданного времени, даже если лимиты CPU не были исчерпаны.
04Производительность: скорость как преимущество
Часто считается, что виртуальные машины медленнее контейнеров. Однако smolvm опровергает этот стереотип. Холодный старт (cold start) занимает от 0,6 до 1,5 секунд. Это время необходимо для инициализации микро-виртуальной машины, загрузки ядра гостевой ОС и запуска процесса. Для сравнения, традиционные VM могут запускаться минуты, а контейнеры — доли секунды. Но smolvm находится в «золотой середине», предлагая безопасность VM с почти контейнерной скоростью.
Что еще более впечатляет, время повторного выполнения (warm execution) составляет около 50 миллисекунд. Это достигается за счет оптимизаций в загрузке образов и кэшировании состояний. Для приложений, требующих быстрого отклика, таких как интерактивные веб-инструменты или API для обработки данных, такая производительность является конкурентным преимуществом.
05Практическое применение: трансформация данных
Основной сценарий использования smolvm, описанный в исследовании, — это выполнение пользовательских задач по трансформации данных. Представьте сервис, где пользователи загружают CSV-файлы и пишут небольшие скрипты на Python или JavaScript для их обработки. Без песочницы такой сервис был бы крайне рискован: пользователь мог бы написать код, крадущий другие файлы или отправляющий данные на внешний сервер.
С smolvm архитектура такого сервиса выглядит следующим образом:
- Пользователь загружает входной файл и скрипт.
- Сервер создает временную виртуальную машину smolvm.
- Входной файл монтируется в режиме только для чтения.
- Скрипт выполняется с ограниченными ресурсами и без сети.
- Результат записывается в выходной том.
- Виртуальная машина уничтожается, а результат возвращается пользователю.
Этот процесс полностью изолирован, безопасен и масштабируем. Каждый запрос выполняется в собственной среде, что исключает конфликты между задачами разных пользователей.
06Локальный запуск и доступ из России
Для разработчиков, работающих в условиях ограниченного доступа к зарубежным облачным сервисам, smolvm представляет интерес как решение для локального развертывания. Поскольку smolvm работает на базе KVM, он может быть установлен на любой Linux-сервер с поддержкой виртуализации. Это позволяет создать полностью автономную песочницу внутри компании или на личном сервере, не зависящую от внешних провайдеров.
Однако важно учитывать требования к оборудованию. Для эффективной работы smolvm необходим сервер с достаточным количеством ядер и оперативной памяти, а также поддержкой аппаратной виртуализации. В условиях локального запуска администраторам необходимо самостоятельно настраивать права доступа к /dev/kvm и управлять ресурсами хост-системы.
07Выводы и перспективы
Исследование Саймона Уиллисона демонстрирует, что smolmachines (smolvm) является зрелым и надежным инструментом для безопасного выполнения ненадежного кода. Сочетание аппаратной изоляции, быстрого запуска и гибкой настройки ограничений делает его идеальным выбором для AI-агентов и сервисов, работающих с пользовательским кодом.
Ключевым уроком из этого эксперимента стала роль ИИ-агентов в решении инфраструктурных задач. Агент Claude Fable 5 не просто выполнил команду, а адаптировался к ограничениям среды, нашел обходной путь через GitHub Actions и доказал работоспособность технологии. Это открывает новые возможности для автоматизации DevOps-процессов и тестирования безопасности.
08Что это значит на практике
Для разработчиков и архитекторов, рассматривающих внедрение AI-агентов в свои продукты, smolvm предлагает готовое решение для безопасного исполнения кода. Вместо изобретения велосипедов с использованием контейнеров и сложных правил iptables, можно использовать готовые микро-виртуальные машины с гарантированной изоляцией.
Если вы планируете запускать пользовательские скрипты, особенно в условиях, где доверие к коду отсутствует, smolvm должен быть в вашем списке инструментов. Начните с локального тестирования на сервере с KVM, чтобы оценить производительность и удобство настройки. Для облачных решений ищите провайдеров, предоставляющих доступ к /dev/kvm, или используйте CI/CD-системы, такие как GitHub Actions, для прототипирования.
Безопасность в эпоху AI — это не опция, а необходимость. smolmachines показывает, что высокая безопасность и высокая производительность могут сосуществовать, если правильно выбрать архитектуру изоляции.
Источник: Simon Willison ↗