Docker Sandboxes и MicroVMs: изоляция AI-агентов

На прошлой неделе команда Docker представила Docker Sandboxes, стремясь достичь надежной изоляции для агентов в своей сфере

В этом сообщении мы обсудим, как микровиртуальные машины (MicroVMs) обеспечивают необходимую изоляцию и архитектурные решения, принятые в этом подходе

Почему контейнеры и ВМ не подходят для изоляции агентов

Каждая модель изолирования требует от вас чем-то пожертвовать. Рассмотрим четыре основных подхода

Полноценные виртуальные машины обеспечивают высокий уровень изоляции, но ВМ общего назначения не оптимизированы для работы с большим количеством сессий агентов. Некоторые специализированные ВМ могут запускаться быстрее на современном оборудовании, но использование ВМ общего назначения часто связано с медленным холодным стартом и большими накладными расходами

Контейнеры работают быстро и широко применяются в разработке современных приложений. Однако, когда речь идет об автономном агенте, которому требуется собирать и запускать собственные Docker-контейнеры, возникает проблема с Docker-in-Docker. Это требует повышенных привилегий, подрывающих необходимую изоляцию

WASM / V8-изоляты обеспечивают быстрый запуск, но их модель изоляции отличается от обычных операционных систем. Поставщики песочниц на основе изолятов признают, что усиливать защиту V8 сложно, и находить уязвимости в движке V8 проще, чем в проверенных гипервизорах. К тому же, WASM не позволяет агентам устанавливать системные пакеты или выполнять произвольные команды

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

MicroVMs предоставляют необходимую изоляцию на уровне аппаратной границы, избегая накладных расходов полноценной ВМ и ограничений контейнеров. Каждая агентская сессия получает свое ядро и Docker-демон, надежно защищенные

По этой теме полезно отдельно посмотреть Что такое Docker — объяснение простыми словами, чтобы расширить контекст и сравнить подходы

По этой теме полезно отдельно посмотреть Docker backup — резервное копирование контейнеров и данных, чтобы расширить контекст и сравнить подходы

MicroVMs vs контейнеры: в чём преимущество для агентов

Docker Sandboxes запускают каждую агентскую сессию внутри выделенной MicroVM с приватным Docker-демоном, изолированным границей ВМ, и без пути обратно к хосту

В этом одном предложении содержатся три архитектурных решения, заслуживающих пояснения

Выделенная MicroVM. Каждая песочница имеет собственное ядро. Это обеспечивает изоляцию на уровне аппаратной границы, аналогично полноценной ВМ. Даже если агент скомпрометирован, он не сможет получить доступ к хосту или другим песочницам, что гарантирует целостность

Приватный Docker-демон. Каждая песочница имеет свой Docker-демон, работающий внутри MicroVM. Это позволяет использовать docker build, docker run и docker compose без необходимости монтирования сокетов и получения повышенных привилегий на хосте

Никакого пути обратно к хосту. Ограничение доступа к файлам и ресурсам устанавливается заранее, что отличает наш подход. Логика безопасности, разработанная самим агентом, не обеспечивает необходимого уровня защиты

MicroVMs на macOS и Windows: почему потребовался новый VMM

Выбор MicroVMs был лёгкой частью. Запустить их там, где разработчики реально работают, — вот что оказалось сложным

Мы изучили существующие решения, но ни одно из них не удовлетворяло нашим требованиям. Firecracker, наиболее известный проект для MicroVM, изначально был создан для облачной инфраструктуры, но не поддерживает macOS или Windows, что является ограничением

Можно адаптировать существующий VMM (Virtual Machine Monitor) для работы на различных платформах. Однако это приведёт к созданию хрупких обходных решений и нарушению принципа «работает без дополнительной настройки», что может заставить разработчиков отказаться от изоляции

Поэтому мы создали новый VMM, специально разработанный для тех мест, где реально работают агенты написания кода

