Как OpenShell защищает кластер от ошибок ИИ‑агента

Все повсеместно внедряют ИИ‑агентов где надо и где нет. Периодически сеть развлекают новости о том, как очередной из них сначала выполняет rm -fr /* или что‑то в этом роде, а потом пишет: «Извините, я все удалил. Хотите помогу начать проект с чистого листа?»  

Решение напрашивается само собой: ограничивать возможности агентов, чтобы те не выходили за рамки безопасных API-вызовов. Ведь по сути, каждый агент — это недоверенный код, обладающий реальными доступами. И вот, NVIDIA инициировала проект OpenShell, который сейчас развивается в инкубаторе CNCF Sandbox.

Как OpenShell контролирует агентов

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

1. Файловая система — механизм Landlock ограничивает пути на чтение и запись. Например, директории /usr и /etc доступны только для чтения, а запись разрешена исключительно в /sandbox, /tmp и /dev/null.
2. Процессы — перед стартом песочница принудительно переключает процесс на обычного пользователя, отзывает все системные привилегии Linux (capabilities) и применяет профиль seccomp.
3. Сеть — весь исходящий трафик запрещен по умолчанию, а разрешения выдаются точечно: для конкретного выполняющегося файла, хоста, порта, HTTP-метода.
4. Учетные данные — внутри песочницы видны лишь заглушки (placeholders). Супервизор подменяет их на реальные API-ключи «на лету» и строго для разрешенных эндпоинтов.

В отличие от многих аналогов, OpenShell не тащит за собой кастомный планировщик. Внутри работает Agent Sandbox (ресурс agents.x-k8s.io от SIG Apps).

Очень существенная особенность — гранулярность. Обычная NetworkPolicy может дать поду полный доступ к api.github.com по порту 443, но не способна, скажем, утилите curl разрешить только читать, но не создавать задачи, тикеты или баг‑репорты. OpenShell не просто умеет это делать, но позволяет обновлять правила без перезапуска контейнера.

Архитектура и жизненный цикл

Взаимодействие с кластером идет не через Kubernetes API, а через шлюз OpenShell по протоколу двусторонней аутентификации mTLS, который не позволит злоумышленнику отправить вредоносную команду на открытый порт шлюза. В сообществе уже обсуждается вопрос по реализации CRD-оператора, но пока точкой входа остается именно Gateway.

Жизненный цикл выглядит так.

1. Шлюз валидирует запрос, разрешает параметры и сохраняет состояние. Драйвер создает базовые сетевые политики в неймспейсе: одна полностью блокирует исходящий трафик для пода агента (разрешая только входящий TCP 5500 от супервизора), вторая регулирует сам супервизор.
2. Создается ресурс Sandbox в приостановленном состоянии, после чего контроллер Agent Sandbox поднимает рабочий под и PVC для директории /sandbox. Под удерживается через шлюз планирования (scheduling gate).
3. OpenShell проверяет параметры созданного пода — ожидаемые UID и GID, профиль seccomp, отсутствие монтирования токенов ServiceAccount. Если мутирующие вебхуки нарушили требования безопасности — процесс прерывается с откатом изменений.
4. Драйвер создает под супервизора, сервис, необходимые секреты и выдает супервизору краткосрочный токен.
5. Супервизор подключается к поду агента и передает конфигурацию. Команды агента не стартуют до подтверждения всех ограничений на уровне ОС.
6. Все исходящие запросы, запуски, подключения по SSH, логи, синхронизация файлов и прочее — идут исключительно через супервизор.

OpenShell или Agent Substrate

В сентябре 2026 года CNCF принял в песочницу сразу два инструмента для ограничения возможностей ИИ-агентов: OpenShell от NVIDIA и Agent Substrate от Google. Их архитектуры принципиально отличаются, так как решают разные задачи.

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

Agent Substrate решает проблему плотности — как дешево запустить тысячи простаивающих агентов. Проект использует собственный планировщик, пулы воркеров и приостанавливает неактивные рабочие нагрузки в защищенных средах gVisor или Cloud Hypervisor. Подмена учетных данных здесь реализована на уровне общего шлюза исходящего трафика (egress gate).

В будущем эти подходы можно будет объединять, хотя для этого еще предстоит согласовать множество вопросов.

Защита периметра с Kyverno и быстрый старт

OpenShell валидирует только критичные для себя настройки пода, оставляя выбор образов и ресурсов на откуп платформенной команде. Базового RBAC здесь недостаточно: не исследуется само содержимое запросов — не запрещаются опасные конфигурации.

На этом этапе подключается Kyverno — нативный движок политик (policy engine) для Kubernetes, разрабатываемый компанией Nirmata. Его задача — проверять запросы к Kubernetes API с помощью CEL-политик. Эти валидации применяются ко всем учетным записям, включая сервисный аккаунт самого Gateway, защищая кластер даже в случае компрометации шлюза.

В перспективе безопасность можно усилить с помощью DaemonSet-агентов, которые через eBPF (то есть, выполняясь прямо в ядре Linux) будут отслеживать несанкционированные запуски CLI-утилит (claude, ollama), обращения к моделям .gguf и DNS-запросы к серверам ИИ‑провайдеров, сохраняя отчеты прямо в неймспейсе.

Как пощупать

Для тестирования разработчики Nirmata подготовили демо-репозиторий. Полный цикл работы разворачивается на базе Kubernetes 1.35 с использованием Cilium 1.20, Agent Sandbox v1.0.5, OpenShell 0.1.3 и Kyverno 1.18.2.

Понадобятся Docker, kind, kubectl, Helm, curl, SSH и nc. Все просто: поднимается кластер и запускается демо:

      git clone https://github.com/nirmata/demo-openshell

cd demo-openshell

./scripts/setup.sh && ./scripts/install-cli.sh && ./scripts/verify.sh

./scripts/demo.sh           # L7-политики OpenShell
./scripts/kyverno-demo.sh   # Admission-политики Kyverno
./scripts/cleanup.sh        # Удаление демо-ресурсов