Docker объявила о передаче спецификации Sandbox Kit в CNCF, превратив права доступа ИИ-агентов в переносимый артефакт. Спецификация под лицензией Apache 2.0, сейчас в версии v3, упаковывает агента, его инструменты и типизированный список запрошенных хостов, учетных данных и томов в обычный OCI-образ. Об этом объявлено на WeAreDevelopers 24 сентября. Смысл для бизнеса прост: права доступа перестают храниться в истории команд и панелях и становятся проверяемым пакетом.
Как Sandbox Kit v3 упаковывает разрешения
В версии v3 Kit больше не является отдельным типом артефакта, у него нет собственного media type и нет sidecar-файла. Манифест содержит одну декларацию vnd. docker. sandbox. kit. descriptor, поэтому работают привычные операции. Kit можно собрать командой docker buildx build, получить через docker pull, а также сканировать, подписывать и использовать в инструкции FROM. Фиксация дайджеста одновременно фиксирует содержимое и разрешения, что упрощает аудит и контроль версий.
Разрешения выражены типизированными версионированными возможностями, например com. docker. sandbox/network-policy@2 и com. docker. sandbox/credential@1. В примере GitHub CLI из спецификации разрешен api. github. com, но запрещен DELETE для /repos/**, причем запрет имеет приоритет. Для учетных данных поддерживается прокси-управление: соответствующий runtime подставляет реальный токен в запросы к указанным доменам, а внутри песочницы находится только sentinel-значение. Такое устройство не дает секретам попасть в среду агента.
Контекст — разрозненность прав агентов. Такие агенты, как Claude Code и Codex, устанавливают пакеты, вызывают API и используют учетные данные от имени пользователей, а bind mounts, широкие токены и открытые правила firewall остаются разбросанными. Docker считает, что это повторяет проблему, ради которой создавался OCI, когда каждый поставщик runtime может придумать собственный ответ. Компания проводит параллель с передачей формата образов и runc, из которых вырос OCI, а CTO CNCF Chris Aniszczyk назвал подход открытым и воспроизводимым способом поставки агента с ограничениями.
Что это меняет для компаний, запускающих агентов
Запуск объединяет один workload Kit с корневой файловой системой и любое число mixin-оверлеев, упорядоченных по графу зависимостей provides и requires, а не по порядку флагов. Разрешение завершается ошибкой, если requires не выполнено или два Kit предоставляют одно имя, а пересекающиеся декларации согласуются, при этом сетевые правила объединяются. Для эксплуатационных команд это означает компонуемые окружения с предсказуемыми отказами вместо скрытых конфликтов, хотя корректное описание зависимостей становится новой обязанностью.
Kit только запрашивает разрешения, а решение принимает хост. Без соответствующего runtime аннотация не действует, а если обязательный запрос нельзя удовлетворить, запуск отклоняется. Каждый дескриптор сводится к нормализованному набору грантов, поэтому runtime с контролем обновлений может сохранить этот набор и остановить любую версию, которая его расширяет, включая удаление запрета. К спецификации прилагаются два набора conformance-тестов, для артефактов Kit и для runtime, что дает заказчикам конкретные вопросы о проверке исполнения.
Индикатором развития станет принятие в программу CNCF и появление второго соответствующего runtime помимо Docker Sandboxes, который запускает агентов в microVM с собственным ядром. В публикациях не указаны статус принятия и уровень зрелости, а переносимость между runtime пока не продемонстрирована. Docker сообщает о создании Kit совместно с AWS, Box, Datadog, Dynatrace, JFrog, NanoClaw, OpenClaw, Palo Alto Networks и Snyk, а примеры можно проверить через sbx CLI. До изменения управления спецификация ведется Docker в репозитории docker/sandbox-kit-spec.
