Содержание
Коротко
Контейнер — это процесс с отдельным взглядом на файлы, процессы и сеть, но с общим ядром машины. Docker Sandboxes — отдельная микроВМ: своё ядро Linux, своя файловая система, своя сеть и свой демон Docker. Путать их легко, потому что внутри песочницы агент как раз запускает контейнеры. Граница при этом другая. Сервис по-прежнему живёт в контейнере. Агента, который часами ставит пакеты и читает чужие инструкции, Docker предлагает сажать в микроВМ.
Что произошло
В блоге Docker Шрини Секаран и Олег Селаев разбирают, почему «песочница» — не контейнер с агентом внутри. Контейнер изолирует приложение: пространства имён дают свой вид файлов и сети, группы контроля отмеряют процессор, память и диск. Старт быстрый, плотность высокая, общий примитив для Compose, Kubernetes и почти любой сборки. Если нужно поднять сервис, выполнить обрывок кода или прогнать оценку и исчезнуть, контейнер остаётся нормальным выбором.
Агент ведёт себя как человек за ноутбуком, а не как процесс с известным набором зависимостей. Он клонирует репозиторий, ставит пакеты, поднимает PostgreSQL, гоняет миграции, собирает образы, читает журналы и пробует снова часами. Каждый шаг опирается на то, что оставил предыдущий. Контейнер рассчитан на сборку из образа и нескольких явных томов: всё, что агент создал мимо них, пропадает при пересоздании.
Вторая разница — откуда берутся команды. Решение, что запустить, вероятностное. Инструкции приходят из файлов, задач, страниц, описания пакетов и ответов инструментов. Часть этого входа никто не проверял. В тексте вспоминают уже виденный случай, когда агент удалил боевую базу, неверно прочитав задачу. В режиме, где подтверждения выключены, ловить это некому.
Песочница запускается одной командой sbx run claude. Её можно остановить и продолжить: поставленное агентом остаётся, пока песочницу не удалят. Внутри у агента есть права суперпользователя и свой Docker, без сокета демона на хосте.
Почему это важно
Побег из контейнера упирается в общее ядро. Дальше — ядро машины, соседние процессы и смонтированные секреты. На macOS и Windows контейнеры и так сидят в виртуальной машине Docker Desktop, но друг с другом они всё равно делят одно ядро этой машины. МикроВМ ставит гипервизор между агентом и вашим ядром: выбрался из контейнера — оказался в одноразовой гостевой системе, хост снаружи. Два агента на одной машине не видят песочницы друг друга. Доступно только то, что вы сами отдали: рабочий каталог, разрешённые адреса, серверы MCP и навыки.
Отдельная дыра — сокет /var/run/docker.sock. Его монтируют в Compose, в сборках и в средствах наблюдения, и он отдаёт контейнеру управление демоном хоста. Агенту не нужен новый эксплойт: он осматривает среду, потому что работа в этом и состоит. В демонстрации из доклада агент так добрался до файла с секретами на хосте. В песочнице демон свой, внутри гостя. Сокет хоста снаружи.
Правила, которые агент может прочитать, он может обойти. Исходящий трафик в этой схеме идёт через прокси на хосте со списком запрета по умолчанию. Для части HTTP-сервисов ключ подставляет тот же прокси, и сырое значение в виртуальную машину не попадает. Каталог проекта по умолчанию смонтирован на запись: агент может править и удалять файлы. Режим клона даёт ему частную копию внутри машины, исходный репозиторий при этом остаётся читаемым.
На практике
| Берите контейнер | Берите песочницу |
|---|---|
| Код и зависимости ваши, запуск короткий | Код рождается или скачивается во время работы |
| Свой Docker не нужен или его уже даёт сборка | Нужен свой Docker без пути к сокету хоста |
| Нужны плотность, Compose или Kubernetes | Нужны сеть и ключи, которые процесс не может выключить |
| Общего ядра достаточно | Нужен гипервизор между нагрузкой и вашим ядром |
Docker называет пять поводов начать с песочницы: агент работает без присмотра или подтверждения включены сами; ему надо собирать образы, Compose или Testcontainers; он читает задачи, страницы, метаданные пакетов или вывод MCP, которые писали не вы; ключи не должны оказаться внутри среды; сессия длиннее одной задачи.
Железо тяжелее, чем у ещё одного контейнера. Нужен гипервизор: Apple silicon и macOS 14 или новее, Windows Hypervisor Platform, либо KVM на поддерживаемых сборках Ubuntu. Внутри другой виртуальной машины нужна вложенная виртуализация. Облачный вариант крутит ту же изоляцию на машинах Docker, секреты и сетевые правила у локальной и облачной копии раздельные. Наборы инструментов и файл sbxenv.yaml Docker помечает как ранний доступ и эксперимент: коллега может поднять ту же песочницу одной командой, но формат ещё меняется.
Итог
Контейнер изолирует приложение, которое ведёт себя так, как его собрали. Агенту нужна граница, которую модель не переписывает, и состояние, которое живёт дольше одного процесса. Приложение по-прежнему пакуйте в контейнер. Агента, если он ходит в сеть и ставит пакеты сам, сажайте в микроВМ.