Docker готовит отдельную инфраструктуру для AI-агентов

Пока AI-агент просто пишет код по команде разработчика, привычной инфраструктуры вроде Docker вполне хватает. Но ситуация меняется, когда агент начинает работать самостоятельно.

Он может установить пакет, запустить команду, изменить десятки файлов, обратиться к API, воспользоваться токеном, поднять сервис и продолжить работу уже после того, как разработчик закрыл ноутбук.

И тут возникает неприятный вопрос: где вообще должен работать такой агент и что ему разрешено делать?

Docker теперь пытается решить эту проблему не очередным инструментом для контейнеров, а отдельным инфраструктурным слоем.

24 сентября компания представила Docker Cloud Sandboxes - облачную среду для запуска AI-агентов, которые могут работать часами без привязки к компьютеру разработчика. Одновременно Docker представила новую версию Sandbox Kit Specification, в которой окружение агента, его инструменты и разрешения описываются как OCI-образ.

Именно вторая часть выглядит наиболее интересной.

Контейнера для агента уже недостаточно

Обычный контейнер хорошо подходит для заранее определённого приложения.

Мы знаем, какой процесс он запускает, какие порты ему нужны, какие директории подключены и к каким сервисам он обращается. В идеальном случае всё это можно описать в Dockerfile и конфигурации.

AI-агент устроен иначе.

Разработчик может сказать ему: «разберись, почему падают тесты». Дальше агент сам решает, какие файлы открыть, какие команды выполнить, какие зависимости установить и куда отправить запрос.

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

Docker уже несколько месяцев двигается именно в сторону изолированного выполнения агентов. В январе компания представила Sandboxes на базе microVM: агент получает отдельное окружение с собственным ядром, а его действия не должны напрямую затрагивать хостовую систему.

Но здесь обнаружилась ещё одна проблема.

Изолировать агента мало. Нужно ещё понимать, какие полномочия он получает внутри этой изоляции.

Допустим, агент находится в отдельной виртуальной машине. Это уже лучше, чем запускать его непосредственно на рабочем компьютере. Но ему всё равно могут понадобиться GitHub, база данных, MCP-сервер, определённые файлы, сетевые адреса и секреты.

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

Что именно разрешено этому агенту?

Docker предлагает вынести ответ на этот вопрос непосредственно в артефакт, который запускается.

Docker превращает разрешения в отдельный объект

Новая Sandbox Kit Specification описывает Kit как обычный OCI-образ.

Внутри него можно описать самого агента, необходимые инструменты и то, к каким ресурсам он должен иметь доступ. Причём речь идёт не только о файловой системе.

В спецификации предусмотрены, например, сетевые правила, credentials, volumes, порты и другие capabilities. Docker также разделяет Kits на workload и mixin: первый задаёт основное окружение, а второй позволяет добавлять отдельные возможности поверх него.

На практике идея выглядит довольно просто.

Представим агента, которому нужно работать с GitHub. Ему может быть разрешён доступ к github.com и api.github.com, но при этом некоторые операции можно запретить.

Получается уже не абстрактное «агенту разрешён GitHub», а гораздо более конкретное описание его полномочий.

И это важный сдвиг.

Раньше разработчик в основном описывал как запустить программу.

Теперь для AI-агента приходится описывать ещё и что программе разрешено делать после запуска.

Почему Docker выбрала OCI

Самое интересное здесь даже не сама идея Sandbox Kit.

Docker могла бы сделать собственный формат конфигурации и отдельный каталог для таких окружений. Но компания пошла другим путём: Kit оформляется как обычный OCI image.

Это означает, что для его сборки и распространения можно использовать знакомую экосистему контейнеров. Docker прямо указывает, что Kit можно собирать через docker buildx, хранить в registry, подписывать и сканировать существующими инструментами.

Получается довольно понятная схема.

Dockerfile отвечает за содержимое приложения.

Kit добавляет к агенту описание его полномочий.

И это уже больше похоже не на ещё один Docker-файл, а на попытку создать общий формат для AI-инфраструктуры.

Особенно показателен подход к версиям.

Если новая версия Kit внезапно начинает требовать дополнительный домен, credential или volume, это становится изменением самого артефакта. Разницу можно увидеть при обновлении и проверить до запуска.

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

Cloud Sandboxes решают другую половину проблемы

Параллельно Docker представила Cloud Sandboxes.

Здесь проблема уже не столько в том, что может делать агент, сколько в том, где ему работать, если задача занимает несколько часов.

Раньше разработчик мог запустить агента на ноутбуке, оставить его выполнять большой рефакторинг или миграцию и ждать результата.

Но ноутбук - не сервер.

Он может перейти в сон, потерять сеть или просто понадобиться самому разработчику.

Cloud Sandboxes позволяют перенести тот же принцип из локальной среды в облако Docker. Компания описывает их как microVM-окружения на управляемых вычислительных ресурсах. При этом идея состоит в том, чтобы локальный sandbox и облачный sandbox использовали одну модель изоляции.

Запуск может выглядеть как продолжение локальной работы, а не как отдельный DevOps-проект.

Например, агент начал работу на компьютере разработчика, а затем задачу, которая должна выполняться ещё несколько часов, можно продолжить в облаке.

Docker прямо связывает это с новым типом задач для агентов: большой рефакторинг, миграция зависимостей, длительный прогон тестов и другие операции, где человеку необязательно сидеть рядом всё время.

Здесь появляется ещё одна важная деталь - секреты

У автономного агента почти всегда возникает проблема с credentials.

Если положить API-ключ непосредственно внутрь окружения, агент потенциально получает доступ к самому секрету. Если передавать ключ через переменные окружения, он также оказывается внутри среды выполнения.

