NVIDIA OpenShell: как ограничить доступ ИИ-агентов

Как работает NVIDIA OpenShell

OpenShell — среда выполнения с открытым исходным кодом: она запускает агента и контролирует его доступ. Она работает под агентом, не заменяя его рассуждения или инструменты.

Представьте подрядчика, который работает в здании. Ему выделяют мастерскую, разрешают входить в определённые помещения и связываться с определёнными поставщиками. Генеральный ключ ему не выдают только потому, что в задании написано «будьте осторожны». OpenShell создаёт такие границы для программных агентов.

В обзоре среды выполнения описаны ограничения файловой системы, сети и процессов, а также защита учётных данных провайдеров. Landlock — механизм ядра Linux, ограничивающий доступ к файлам; seccomp ограничивает системные вызовы, то есть низкоуровневые обращения программы к операционной системе. Эти ограничения применяются независимо от рассуждений агента.

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

NVIDIA описывает варианты запуска для Claude Code, Codex, GitHub Copilot CLI, Hermes, LangChain Deep Agents, OpenClaw и OpenCode, а также для собственных агентов и образов. «Поддерживается» не означает, что все инструменты уже установлены: по умолчанию сейчас используется минимальный образ Ubuntu без CLI агентов — программ командной строки, через которые их запускают.

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

Где OpenShell можно запустить сейчас

Выбирайте хост по актуальной матрице поддержки. Этот разбор опирается на документацию с пометкой v0.1.7, проверенную 8 ноября 2026 года.

WSL 2 запускает среду Linux в Windows. MXC — отдельный вариант нативной изоляции в Windows. Поэтому «поддержка Windows» не означает один взаимозаменяемый способ установки.

В анонсе сотрудничества по Windows описан перенос OpenShell на Windows через MXC. Само направление развития платформы ещё не означает наличия обычного стабильного установщика для нативного запуска. В текущей документации по установке прямо сказано: стандартные каналы релизов не предоставляют нативные исполняемые файлы для Windows.

Для первого знакомства выберите поддерживаемую конфигурацию Linux или Apple Silicon. В матрице поддержки также указаны требования к ядру и среде выполнения: необходимый ABI Landlock появился в Linux 6.2, но одной версии ядра недостаточно. Среда выполнения должна пройти обязательные проверки. В варианте с Docker Desktop на macOS эти механизмы Linux работают внутри его виртуальной машины Linux. Процессоры NVIDIA Vera не обязательны.

Как установить CLI и запустить первого агента

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

1. Подготовьте хост и установите OpenShell. Для варианта с Docker нужен запущенный Docker Desktop либо Docker Engine 28.0 или новее. На поддерживаемых Linux и macOS руководство по установке предлагает команду curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh. Прежде чем запускать установщик, изучите его. Он устанавливает CLI, инструмент проверки политик и локальный шлюз. Команда openshell status позволяет убедиться, что CLI видит шлюз.

2. Настройте сервис модели. В примере используется OpenRouter. Перед созданием провайдера задайте OPENROUTER_API_KEY в окружении хоста. Профиль провайдера описывает разрешённые адреса сервисов и пути к исполняемым файлам; сам провайдер хранит учётные данные. В примере профиля NVIDIA программе /usr/local/bin/opencode разрешено обращаться к openrouter.ai.

3. Импортируйте профиль, создайте провайдера и запустите образ. Выполните на хосте следующие команды по порядку:

openshell profile import \
  --url https://raw.githubusercontent.com/NVIDIA/OpenShell/main/providers/openrouter.yaml
openshell provider create \
  --name openrouter --type openrouter --from-existing
openshell sandbox create \
  --name my-agent \
  --from ghcr.io/anomalyco/opencode:latest \
  --provider openrouter \
  -- opencode -m openrouter/nvidia/nemotron-3.5-lightning:free

OpenCode уже находится в образе; команда после -- запускает его как основной процесс. В руководстве по запуску первого агента используется эта бесплатная модель, для которой не требуется пополнять баланс OpenRouter. Это выбор модели в конкретном примере, а не обещание бесплатного использования любых моделей.

4. Проверяйте запросы доступа с хоста. Когда агент пытается обратиться к неразрешённому адресу, OpenShell отклоняет запрос и готовит предложение узкого правила. Выполните openshell rule get my-agent --status pending. Если предложение соответствует доступу, необходимому для задачи, одобрите именно его командой openshell rule approve my-agent --chunk-id <chunk-id>, подставив фактический ID вместо заполнителя. Правило перезагрузится, и агент сможет повторить попытку.

5. Посмотрите, какие права вы действительно выдали. Выполните openshell policy get my-agent --base, затем openshell policy get my-agent --full. Первая команда показывает базовую политику, вторая — политику с правилами, добавленными провайдерами. Прежде чем подключать реальный проект или чувствительный сервис, проверьте итоговые разрешения.

