AIREITER

Обзор NVIDIA OpenShell: более безопасная среда для AI-агентов, но не без ограничений

Последнее обновление: 2026-09-29 00:48:37

Агент для программирования, который может редактировать файлы, устанавливать пакеты и обращаться к API, нельзя надежно ограничить одной инструкцией в системном промпте. NVIDIA OpenShell выносит эти разрешения за пределы самого агента и помещает его в изолированную среду с политиками безопасности. Но самая сложная часть по-прежнему остается на вашей стороне: нужно описать политики без пробелов и проверить, как именно все это работает в конкретном развертывании.

Коротко: OpenShell — это граница изоляции, а не фреймворк для агентов

NVIDIA OpenShell — среда выполнения с открытым исходным кодом для автономных агентов. В документации ветки 0.1.x описаны Gateway, отдельный Supervisor для каждой песочницы, ограничения файловой системы и процессов на уровне ядра, контролируемый сетевой доступ, привязка учетных данных и инструменты для проверки политик. По словам NVIDIA, опубликованным в техническом блоге 28 сентября 2026 года, OpenShell позволяет изолировать такие агенты, как Codex и Claude Code, не переписывая их (NVIDIA Technical Blog).

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

Документация NVIDIA OpenShell с рекомендациями по безопасности

Что именно контролирует OpenShell

OpenShell разделяет управление инфраструктурой и рабочую нагрузку. Gateway управляет песочницами и политиками, Supervisor посредничает во внешних запросах, а Sandbox запускает агента с ограничениями на уровне операционной системы (NVIDIA Technical Blog).

УровеньЧто защищаетМожно ли изменить во время работы?
Файловая системаФайлы и каталогиНет; песочницу нужно создать заново
ПроцессыПрава и поведение системных вызововНет; песочницу нужно создать заново
СетьХосты, порты, бинарные файлы и отдельные операции APIДа
Учетные данные провайдеровСекреты, используемые на разрешенных конечных точкахДа

OpenShell применяет политики ниже уровня приложения и хранит переиспользуемые учетные данные отдельно от агента, добавляя их только к разрешенным запросам (OpenShell README).

«OpenShell — это безопасная и приватная среда выполнения для флотов автономных AI-агентов». — README NVIDIA OpenShell (источник)

Главная сила OpenShell — на границе изоляции, а главное слабое место — в проектировании политик

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

Файловая система, процессы и сеть: все ограничения в одной схеме

В актуальном руководстве по безопасности описаны Landlock для контроля доступа к файловой системе, seccomp и отказ от привилегий для ограничения процессов, а также CONNECT-прокси с проверкой политик через OPA для исходящего трафика (OpenShell Security Best Practices). Пути к файлам, не внесенные в список разрешенных, недоступны, исходящий трафик по умолчанию блокируется, а сетевые правила можно привязать к идентификатору конкретного бинарного файла.

Сетевые правила могут проверять не только хост и порт. Политики REST анализируют методы и пути, политики GraphQL — операции и корневые поля, а политики WebSocket — рукопожатия и сообщения. Компромисс очевиден: широкие правила проще поддерживать, узкие — проще защищать и проверять.

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

Учетные данные контролируются, но не становятся безопасными сами по себе

Посредничество при работе с учетными данными сокращает область их раскрытия, но не делает слишком широкую конечную точку безопасной. Политика API только для чтения может сузить возможности учетных данных, у которых технически есть права на запись. Но она не исправит политику, уже разрешающую разрушительные операции.

Руководство по безопасности рекомендует сначала включать правила уровня L7 в режиме audit, изучать реальные запросы и только затем переходить к enforce. В режиме аудита нарушения записываются в журнал, но запросы все равно проходят. Это этап сбора информации, а не рабочий механизм блокировки.

Как оценивать OpenShell и не принимать демонстрацию за результат аудита безопасности

В официальном руководстве NVIDIA используются curl и неаутентифицированный REST API GitHub, чтобы показать блокировку доступа, правила только для чтения и замену политики без остановки работы. Это учебный сценарий, а не независимый бенчмарк (NVIDIA Technical Blog).

С помощью этого руководства стоит проверить три практических вопроса:

  1. Может ли ваш агент запускаться без сетевого доступа и получать только те конечные точки, которые ему действительно нужны?
  2. Удается ли явно разделить операции чтения и записи для используемых API?
  3. Может ли операционная команда анализировать блокировки и изменения политик, не давая агенту права самостоятельно одобрять собственные запросы?

