NVIDIA OpenShell: runtime-контроли и безопасность AI-агентов

AI-агенту можно поставить цель, дать доступ к инструментам и оставить работать: он пишет код, изучает данные, использует API и корректирует план по мере появления новой информации. Именно так появляются системы, которые расследуют инциденты в ПО, проводят эксперименты или ведут долгие исследовательские задачи — часами, днями, иногда неделями.

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

NVIDIA OpenShell 0.1.0 — open-source runtime для задания и принудительного применения ограничений на доступ агента к системам и данным. Платформа объединяет изолированное выполнение в песочнице, контролируемый доступ к сервисам, управление учётными данными и формальный анализ политик. Агент получает ровно те возможности, которые нужны для работы, а OpenShell применяет правила вне его рабочей нагрузки. Это важный принцип: агент может рассуждать как угодно, но за границы политики он не выйдет.

OpenShell поддерживает Codex, Claude Code, Pi, Hermes и будущие агентные фреймворки. Его можно использовать в корпоративной автоматизации, исследованиях, робототехнике и edge-системах — от внутреннего парка агентов до физического ИИ. Для компаний, проектирующих архитектуру AI-агентов, это отдельный runtime-слой контроля, а не очередная библиотека в кодовой базе.

Как организации внедряют OpenShell

OpenShell распространяется с открытым исходным кодом и рассчитан на корпоративное внедрение. Экосистема партнёров участвует и в развитии продукта. Сценарии разные: проектирование микросхем, автоматизация операций, ускоренные вычисления, управление роботами.

Cadence применяет OpenShell в ChipStack Autonomous RTL Design Engineer для проектирования чипов.
Slack создаёт агентную платформу по запросу для автоматизации рабочих задач.
Gecko Robotics использует OpenShell для управления агентами, которые принимают решения на физических роботах.

Возможности OpenShell

Возможность	Практический эффект
Мультитенантность	Несколько команд или клиентов используют общую инфраструктуру, но получают изолированные рабочие пространства, разрешения и доступ к сервисам.
Формальная проверка политик	Помогает подтвердить, что запрошенные права не выходят за заданные границы безопасности.
Расширяемая безопасность и управление	Позволяет подключать внешние сервисы безопасности, системы управления и собственные проверки.
Защищённый доступ к сервисам	Агент работает с аутентифицированными сервисами, не получая реальные секреты в своё окружение.
CPU и GPU	Рабочие нагрузки запускаются на CPU или GPU в контейнерах, виртуальных машинах и Kubernetes.

Таблица 1. Возможности OpenShell 0.1.0

Применение разрешений вне агента

Агент интерпретирует инструкции, выбирает инструменты и меняет стратегию по ходу дела. OpenShell сохраняет эту гибкость, но применяет разрешения снаружи — там, где агент не может незаметно переписать себе правила. Собрать такой контур самостоятельно — значит отдельно настроить песочницу, прокси для исходящих запросов и журнал решений; вынесем контроль прав ваших AI-агентов за пределы их рабочей среды.

Контроль обеспечивают три компонента:

OpenShell Gateway управляет жизненным циклом и политиками множества песочниц.
OpenShell Supervisor работает рядом с каждой песочницей, но вне нагрузки агента, и проверяет исходящие запросы на соответствие политике.
OpenShell Sandbox запускает нагрузку с ограничениями файловой системы и процессов на уровне ядра; сеть доступна только через supervisor.

Песочница OpenShell использует механизмы ядра ОС, чтобы ограничивать чтение и изменение файлов, а также не давать нагрузке получить дополнительные привилегии. Supervisor проверяет HTTP, GraphQL и Model Context Protocol (MCP): например, чтение через API можно разрешить, а запись в тот же API — запретить. Контроли не исчезают, когда агент запускает shell, исполняет сгенерированный код, создаёт дочерние процессы или делегирует работу субагентам. Решения политик записываются в журнал аудита OCSF.

Такая модель особенно полезна для мультиагентных систем: права одного агента не должны случайно превращаться в обходной путь для другого. Мелочь? В реальной инфраструктуре — совсем не мелочь.

Наблюдение за решениями политики

Ниже используется curl и неаутентифицированный GitHub REST API. Так каждое решение политики видно без API-ключа и языковой модели; при работе AI-агента применяются те же ограничения.

Установите OpenShell 0.1.0 по руководству по установке, затем поместите файлы no-network.yaml и github-readonly.yaml в каталог examples. Создайте песочницу без исходящего сетевого доступа:

openshell sandbox create --name policy-demo \
  --no-auto-providers \
  --policy examples/no-network.yaml

Команда откроет shell в песочнице. Попробуйте обратиться к публичной конечной точке:

curl -sS --max-time 10 https://api.github.com/zen

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

openshell logs policy-demo --since 5m

Теперь задайте политику доступа к GitHub REST API только для чтения. Политики описываются в YAML и компилируются в OPA/Rego; OpenShell оценивает их для каждого исходящего запроса.

network_policies:
  github_api:
    name: github-api-readonly
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

Правило разрешает /usr/bin/curl обращаться к GitHub API через порт 443. При protocol: rest OpenShell анализирует HTTP-запрос: чтение пропускает, запись блокирует. Обновите политику без перезапуска песочницы:

openshell policy set policy-demo \
  --policy examples/github-readonly.yaml --wait

# Чтение: разрешено
curl -sS --max-time 10 https://api.github.com/zen

# Запись: заблокирована
curl -sS --max-time 10 -X POST https://api.github.com/zen

Доступ к сервисам без раскрытия учётных данных

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

Принимающий сервис по-прежнему применяет права, связанные с настоящими учётными данными. OpenShell добавляет ещё один уровень: политика API «только чтение» способна остановить запись, даже если сам ключ технически допускает её. Это разумная основа для AI compliance и соответствия требованиям.

Если провайдер GitHub с именем github уже настроен, его можно подключить к новой песочнице и запустить Codex:

openshell sandbox create \
  --provider github \
  -- codex

Настройка сетевого доступа во время работы агента

Иногда агенту требуется сервис, о котором не знали в начале задачи. При блокировке OpenShell фиксирует отказ, чтобы оператор или отдельный агент-ревьюер мог его проверить. С включённым policy advisor агент предлагает узкое изменение сетевой или файловой политики. По умолчанию решение остаётся за человеком: агент не утверждает собственную заявку. После одобрения новое правило загружается в работающую песочницу без перезапуска работы.

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

openshell settings set <sandbox-name> \
  --key agent_policy_proposals_enabled \
  --value true

Проверка разрешений, которые даёт политика

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

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

В длительных состязательных экспериментах агенты с ослабленными защитными механизмами до двух часов пытались убедить AI-ревьюера выдать права на изменение защищённого репозитория GitHub. Формальный анализ давал ревьюеру доказательства фактических последствий таких разрешений. В этих тестах сочетание проверки и runtime-контролей позволило сохранить полезный доступ без единой записи в защищённые репозитории.

Локальная разработка и развёртывание в общей инфраструктуре

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

Доверенное middleware вне песочницы подключает сервисы идентификации и добавляет прикладные проверки в путь запроса. Compute-драйверы связывают OpenShell с Docker, Podman, MicroVM и Kubernetes; актуальные требования приведены в матрице поддержки.

Чтобы начать работу, используйте краткое руководство: оно поможет запустить агента с OpenShell и настроить сервисы, к которым ему разрешено обращаться. Код проекта доступен на GitHub.

Если в вашем контуре уже работают Codex, Claude Code или Hermes, сформулируем политику прав для каждого агента и проверим, что в ней нет обходных путей.

Источник: developer.nvidia.com