Он работает нативно на всех трёх платформах, используя нативный гипервизор каждой ОС: Apple Hypervisor.framework, Windows Hypervisor Platform и Linux KVM. Единая кодовая база для трёх платформ и ноль трансляционных слоёв

Это важно, потому что означает: агенты получают изоляцию на уровне ядра, оптимизированную для каждой конкретной ОС. Холодный старт выполняется быстро, потому что нет налога на абстракцию. Разработчик на MacBook получает те же гарантии изоляции и ту же производительность при запуске, что и разработчик на рабочей станции Linux или машине с Windows

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

Холодный старт MicroVM: как это работает в Docker Sandboxes

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

При почти мгновенном запуске нет никаких причин производительности запускать агента вне неё

Docker Sandboxes на практике: что получает разработчик

Вот конкретная версия того, что даёт эта архитектура

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

Ограниченный доступ, а не всё или ничего. Вы определяете границу: именно те файлы и директории, которые агент может видеть, сетевые конечные точки, к которым он может обращаться, и секреты, которые он получает. Учётные данные вводятся во время выполнения и за пределами границы MicroVM, никогда не встраиваясь в среду

Одноразовый по замыслу. Если агент сбился с курса, удалите песочницу и начните заново за считанные секунды. Нет никакого состояния для очистки и ничего для отката на вашем хосте

Работает с каждым крупным агентом. Claude Code, Codex, OpenCode, GitHub Copilot, Gemini CLI, Kiro, Docker Agent и системы следующего поколения, такие как OpenClaw и NanoClaw. Одинаковая изоляция, одинаковая скорость, единая модель песочницы для всех них

Docker Sandboxes для команд: сценарии применения

Индивидуальные разработчики могут установить и запустить Docker Sandboxes уже сегодня, автономно, без необходимости лицензии Docker Desktop

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

Почему MicroVMs устраняют компромисс между скоростью и изоляцией

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

MicroVMs устраняют эту звёздочку. Вы получаете изоляцию уровня ВМ с холодным стартом, достаточно быстрым, чтобы не было причин её пропускать, и полную поддержку Docker внутри песочницы. Никакого компромисса нет

Ваши агенты должны работать автономно. Просто они не должны работать без каких-либо ограничений

Быстрый старт: установка Docker Sandboxes

Установите Docker Sandboxes одной командой

macOS:

brew install docker/tap/sbx

Windows:

winget install Docker.sbx

Часто задаваемые вопросы о Docker Sandboxes и MicroVMs

Чем MicroVMs отличаются от обычных контейнеров с точки зрения безопасности? Контейнеры разделяют ядро хост-системы, что при определённых конфигурациях открывает путь к хосту. MicroVMs дают каждой сессии собственное изолированное ядро — аппаратная граница изоляции (hardware boundary) не позволяет агенту добраться до хоста или соседних сессий даже при компрометации

Почему Docker создал собственный VMM вместо использования Firecracker? Firecracker разработан для Linux/KVM-сред и не имеет нативной поддержки macOS и Windows. Новый VMM использует нативный гипервизор каждой платформы — Apple Hypervisor.framework, Windows Hypervisor Platform и Linux KVM — без трансляционных слоёв и обходных решений

Может ли агент внутри Docker Sandbox запускать собственные контейнеры? Да. Каждая песочница получает приватный Docker-демон, изолированный границей MicroVM. Агент может выполнять docker build, docker run и docker compose без монтирования сокетов и без привилегий на уровне хоста

Кто определяет, к каким файлам и сетевым ресурсам имеет доступ агент? Границы доступа задаются до запуска агента — на уровне инфраструктуры, а не самим агентом. Учётные данные вводятся во время выполнения и никогда не встраиваются в среду

С какими агентами совместимы Docker Sandboxes? Claude Code, Codex, OpenCode, GitHub Copilot, Gemini CLI, Kiro, Docker Agent, OpenClaw и NanoClaw. Единая модель песочницы работает для всех них с одинаковой изоляцией и одинаковой скоростью запуска