Агент генерирует команду и тут же её исполняет. Ревью нет, границы — общие. В феврале 2026 консенсус практиков прямой: Docker/runc для такого кода недостаточно. Побег из контейнера — вопрос времени, а цена — хост, секреты и сеть. Песочница делает побег дорогим, а сброс — дешёвым.
Почему Docker не подходит для кода агента
Контейнер делит ядро хоста. Агент видит тот же syscall ABI, отфильтрованный seccomp, но всё ещё единое ядро. Инциденты 2025–2026 — ROME (агент вышел из теста и майнил на GPU), CVE-2026-25049 в n8n (CVSS 10.0, sandbox escape), 21k открытых OpenClaw — показывают: shared-kernel для untrusted кода не граница, а фильтр.
Нужна не фильтрация, а второе ядро — пользовательское (gVisor) или гостевое (microVM).
4 примитива изоляции
| Технология | Механизм | Boot | Overhead | Граница | Когда |
|---|---|---|---|---|---|
| Docker (runc) | namespaces + cgroup | ~10 мс | ~10 МБ | shared kernel | только trusted код |
| gVisor (runsc) | userspace kernel Sentry, перехват syscalls | ~100 мс | ~20 МБ | нет прямого host syscall | compute-задачи, есть Kubernetes |
| Firecracker | KVM microVM, свой guest kernel | ~125 мс | ~5 МБ | hardware (KVM) | untrusted код, максимум изоляции |
| Kata Containers | microVM за container API | ~200 мс | ~30 МБ | hardware | Kubernetes-native, нужен K8s |
| Wasm/WASI, V8 isolates | capability, нет syscall ABI | <1 мс | <1 МБ | runtime | bounded tool, без shell |
gVisor реализует ядро в Go и пропускает через Sentry только 53–68 host syscalls. Firecracker — минимальный VMM AWS (Lambda/Fargate) с <5 МБ на VM и 150 VM/сек на хост, свой процесс зажат в 24 syscalls. Выбор — ставка на разный код: Sentry vs KVM+VMM.
Kubernetes agent-sandbox — жизненный цикл отдельно от изоляции
В ноябре 2025 SIG Apps выпустил kubernetes-sigs/agent-sandbox — контроллер, который развёл жизненный цикл и выбор изоляции:
Sandbox— изолированная сессия с постоянным ID и диском;SandboxTemplate— шаблон с лимитами, политиками, бэкендом (gVisor/Kata/обычный);SandboxClaim— заявка оркестратора без знания бэкенда.
Один и тот же SandboxTemplate может указывать на gVisor сегодня и на Kata завтра. GKE уже имеет gke.io/agent-sandbox (март 2026), Kata — официальную интеграцию.
3 паттерна жизненного цикла
- Ephemeral session VM — boot → run → destroy. Просто, надёжно, без состояния между задачами.
- Snapshot cloning — golden VM → snapshot → clone per session. 28 мс через copy-on-write, быстрый reset.
- Pool of paused VMs — держать пачку приостановленных VM, resume по требованию. Сложнее, но ниже хвост latency.
Выбор зависит от частоты задач: короткие tool calls — Cloudflare V8 isolates (<1 мс), долгие сессии — Firecracker с snapshot.
Что выбрать
- Код извне или от LLM без ревью → Firecracker / Kata. gVisor допустим только как компромисс.
- Уже в Kubernetes и нужна совместимость → gVisor (
runsc), потомagent-sandbox. - Capability-скоуп без shell → Wasm/WASI.
- В любом случае: per-sandbox лимиты (CPU/mem/disk/net), deny-all egress по умолчанию с allowlist, ephemeral на задачу, брокер секретов вне песочницы.
Где Codenik
Codenik не заменяет песочницу, а делает её эффективной: агент не трогает хост напрямую. Вызов идёт агент → Codenik gateway → MCP-сервер в sandbox. Секреты живут в gateway, не в песочнице; сеть — deny-by-default; каждый tools/call и сброс песочницы — в аудите. Песочница ловит побег, gateway — лишние права.
Короткий вывод
Для кода агента Docker — не песочница, а упаковка. Берите gVisor как минимум, Firecracker/Kata как дефолт для untrusted, отделяйте жизненный цикл через agent-sandbox. Тогда сброс стоит миллисекунды, а побег — две уязвимости подряд.