Docker предлагает другой подход для Cloud Sandboxes: секрет хранится вне sandbox, а нужное значение проксируется при обращении агента к разрешённому сервису.

То есть агенту не обязательно знать сам секрет, чтобы воспользоваться сервисом.

Docker отдельно описывает эту модель для Cloud Sandboxes: ключи или токены хранятся вне окружения, а proxy inject передаёт их при соответствующем запросе.

Для AI-агентов это особенно интересно из-за prompt injection.

Если агент никогда не получил реальный секрет в свою среду, одна вредоносная инструкция внутри документа или ответа MCP-сервера не может просто вывести этот секрет через обычный доступ к файловой системе.

Конечно, это не делает всю систему автоматически безопасной. Но граница становится гораздо понятнее: агенту дают возможность пользоваться ресурсом, не обязательно отдавая ему сам credential.

Docker пытается сделать разрешения переносимыми

Вот здесь новая архитектура начинает выглядеть серьёзнее обычного облачного продукта.

Docker не хочет, чтобы Sandbox Kit оставался исключительно внутренним форматом Docker Sandboxes.

24 сентября компания объявила, что передаёт спецификацию в CNCF. Сам формат распространяется как open source под Apache 2.0, а идея состоит в том, чтобы в дальнейшем спецификация находилась под нейтральным управлением.

Логика понятна.

Если каждый производитель AI-агентов создаст собственную систему разрешений, разработчикам придётся изучать отдельные модели безопасности для каждого инструмента.

Сегодня один агент понимает свои policy-файлы, другой - собственные permissions, третий использует ещё какую-нибудь конфигурацию.

Docker предлагает другой вариант: агент и его полномочия должны описываться переносимым артефактом.

В этом смысле аналогия с контейнерами вполне очевидна.

OCI сделал контейнерные образы переносимыми между разными инструментами и инфраструктурами. Docker теперь пытается добиться похожего эффекта для AI-агентов, только переносить нужно не только окружение, но и набор разрешений.

Docker формулирует это ещё жёстче: контейнеры сделали программное обеспечение воспроизводимым, а Kits должны сделать воспроизводимыми полномочия агента.

Почему это появилось именно сейчас

Ещё недавно AI-агент в разработке был скорее помощником.

Он предложил код - человек его проверил.

Написал команду - человек запустил.

Нашёл ошибку - человек решил, что делать дальше.

Сейчас модель работы постепенно меняется.

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

Docker сама использует подобную модель. В мае компания рассказывала о собственной виртуальной команде из нескольких AI-агентов, которые тестируют продукт, разбирают issues, готовят release notes и исправляют ошибки в CI. Каждый агент работает в sandbox.

При таком сценарии безопасность уже нельзя свести к вопросу «доверяем ли мы модели».

Модель может ошибиться. Может неправильно понять задачу. Может получить вредоносный контекст. Может выполнить неожиданную команду.

Поэтому всё большее значение имеет не идеальное поведение агента, а то, что произойдёт, если он поведёт себя не так, как ожидалось.

Именно здесь microVM, сетевые ограничения, прокси для секретов и описываемые в Kit полномочия складываются в одну систему.

Это ещё не готовый стандарт для всего рынка

При этом есть важный момент, который легко потерять за громкими формулировками.

Docker пока не создала универсальную инфраструктуру, которую автоматически поддерживает весь рынок.

Sandbox Kit Specification только передаётся в CNCF. Docker Sandboxes выступает первой реализацией, которая обеспечивает описанное поведение. Для других runtime ещё предстоит реализовать совместимость со спецификацией.

То есть сейчас это скорее ставка на направление развития, чем устоявшийся стандарт.

Но сама постановка проблемы выглядит своевременно.

Когда AI-агент просто генерирует текст, вопрос его полномочий почти не возникает.

Когда он получает shell, файловую систему, сеть, credentials и возможность самостоятельно принимать следующие шаги - ситуация становится совершенно другой.

Тогда недостаточно написать:

//text

Запусти агента.

Нужно ещё иметь возможность ответить:

//text

Какие файлы он видит?
Какие команды может выполнять?
К каким доменам обращается?
Какие секреты получает?
Какие операции запрещены?
Что произойдёт при обновлении его окружения?

И желательно, чтобы ответы на эти вопросы не жили в голове одного DevOps-инженера или в нескольких забытых конфигурационных файлах.

Docker меняет саму единицу инфраструктуры

Для меня здесь самая интересная часть анонса не Cloud Sandboxes как облачный сервис.

Облако - понятный следующий шаг для агентов, которым нужно работать дольше локальной сессии.

Гораздо интереснее появление идеи агент + окружение + полномочия как одного переносимого объекта.

Это уже другой взгляд на инфраструктуру.

Обычный контейнер говорит:

Вот программа и всё, что ей нужно для запуска.

Sandbox Kit пытается сказать:

Вот агент, его инструменты и конкретный набор возможностей, которые ему разрешено получить.

Если такая модель действительно приживётся, разработчику станет проще не только запускать агентов, но и проверять их перед запуском.

Появится возможность посмотреть на Kit примерно так же, как сейчас смотрят на Dockerfile или зависимости проекта: что добавилось, какие права появились, к каким сервисам теперь есть доступ.

И именно здесь Docker делает ставку на OCI.

Похоже, компания понимает, что рынок AI-агентов очень быстро движется от отдельных помощников к автономным системам. А когда таких систем станет много, главным вопросом будет уже не только качество моделей.

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

И Docker пытается занять этот инфраструктурный слой ещё до того, как для него окончательно сформируется единый стандарт.