Google Cloud представила управляемый сервис GKE Agent Sandbox, в то время как open-source проект kubernetes-sigs/agent-sandbox предоставляет ту же возможность любому кластеру Kubernetes. Оба решения предоставляют разработчикам одноразовый Linux-контейнер для ИИ-агентов, не затрагивая остальную инфраструктуру.
Почему коду, созданному ИИ, нужна «песочница»
Современные ИИ-агенты не просто отвечают на вопросы. Они пишут скрипты, просматривают веб-страницы, выполняют shell-команды и даже запускают веб-сервисы. Такая мощь создает брешь в безопасности: код, который они выдают, может быть с ошибками, вредоносным или чрезмерно агрессивным. Агент, который выполнит rm -rf / или подключится к внутренней базе данных без разрешения, может скомпрометировать всю систему.
Песочница изолирует каждого агента в собственном контейнере — крошечной, одноразовой виртуальной машине. Если агент поведет себя неправильно, ущерб останется внутри этого контейнера; хост и другие рабочие нагрузки останутся в безопасности. Новое предложение GKE и проект, поддерживаемый сообществом, превращают эту идею в готовый к использованию сервис.
Два способа получить песочницу
- GKE Agent Sandbox — полностью управляемый сервис для клиентов Google Cloud.
kubernetes-sigs/agent-sandbox— open-source проект для любого кластера Kubernetes.
Оба решения имеют общую базовую архитектуру, построенную на стандартных примитивах Kubernetes.
Как устроена система
| Компонент | Роль |
|---|---|
| Sandbox | Изолированный контейнер, в котором выполняется код агента. Он имеет стабильное имя и, при необходимости, постоянное хранилище. |
| SandboxTemplate | Шаблон, определяющий образ контейнера и политики безопасности — «рецепт» для создания новых песочниц. |
| SandboxClaim | Запрос, отправляемый агентом (или его контроллером) для развертывания песочницы по конкретному шаблону. |
| SandboxWarmPool | Пул заранее созданных песочниц, готовых к мгновенной выдаче. Поддержание контейнеров в «горячем» состоянии позволяет избежать задержек, связанных с загрузкой образов и запуском нового пода каждый раз. |
Когда агенту требуется среда, он отправляет SandboxClaim. Контроллер проверяет теплый пул (warm pool), выбирает свободную песочницу и привязывает ее к запросу. Если пул пуст, создается новая песочница по шаблону; в противном случае передача происходит за миллисекунды.
Настройки безопасности, которыми можно управлять
- Default-deny networking — По умолчанию песочница не имеет доступа к внутренней сети. Вам необходимо добавить явные правила для разрешения исходящих или входящих соединений, что предотвращает случайное раскрытие внутренних сервисов.
- Уровни изоляции — Выберите среду выполнения контейнеров (container runtime), соответствующую вашему уровню допустимого риска:
- Стандартные контейнеры для скорости,
- gVisor для дополнительного уровня изоляции в пользовательском пространстве (user-space), или
- Kata Containers для изоляции с аппаратной поддержкой, которая работает как легковесная виртуальная машина.
- SDK — Клиентские библиотеки на Python и Go позволяют разработчикам программно создавать, запрашивать и удалять песочницы, что вписывается в рабочий процесс конвейеров (pipelines) на базе ИИ.
Кому это выгодно, а кто может быть против
Итог
Предоставление ИИ-агентам собственного одноразового Linux-окружения устраняет главный фактор неопределенности в автоматизации на базе ИИ: риск того, что сгенерированный код разрушит хост. Управляемый сервис GKE Agent Sandbox от Google Cloud и проект kubernetes-sigs/agent-sandbox, поддерживаемый сообществом, делают такую изоляцию практичной как для облачных (cloud-native), так и для локальных (on-prem) сред. Организации, которым необходимо соблюдать баланс между гибкостью и безопасностью, теперь имеют конкретный, нативный для Kubernetes инструмент, позволяющий держать код, созданный ИИ, в безопасной «песочнице».