Почти каждый, кто дал агенту порулить кодом дольше пяти минут, рано или поздно выключает подтверждения. Claude Code — --dangerously-skip-permissions, Codex — --full-auto, дальше по списку. И это рационально: агент, который спрашивает разрешение на каждый ls, не экономит время, а сжигает его. Вопрос только в том, что стоит между этим агентом и вашей машиной.
Обычно там не стоит ничего.
Что именно вы разрешаете
Агент в автономном режиме — это процесс с вашими правами, который сам решает, что выполнить в шелле. Он видит ~/.ssh, ~/.aws, ~/.config/gh, куки браузера, соседние рабочие репозитории и историю шелла. Не потому, что он злой, а потому что вы его так запустили: ваш uid, ваш $HOME.
Дальше достаточно одной из трёх вещей: агент неверно понял задачу и выполнил rm -rf не в том каталоге; в контекст попала инструкция из внешнего источника (issue на GitHub, README зависимости, содержимое веб-страницы) и агент её исполнил; агент поставил пакет, у которого в postinstall лежал не тот код. Третий сценарий на форуме уже разбирали — червь Shai-Hulud в npm собирал токены именно так.
❗ Главное
Изоляция агента решает ровно одну задачу: ограничить радиус поражения, когда агент сделает не то. Она не делает агента умнее и не защищает от того, что он испортит сам проект, к которому вы дали ему доступ.
Граница первая: контейнер. Что он держит
Самый частый ответ — «запусти в докере». Он рабочий, но полезно понимать, где именно проходит граница.
Контейнер — это процесс на вашем ядре, отделённый namespaces (PID, mount, net, user) и ограниченный cgroups, seccomp и capabilities. Файловая система изолирована, сеть изолирована, чужие процессы не видны. Для «агент случайно удалил каталог» этого достаточно: он удалит его внутри контейнера.
Чего контейнер не держит:
Ядро общее. Любая уязвимость в syscall-интерфейсе ядра — это потенциальный побег на хост. Такие CVE выходят регулярно.
То, что вы сами прокинули.-v /var/run/docker.sock:/var/run/docker.sock — это root на хосте одной командой. --privileged — то же самое. А агенту часто нужен докер: он хочет собрать образ, поднять базу, прогнать интеграционные тесты.
Смонтированный каталог проекта. Он смонтирован на запись, иначе смысла нет.
⚠️ Осторожно
Devcontainer в VS Code — это удобно, но по модели угроз это тот же контейнер. Если внутри девконтейнера агент получает доступ к докер-сокету хоста (популярный способ «чтобы docker внутри работал»), изоляция сводится к нулю.
Граница вторая: microVM. Что сделал Docker
В апреле 2026 Docker выпустил Docker Sandboxes и утилиту sbx — обёртку, которая запускает агента в микровиртуалке, а не в контейнере. В августе продукт снова всплыл в топе Hacker News, поэтому уточню сразу: это не свежий релиз, инструмент живёт с весны.
Ключевое отличие от контейнера — своё ядро. Каждая песочница получает отдельную VM с собственным ядром, собственным сетевым стеком и собственным демоном Docker внутри. Побег требует уже не бага в syscall, а бага в гипервизоре — граница принципиально другого класса.
Любопытная часть — как это сделано кросс-платформенно. В инженерном блоге Docker прямо объясняют, почему не взяли Firecracker: тот «спроектирован для облачной инфраструктуры, конкретно для Linux/KVM окружений вроде AWS Lambda» и «не имеет нативной поддержки macOS или Windows, точка». Поэтому написали свой VMM, который использует родной гипервизор каждой ОС:
ОС
Гипервизор
macOS
Apple Hypervisor.framework
Windows
Windows Hypervisor Platform
Linux
KVM
Docker Desktop при этом не требуется — sbx ставится отдельно.
Установка: brew install docker/tap/sbx (macOS), winget install Docker.sbx (Windows), на Linux — через apt из репозитория Docker. Дальше sbx login и sbx run claude в каталоге проекта.
Что sbx реально умеет
Список подкоманд из официального CLI-референса — он же лучший индикатор того, на что инструмент рассчитан:
Команда
Зачем
sbx run <агент>
поднять песочницу и запустить агента в ней
sbx ls / sbx stop / sbx rm
список, остановка, удаление песочниц
sbx exec
выполнить команду внутри уже поднятой песочницы
sbx cp
перенести файлы между хостом и песочницей
sbx policy
allow / deny / check — сетевые ограничения
sbx secret
set, ls, rm, import — управление секретами отдельно от кода
Из коробки поддерживаются claude, codex, copilot, cursor, gemini, kiro, opencode, droid, docker-agent и просто shell. Сам sbx бесплатен, включая коммерческое использование; деньги берут за Docker AI Governance — централизованное применение сетевых, файловых и MCP-политик на все машины организации плюс аудит-логи. Для одиночки это не нужно, для команды из тридцати человек — как раз то, за что платят.
⚠️ Осторожно
Docker пишет, что «холодный старт быстрый», но конкретных цифр — миллисекунд старта, накладных расходов по памяти — в блоге нет. Это заявление вендора, а не измерение. Если для вас важно поднимать десятки песочниц параллельно, замеряйте сами; я подтверждённых бенчмарков не нашёл.
Четыре уровня, и во что каждый обходится
Вариант
Граница
Что переживёт побег
Цена
Агент на хосте
нет
ничего
0, но $HOME открыт целиком
Контейнер / devcontainer
namespaces, общее ядро
всё, кроме смонтированного и сокетов
почти 0, но docker-in-docker ломает модель
microVM (sbx, Firecracker, Lima)
своё ядро + гипервизор
хост целиком, кроме проброшенного каталога
секунды на старт, память под VM
Отдельная машина / VPS
физическая
вообще всё
деньги, задержка, сложность синка
✅ Как правильно
Практическое правило: если агент работает с одним репозиторием и не трогает прод — контейнера достаточно. Если вы включаете полную автономию, даёте доступ к докеру и уходите пить кофе — берите microVM. Если агент имеет доступ к продовым ключам — не берите ничего из этого списка, а уберите ключи.
Пять вещей, которые песочница не чинит
Секреты, которые вы сами передали. Агенту нужен токен GitHub, чтобы создать PR. Внутри песочницы он его видит. sbx secret управляет хранением, но не тем, что агент с секретом сделает.
Push в репозиторий. Изоляция файловой системы не мешает агенту запушить сломанный код. Отдельная ветка и обязательное ревью защищают тут лучше, чем гипервизор — на форуме есть разбор stacked PR как раз про дисциплину ревью.
MCP-серверы. Каждый подключённый MCP — это канал наружу, часто с собственной авторизацией. Песочница ограничивает процесс, а не права токена внутри MCP.
Цепочку поставок. Агент внутри изолированной VM всё так же выполняет npm install, и вредонос всё так же отработает — просто внутри VM. Если у вас там лежали креды, они утекли.
Сам проект. Каталог смонтирован на запись — иначе агент бесполезен. Единственная страховка здесь — git и бэкапы, а не изоляция.
🔒 Безопасность
Отдельный момент про приватность: у Docker Sandboxes требуется sbx login, то есть учётная запись Docker. Что именно уходит в телеметрию при использовании политик и governance — стоит проверить в вашей юрисдикции и политике компании до того, как вы прогоните через это внутренний код. Для чувствительных проектов автономный вариант — обычная локальная VM (Lima, multipass, чистый QEMU/KVM), без внешнего аккаунта.
Если не хочется зависеть от Docker
На Linux всё это собирается руками и бесплатно: qemu-system-x86_64 с -enable-kvm и прокинутым каталогом через virtiofs, или Lima, или обычный multipass. На macOS ту же роль играет Lima поверх vz. Дороже по возне на старте, зато без аккаунта и без вендора в цепочке. Если хочется совсем просто и вы согласны на границу уровня контейнера — берите обычный docker run с --network none там, где агенту сеть не нужна вовсе.
💬 Вопрос к сообществу
А вы даёте агенту полную автономию? И если да — что стоит между ним и вашим ~/.ssh: контейнер, виртуалка, отдельная машина или ничего? Интересны реальные конфиги, а не намерения.
Вы можете написать сейчас и зарегистрироваться позже.
Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.
Почти каждый, кто дал агенту порулить кодом дольше пяти минут, рано или поздно выключает подтверждения. Claude Code —
--dangerously-skip-permissions, Codex —--full-auto, дальше по списку. И это рационально: агент, который спрашивает разрешение на каждыйls, не экономит время, а сжигает его. Вопрос только в том, что стоит между этим агентом и вашей машиной.Обычно там не стоит ничего.
Что именно вы разрешаете
Агент в автономном режиме — это процесс с вашими правами, который сам решает, что выполнить в шелле. Он видит
~/.ssh,~/.aws,~/.config/gh, куки браузера, соседние рабочие репозитории и историю шелла. Не потому, что он злой, а потому что вы его так запустили: ваш uid, ваш $HOME.Дальше достаточно одной из трёх вещей: агент неверно понял задачу и выполнил
rm -rfне в том каталоге; в контекст попала инструкция из внешнего источника (issue на GitHub, README зависимости, содержимое веб-страницы) и агент её исполнил; агент поставил пакет, у которого вpostinstallлежал не тот код. Третий сценарий на форуме уже разбирали — червь Shai-Hulud в npm собирал токены именно так.❗ Главное
Изоляция агента решает ровно одну задачу: ограничить радиус поражения, когда агент сделает не то. Она не делает агента умнее и не защищает от того, что он испортит сам проект, к которому вы дали ему доступ.
Граница первая: контейнер. Что он держит
Самый частый ответ — «запусти в докере». Он рабочий, но полезно понимать, где именно проходит граница.
Контейнер — это процесс на вашем ядре, отделённый namespaces (PID, mount, net, user) и ограниченный cgroups, seccomp и capabilities. Файловая система изолирована, сеть изолирована, чужие процессы не видны. Для «агент случайно удалил каталог» этого достаточно: он удалит его внутри контейнера.
Чего контейнер не держит:
-v /var/run/docker.sock:/var/run/docker.sock— это root на хосте одной командой.--privileged— то же самое. А агенту часто нужен докер: он хочет собрать образ, поднять базу, прогнать интеграционные тесты.⚠️ Осторожно
Devcontainer в VS Code — это удобно, но по модели угроз это тот же контейнер. Если внутри девконтейнера агент получает доступ к докер-сокету хоста (популярный способ «чтобы docker внутри работал»), изоляция сводится к нулю.
Граница вторая: microVM. Что сделал Docker
В апреле 2026 Docker выпустил Docker Sandboxes и утилиту
sbx— обёртку, которая запускает агента в микровиртуалке, а не в контейнере. В августе продукт снова всплыл в топе Hacker News, поэтому уточню сразу: это не свежий релиз, инструмент живёт с весны.Ключевое отличие от контейнера — своё ядро. Каждая песочница получает отдельную VM с собственным ядром, собственным сетевым стеком и собственным демоном Docker внутри. Побег требует уже не бага в syscall, а бага в гипервизоре — граница принципиально другого класса.
Любопытная часть — как это сделано кросс-платформенно. В инженерном блоге Docker прямо объясняют, почему не взяли Firecracker: тот «спроектирован для облачной инфраструктуры, конкретно для Linux/KVM окружений вроде AWS Lambda» и «не имеет нативной поддержки macOS или Windows, точка». Поэтому написали свой VMM, который использует родной гипервизор каждой ОС:
Docker Desktop при этом не требуется —
sbxставится отдельно.Официальная иллюстрация Docker Sandboxes. Источник: docker.com
ℹ️ Справка
Установка:
brew install docker/tap/sbx(macOS),winget install Docker.sbx(Windows), на Linux — через apt из репозитория Docker. Дальшеsbx loginиsbx run claudeв каталоге проекта.Что
sbxреально умеетСписок подкоманд из официального CLI-референса — он же лучший индикатор того, на что инструмент рассчитан:
sbx run <агент>sbx ls/sbx stop/sbx rmsbx execsbx cpsbx policysbx secretsbx mcpsbx portssbx templatesbx tuiИз коробки поддерживаются
claude,codex,copilot,cursor,gemini,kiro,opencode,droid,docker-agentи простоshell. Самsbxбесплатен, включая коммерческое использование; деньги берут за Docker AI Governance — централизованное применение сетевых, файловых и MCP-политик на все машины организации плюс аудит-логи. Для одиночки это не нужно, для команды из тридцати человек — как раз то, за что платят.⚠️ Осторожно
Docker пишет, что «холодный старт быстрый», но конкретных цифр — миллисекунд старта, накладных расходов по памяти — в блоге нет. Это заявление вендора, а не измерение. Если для вас важно поднимать десятки песочниц параллельно, замеряйте сами; я подтверждённых бенчмарков не нашёл.
Четыре уровня, и во что каждый обходится
sbx, Firecracker, Lima)✅ Как правильно
Практическое правило: если агент работает с одним репозиторием и не трогает прод — контейнера достаточно. Если вы включаете полную автономию, даёте доступ к докеру и уходите пить кофе — берите microVM. Если агент имеет доступ к продовым ключам — не берите ничего из этого списка, а уберите ключи.
Пять вещей, которые песочница не чинит
Секреты, которые вы сами передали. Агенту нужен токен GitHub, чтобы создать PR. Внутри песочницы он его видит.
sbx secretуправляет хранением, но не тем, что агент с секретом сделает.Push в репозиторий. Изоляция файловой системы не мешает агенту запушить сломанный код. Отдельная ветка и обязательное ревью защищают тут лучше, чем гипервизор — на форуме есть разбор stacked PR как раз про дисциплину ревью.
MCP-серверы. Каждый подключённый MCP — это канал наружу, часто с собственной авторизацией. Песочница ограничивает процесс, а не права токена внутри MCP.
Цепочку поставок. Агент внутри изолированной VM всё так же выполняет
npm install, и вредонос всё так же отработает — просто внутри VM. Если у вас там лежали креды, они утекли.Сам проект. Каталог смонтирован на запись — иначе агент бесполезен. Единственная страховка здесь — git и бэкапы, а не изоляция.
🔒 Безопасность
Отдельный момент про приватность: у Docker Sandboxes требуется
sbx login, то есть учётная запись Docker. Что именно уходит в телеметрию при использовании политик и governance — стоит проверить в вашей юрисдикции и политике компании до того, как вы прогоните через это внутренний код. Для чувствительных проектов автономный вариант — обычная локальная VM (Lima, multipass, чистый QEMU/KVM), без внешнего аккаунта.Если не хочется зависеть от Docker
На Linux всё это собирается руками и бесплатно:
qemu-system-x86_64с-enable-kvmи прокинутым каталогом через virtiofs, или Lima, или обычный multipass. На macOS ту же роль играет Lima поверхvz. Дороже по возне на старте, зато без аккаунта и без вендора в цепочке. Если хочется совсем просто и вы согласны на границу уровня контейнера — берите обычныйdocker runс--network noneтам, где агенту сеть не нужна вовсе.💬 Вопрос к сообществу
А вы даёте агенту полную автономию? И если да — что стоит между ним и вашим
~/.ssh: контейнер, виртуалка, отдельная машина или ничего? Интересны реальные конфиги, а не намерения.Источники
sbxTOP HOSTERS: KAMATERA (30 дней бесплатного теста!)
Универсальный хостер №1 - 4VPS.su (2Гб\с сервера) - 10% скидка на первый заказ или 15% бонус на первое пополнение