Для полноценного пилота добавьте сценарии с попытками обхода: симлинки и path traversal, установку пакетов, дочерние процессы shell, альтернативные бинарные файлы, отправку подстановок учетных данных не на тот хост и комбинации действий, каждое из которых по отдельности разрешено. В открытых материалах нет данных о задержках, накладных расходах при запуске или независимых показателях частоты успешного обхода изоляции. Поэтому эти метрики придется собирать в собственной среде, а не выдавать архитектурные заявления продукта за результаты тестирования.

Что может остановить производственное внедрение

При принятии решения о запуске в production стоит учитывать три ограничения:

  1. Зрелость и совместимость. В репозитории заявлена поддержка Linux, macOS на Apple Silicon и Windows через экспериментальный WSL 2. Для выполнения можно использовать Docker, Podman или виртуализацию на уровне хоста. В Kubernetes требуется CNI, поддерживающий NetworkPolicy; пространства имен пользователей Kubernetes также требуют актуальных версий ядра, Kubernetes и среды выполнения, а совместимость GPU в такой конфигурации не подтверждена (OpenShell README; Security Best Practices).
  2. Комбинирование политик. В тесте реального пользователя @liyun0016 явно заданные проверки запретов прошли, однако редактирование репозитория, изменение CI и запуск CI могли объединиться в несанкционированный путь к production (публикация). OpenShell исполняет написанные вами правила, но не формулирует за вас забытые бизнес-ограничения.
  3. Качество доказательств. NVIDIA сообщает о длительных adversarial-экспериментах без записей в защищенные репозитории, но в цитируемых технических материалах не приводит число моделей, базовые показатели, частоту ложных срабатываний или независимое воспроизведение результатов. Считайте это данными от поставщика, а не сертификацией.

«OpenShell явно хорошо исполняет правила, которые вы ему задаете. Но ... похоже, именно уровень политик становится настоящим узким местом». — @liyun0016 (источник)

Репозиторий NVIDIA OpenShell на GitHub

Кому уже стоит попробовать NVIDIA OpenShell

СитуацияРешение
Локальный агент для программирования, работающий с чувствительными файламиСтоит провести пилот, если подходят требования к Linux/macOS и политики начинаются с узких разрешений
Командный флот агентов с несколькими рабочими пространствамиПодходит, когда нужны изолированные рабочие пространства, общий аудит политик и посредничество при работе с учетными данными
Развертывание в Kubernetes с высокой нагрузкой на GPUПроводите пилот особенно внимательно: совместимость пространств имен пользователей и GPU требует отдельной проверки
Автономный production-агент с широкими бизнес-полномочиямиНе полагайтесь только на OpenShell; добавьте бизнес-согласования, контроль на уровне операций, журналирование и откат
Нужна только простая песочница для Python-кодаСравните специализированные решения; OpenShell может оказаться избыточным уровнем управления

Моя рекомендация — ограниченный пилот, а не безусловная миграция. Выберите одного агента, одно рабочее пространство, сетевую политику с запретом по умолчанию и небольшой набор обратимых задач. Измеряйте количество ложных блокировок, время запуска, стоимость поддержки политик и возможность пересечь бизнес-границу с помощью последовательности по отдельности разрешенных действий.

Частые вопросы о NVIDIA OpenShell

Требуется ли NVIDIA OpenShell GPU NVIDIA?

В README описаны сценарии выполнения как на CPU, так и на GPU, а среди вариантов запуска указаны Docker, Podman и виртуализация на уровне хоста. Среда не позиционируется как требующая GPU NVIDIA, но конкретную комбинацию драйверов и компонентов развертывания все равно нужно проверить.

Готов ли OpenShell к production?

У OpenShell 0.1.x есть документированная ветка релизов, однако официальные материалы не содержат независимой сертификации безопасности или широких бенчмарков производительности. Рассматривайте его как инфраструктуру, которую нужно проверить на собственной модели угроз, а не как универсальную гарантию готовности к production. В репозитории указана лицензия Apache License 2.0; отдельно заложите бюджет на вычислительные ресурсы, эксплуатацию Gateway, поддержку политик и тестирование безопасности (OpenShell README).

Итоговый вердикт: подходит.

Может ли OpenShell запускать Claude Code или Codex?

NVIDIA называет Claude Code и Codex среди совместимых агентов в своем техническом блоге. Среда рассчитана на изоляцию уже существующих агентских нагрузок и не требует их переписывать.

Можно ли изменить правила файловой системы без пересоздания песочницы?

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

Чем OpenShell отличается от Docker?

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