После пробного запуска удалите ненужную песочницу командой openshell sandbox delete my-agent.

Какие политики можно менять без перезапуска?

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

Изменения «на ходу» всё равно имеют последствия. Новые сетевые правила закрывают соединения, открытые при старых правилах, поэтому клиентам нужно подключаться заново. Для регистрации нового внешнего промежуточного сервиса требуется изменить конфигурацию шлюза и перезапустить его. Добавление пути файловой системы в сохранённую политику не открывает его уже работающей нагрузке; удаление путей или изменение стартовых настроек после запуска отклоняется. Эти различия разобраны в руководстве по управлению политиками.

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

Понятная политика доступа для агента, работающего с кодом

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

Ниже — пример политики для подготовленного образа с инструментами разработки, где проект находится в /workspace, а curl установлен в /usr/bin/curl. Сохраните её как policy.yaml и передайте --policy ./policy.yaml при создании новой песочницы. Это шаблон под такую структуру образа, а не универсальная замена политики для любого образа агента:

version: 1
filesystem_policy:
  include_workdir: false
  read_only: [/usr, /lib, /etc]
  read_write: [/workspace, /tmp]
landlock:
  compatibility: hard_requirement
network_policies:
  github_readonly:
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

Агент может редактировать проект и временные файлы. Сетевое правило разрешает указанному исполняемому файлу отправлять запросы GET, HEAD и OPTIONS к GitHub API. Оно не даёт произвольным программам доступ в интернет, не разрешает скачивание пакетов и не предоставляет возможность Git push. Провайдер модели настраивается отдельно.

Подготовьте все каталоги состояния агента, куда образу нужна запись, и добавьте их явно. Эти пути относятся к файловой системе песочницы. Не стоит считать, что одноимённый каталог хоста автоматически доступен внутри. Кроме того, для нагрузок с сетевым доступом добавляются базовые пути файловой системы, поэтому короткий YAML не означает, что итоговые границы ограничиваются только перечисленными в нём путями.

Особого внимания заслуживают две настройки. hard_requirement останавливает запуск, если заданные пользователем правила файловой системы невозможно применить, хотя отдельные отсутствующие или недоступные пути всё равно могут быть пропущены. enforcement: enforce блокирует запрещённые запросы, проходящие проверку; предусмотренный схемой режим по умолчанию audit записывает нарушения в журнал, но пропускает такие запросы. Перед адаптацией шаблона изучите справочник схемы политики.

Проверяйте и разрешение, и отказ. В руководстве NVIDIA по сетевой политике сначала проверяется, что curl -s https://api.github.com/zen проходит при правиле только для чтения, а затем — что POST блокируется. С хоста просмотрите журнал командой openshell logs my-agent --since 5m --source sandbox. Для своего проекта также проверьте запись в разрешённый файл и попытку доступа к файлу за установленными границами. Успешный запуск агента сам по себе не служит приёмочным испытанием политики безопасности.

Пять сценариев, с которых стоит начать

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

Ни один из этих сценариев не гарантирует правильность сгенерированного кода или надёжность диагноза инцидента. Польза — в сужении круга возможных действий во время работы агента. Для более широкого выбора инструментов смотрите лучшие инструменты безопасности песочниц для ИИ в 2026 году, а для выбора платформы выполнения — лучшие песочницы для выполнения кода ИИ-агентов в 2026 году.

Два продукта, которые можно построить вокруг OpenShell

Самая перспективная идея — комплект для внедрения агентов разработки в команде. Его покупатель — руководитель платформенной команды, которому нужно дать разработчикам продуктивно работать в одобренной среде. По оценке DataForSEO, запрос «claude code sandbox» набирает 1,300 поисков в месяц на рынке, данные по которому вернул запрос для исходной статьи. Это признак интереса к настройке, а не 1,300 потенциальных клиентов; к тому же часть пользователей ищет собственную песочницу агента, а не OpenShell.

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

Вторая идея — рабочая среда для проверки политик. Команды безопасности могли бы видеть в ней, что разрешает итоговая политика, сравнивать изменения и фиксировать согласования. По оценке DataForSEO, запрос «ai agent security» набирает 480 поисков в месяц, а «ai agent security tools» — 70. Эти отдельные широкие запросы сигнализируют о спросе; складывать их как число уникальных покупателей нельзя.

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

Какие задачи OpenShell не решает

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

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

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

Что сделать в понедельник: поручите руководителю платформенной команды выбрать один репозиторий без чувствительных данных и одного агента. Установите OpenShell на поддерживаемом хосте, подготовьте образ, задайте доступ к файлам и сети, затем проверьте разрешённую и заблокированную операции. В течение первой недели фиксируйте время настройки и часы инженеров, потраченные на устранение помех в работе. Расширяйте доступ только тогда, когда команда сможет объяснить каждое выданное разрешение.

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