--- service: "Publicasta" schema_version: "1.0" article_id: 739 title: "NVIDIA OpenShell передаёт права агентов под управление политик — что уже можно тестировать" language: "ru" default_language: "en" canonical_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=ru" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=ru" api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/nvidia_openshell_agent_runtime_policy_boundaries?lang=ru" channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar" channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-30T13:56:50+00:00" updated_at: "2026-09-30T13:56:50+00:00" translations: - language: "ar" html_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=ar" markdown_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.md?lang=ar" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=ar" - language: "de" html_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=de" markdown_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.md?lang=de" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=de" - language: "en" html_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=en" markdown_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.md?lang=en" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=en" - language: "es" html_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=es" markdown_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.md?lang=es" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=es" - language: "fr" html_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=fr" markdown_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.md?lang=fr" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=pl" markdown_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.md?lang=pl" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=ru" markdown_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.md?lang=ru" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries?lang=zh" markdown_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.md?lang=zh" json_url: "https://publicasta.com/open_source_radar/nvidia_openshell_agent_runtime_policy_boundaries.json?lang=zh" --- # NVIDIA OpenShell передаёт права агентов под управление политик — что уже можно тестировать > NVIDIA OpenShell — рантайм с лицензией Apache 2.0, который помещает кодинговых и автономных агентов в песочницы с заданными правилами. Его ключевая идея — граница вокруг файлов, процессов, сети, учётных данных и изменений политик. NVIDIA OpenShell — открытая часть новой инициативы NVIDIA, призванной упростить изоляцию автономных агентов. Проект помещает такие инструменты, как Codex, Claude Code, OpenCode и GitHub Copilot CLI, в песочницы, а затем задаёт правила для файлов, к которым они могут обращаться, программ, которые им разрешено запускать, сетевых адресатов и используемых учётных данных. ![Редакционная иллюстрация автономного агента программирования внутри песочницы с политиками доступа, ограничивающими файлы, процессы, сеть и учетные данные.](https://publicasta.com/storage/projects/10/pages/739/2026/09/1f38b816-0b0a-4237-9770-bf3037993645.webp) Такой подход важен потому, что многие разговоры о безопасности агентов по-прежнему начинаются с модели. OpenShell начинает уровнем ниже. Он исходит из того, что модель может неправильно понять запрос, последовать враждебной инструкции в репозитории, выполнить рискованную shell-команду или передать работу дочернему процессу. Тогда главный вопрос звучит иначе: что именно получившаяся рабочая нагрузка технически может делать. NVIDIA объявила более широкую платформу Open Agent Safety Platform 28 сентября 2026 года. В неё также входит Sentry — отдельная концепция мониторинга и сдерживания, связанная с аппаратным обеспечением NVIDIA. OpenShell — та часть системы, которую разработчики могут изучать и запускать на нескольких вариантах инфраструктуры. Проект распространяется по лицензии Apache 2.0, но остаётся развивающимся: у него есть операционная сложность, требования к хосту и модель политик, которую необходимо тщательно проверять. Практический вывод прост: OpenShell стоит попробовать для экспериментов с безопасностью, локальной оценки агентов и контролируемых сценариев разработки. Однако успешное прохождение быстрого руководства ещё слишком рано считать доказательством того, что агент безопасен для промышленной эксплуатации. ## Главный акцент: продуктом становится граница агента Репозиторий OpenShell описывает проект как рантайм для групп автономных агентов. Это иное предложение, чем фреймворк агентов. OpenShell не решает, как агент планирует задачу, какая модель должна генерировать следующий шаг или как разработчику строить граф оркестрации. Он располагается под существующим инструментом и пытается удержать этот инструмент внутри заранее объявленной рабочей границы. Разницу легко не заметить на фоне нынешней волны запусков агентных продуктов. Типичный кодинговый агент может читать рабочую копию, изменять исходники, устанавливать зависимости, обращаться к реестрам пакетов, использовать Git, вызывать облачные API и запускать дочерние процессы. В запросе можно попросить его быть осторожным, но запрос не является механизмом принудительного исполнения. Если агент получает вредоносную инструкцию из README или issue, он всё равно может воспользоваться полномочиями, которые ему предоставила окружающая оболочка. OpenShell переносит выражение этих полномочий на другой уровень. Оператор описывает политику в YAML. Рантайм превращает её в ограничения, применяемые ядром, супервизором песочницы и сетевым прокси. Модель по-прежнему способна принять плохое решение, но это решение должно пройти через права, выданные её рабочей нагрузке. В этом и состоит более содержательный открытый аспект проекта, чем очередной перечень поддерживаемых моделей. OpenShell проверяет, можно ли сделать права агента переносимой и проверяемой конфигурацией. Если получится, одна и та же политика сможет перемещаться вместе с образом песочницы или проходить ревью в pull request. Если не получится, проект станет ещё одним конфигурационным слоем, который разработчики будут обходить всякий раз, когда он мешает работе. ## Что именно контролирует OpenShell У основной политики несколько областей, и ведут они себя неодинаково. Время применения настроек — одна из первых вещей, которую должен понять любой оценщик. `filesystem_policy` определяет, какие пути можно читать и какие можно изменять. Проект использует ограничения на основе Landlock для контроля файловой системы. Настройки файловой системы и Landlock применяются при запуске песочницы, поэтому их изменение не равнозначно смене сетевого правила у уже работающей нагрузки. Политика может разрешить агенту записывать в каталог проекта и временный каталог, оставив за пределами его видимости учётные данные, SSH-ключи, профили браузера и посторонние данные домашнего каталога. Раздел `process` задаёт идентификатор и условия работы процессов, используемые при создании песочницы. Цель — не дать рабочей нагрузке превратить обычную задачу программирования в упражнение по повышению привилегий. При этом результат всё равно зависит от выбранного рантайма и конфигурации хоста: файл политики не отменяет предположения безопасности Docker, Podman, Kubernetes, виртуальной машины или лежащей под ними операционной системы. `network_policies` управляют исходящими соединениями. OpenShell использует модель запрета по умолчанию для подключений из песочницы, а затем разрешает названные адресаты и, если это настроено, конкретные бинарные файлы. Правило может отличать менеджер пакетов от shell-команды или Git-клиент от универсального HTTP-клиента. Это позволяет разрешить узкий рабочий процесс, не выдавая каждому процессу одинаковый исходящий доступ. Сетевой слой также может проверять запросы на более высоком уровне. В примере NVIDIA `curl` разрешено читать из REST API GitHub, но запрос на запись отклоняется. Существенная деталь заключается в том, что разрешение хоста не обязательно означает разрешение любой операции на этом хосте. Политика может описывать endpoint, порт, протокол, допустимый бинарный файл и доступ только для чтения либо чтения и записи. `network_middlewares` создают дополнительное место для проверки, преобразования или блокировки. На практике благодаря этому политика может быть точнее обычного правила межсетевого экрана. Документация проекта описывает управление HTTP-, GraphQL- и Model Context Protocol-трафиком. Это не означает, что все прикладные протоколы одинаково зрелы или одинаково легко описываются; речь о том, что рантайм рассчитан на анализ запросов, а не только IP-адресов и портов. Наконец, профили провайдеров отвечают за учётные данные и разрешённый доступ к сервисам. Предполагается, что агент не получает необработанный секрет, после чего использует его повсюду. OpenShell оставляет настоящий секрет вне рабочей нагрузки, проверяет адресат и политику и подставляет учётные данные только для разрешённого запроса. Токен GitHub, пригодный для чтения конкретного API-пути, не должен автоматически превращаться в универсальный секрет, доступный каждой команде внутри песочницы. Последняя граница особенно важна для кодинговых агентов. Инструмент можно лишить возможности читать локальный токен и одновременно выдать ему узкий доступ к удалённому сервису. Это не замена собственным разрешениям сервиса, а дополнительный контроль над тем, как агент ими пользуется. ## Небольшая политика полезнее маркетингового тезиса Наиболее информативный способ оценить OpenShell — начать с намеренно скучной задачи. Создайте песочницу без исходящего сетевого доступа. Выполните безвредный запрос, например обращение к публичному API GitHub. Убедитесь, что запрос заблокирован, и изучите журнал. Затем примените политику, разрешающую endpoint GitHub только для чтения, и повторите запрос. После этого попробуйте операцию записи и проверьте, что правило read-only её отклоняет. Упрощённая форма политики может выглядеть так: ```yaml version: 1 filesystem_policy: include_workdir: true read_only: - /usr - /lib - /etc read_write: - /tmp landlock: compatibility: best_effort 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 ``` Этот пример не является политикой для промышленной среды. Он нужен, чтобы сделать механизм видимым. Заодно он показывает, почему проект следует оценивать тестами, а не скриншотами. Вопрос не в том, существует ли YAML. Вопрос в том, будет ли запрещённый запрос действительно запрещён при точном рантайме, образе, пути к бинарному файлу, настройке учётных данных и конфигурации хоста, которые команда собирается использовать. Документация OpenShell говорит, что статические ограничения фиксируются при создании песочницы, а сетевые ограничения можно менять во время её работы. Это удобно для постепенного согласования: агент начинает без сети, запрашивает конкретный сервис и получает проверенное обновление без перезапуска. Одновременно возникает задача управления. Динамическое изменение политики может расширить доступ во время долгой сессии, поэтому процедура утверждения, журнал аудита и возможность отката не менее важны, чем исходная политика. В проект входят советник политик и prover политик для проверки предлагаемого доступа. Идея состоит в том, что изменение можно проверить на появление новых полномочий до применения. Это полезное направление, но формальная проверка политики не равна проверке того, что политика выражает бизнес-намерение. Формально корректное правило всё равно может разрешить не тот репозиторий, не тот метод API или учётные данные с избыточными полномочиями. ## Кому стоит попробовать OpenShell уже сейчас OpenShell подойдёт тем, кто уже запускает агентов с заметными локальными полномочиями и хочет измерить разницу между осторожностью на уровне prompt и принудительными ограничениями рантайма. Инженеры по безопасности смогут строить воспроизводимые тесты выхода агента из изоляции и вывода данных. Платформенные команды могут исследовать перенос политик с ноутбука разработчика на шлюз Kubernetes. Авторы агентных инструментов — проверить, как их деревья процессов, сетевые вызовы и интеграции с провайдерами ведут себя в ограниченной среде. Проект особенно актуален для разработчиков, работающих с чужими репозиториями. Незнакомая кодовая база может содержать скрипты установки, сгенерированные файлы, hooks зависимостей или инструкции, адресованные автоматическим инструментам. Песочница с узким рабочим каталогом и без исходящего доступа по умолчанию даёт более безопасное место для изучения такого материала. Защита не абсолютна, но она может уменьшить последствия случайной команды. Исследователям, оценивающим локальные модели, разделение также будет полезно. OpenShell может запускать агента с локальным или облачным выводом, одновременно помещая файлы рабочей нагрузки и исходящие запросы за границу политики. Это позволяет сравнивать модели, не меняя целиком среду хоста при каждом запуске. Осторожнее следует быть тем, кто ищет готовую корпоративную панель управления. В репозитории есть шлюз, SDK, работа с провайдерами, аудит и путь развёртывания в Kubernetes, но совместное использование этих частей — самостоятельный системный проект. Он затрагивает управление образами, привилегии рантайма, сетевое принуждение, идентификацию, секреты, логирование, реагирование на инциденты и владение политиками. Установка CLI не означает, что эта работа выполнена. ## Хост и рантайм по-прежнему имеют значение Быстрый старт сейчас ориентирован на Linux, macOS на Apple Silicon и Windows через WSL 2 в экспериментальном режиме. Проект ожидает контейнерную или виртуализационную основу вроде Docker, Podman или виртуализации на хосте. Kubernetes поддерживается через развёртывание Helm; проект отдельно отмечает, что сетевой слой кластера должен обеспечивать соблюдение соответствующей сетевой политики. Это не административные сноски. Песочница настолько сильна, насколько сильна граница, которая реально её обеспечивает. Команда должна зафиксировать доступные функции ядра, поведение при недоступности Landlock, использование rootless-контейнеров, сохраняющиеся capabilities, способ сборки образов и механизм аутентификации обновлений. Один и тот же YAML может давать разные практические результаты при изменении предположений о хосте. Документация политики проекта включает настройку совместимости для Landlock. Это полезная адаптация под разные среды, однако разрешительный режим совместимости нельзя принимать за гарантию того, что все задуманные ограничения файловой системы активны. Промышленному развёртыванию нужна стартовая проверка, которая либо завершается с ошибкой при недостаточной защите, либо ясно сообщает о сниженной позиции безопасности. Сетевой прокси — ещё одна зависимость, которую нужно проверять. Если агенту нужны реестр пакетов, Git-провайдер, endpoint модели, трекер задач или MCP-сервер, каждый сервис расширяет поверхность политики. Широкое правило для домена может быть удобным, но подрывать смысл управления отдельными endpoint. Слишком узкое правило способно подтолкнуть разработчика к добавлению исключения «разрешить всё». Операционная схема должна делать узкий путь проще обхода. ## Брокер учётных данных многообещающ, но не творит чудес Модель провайдеров OpenShell отвечает на распространённую проблему: агенту передают окружение со всеми токенами, доступными пользователю. Если оставить секреты вне песочницы и связать их с разрешёнными адресатами, рантайм сможет не дать токену одного сервиса уйти в другой. Он также может применить правило чтения к запросу, даже если базовый токен технически допускает запись. Риск учётных данных при этом не исчезает. Сервис по-прежнему должен выдавать разумно ограниченные токены. Профиль провайдера необходимо правильно настроить. Прокси должен распознавать трафик, который обязан проверять. Полномочие удалить репозитории остаётся опасным, если политика разрешает соответствующий метод API. Модель всё ещё может создать разрушительный результат внутри выданной ей области. Поэтому лучшая проверка — матрица, а не один успешный сценарий. Проверьте разрешённое чтение, запрещённую запись, неутверждённый хост, запрос от неправильного бинарного файла, просроченные учётные данные, некорректный запрос, subprocess и дочернего агента. Повторите те же действия через SDK или интеграционный путь, который будет использовать настоящая нагрузка. Затем изучите аудит и выясните, сможет ли оператор восстановить последовательность событий. OpenShell заявляет, что записывает решения политики в журнал аудита Open Cybersecurity Schema Framework. Для реагирования на инциденты это полезно, но журналы работают только тогда, когда их собирают, хранят, защищают от рабочей нагрузки и связывают с идентификатором человека или автоматизации, утвердивших изменение. Локальный демонстрационный лог ещё не является корпоративной системой аудита. ## Чего проект не решает OpenShell обеспечивает сдерживание, а не выравнивание поведения модели. Он не превращает ненадёжную модель в надёжную, не отличает тонкую бизнес-ошибку от допустимого действия и не гарантирует безопасность самой постановки задачи. Если агенту разрешено менять промышленное развёртывание, рантайм может безошибочно обеспечить это разрешение, пока модель выполняет разрушительное, но технически авторизованное изменение. Проект также не заменяет провайдеров идентификации, менеджеры секретов, защиту конечных точек, управление уязвимостями, средства контроля цепочки поставки, наблюдаемость или человеческое подтверждение. В собственных материалах NVIDIA описывает OpenShell как границу рантайма агента, интегрирующуюся с окружающими системами. Именно так его и стоит понимать. Проект добавляет слой, но не делает остальную часть стека необязательной. Есть и более базовое ограничение: качество политики определяет, насколько полезен выданный доступ. Агент-разработчик, который не может прочитать нужные файлы или обратиться к нужному реестру пакетов, будет непонятно ошибаться. Агент с широкими правами на файловую систему и сеть может работать гладко, почти не получая реальной защиты. Инженерная задача — определить минимальный набор полномочий, достаточный для завершения работы, а затем сделать исключения явными и проверяемыми. В публичном обсуждении звучала та же обеспокоенность с другой стороны. В материалах о запуске отмечалось, что строгие ограничения могут блокировать полезную работу и что для понимания баланса нужны реальные кейсы. Это не причина отбрасывать проект. Это причина проверять настоящие рабочие процессы вместо повторения тезиса о том, что агента можно изолировать за миллисекунды. Компонент Sentry также важно концептуально отделять. NVIDIA представляет его как аппаратный слой мониторинга и сдерживания, тогда как OpenShell — открытый рантайм и граница политики. Согласно NVIDIA и публикациям о запуске, OpenShell способен работать на конкурирующих вычислительных платформах, включая Arm и Intel. Поэтому при оценке открытого проекта не следует автоматически приписывать ему все свойства более широкой платформы NVIDIA. ## Лицензия и зрелость проекта Репозиторий OpenShell указывает лицензию Apache 2.0. Это разрешительная лицензия, знакомая проектам инфраструктуры и инструментам разработчика. Она упрощает изучение, изменение и интеграцию кода с учётом условий самой лицензии, а также отдельных условий для загружаемых материалов, контейнерных образов, моделей, провайдеров и сторонних компонентов. В репозитории также есть политика безопасности и уведомления о сторонних компонентах. Эти документы должны входить в проверку перед внедрением. Собственный отказ от ответственности проекта указывает, что материалы, полученные или используемые программой, регулируются отдельными условиями, а пользователи сами отвечают за проверку их безопасности, целостности и пригодности. Иными словами, открытый рантайм не делает автоматически надёжными каждый образ, навык, плагин, модель или скрипт, запущенные внутри него. Зрелость следует оценивать по истории выпусков и issue, а не только по наличию за репозиторием крупной компании. У OpenShell большая поверхность: CLI, локальный шлюз, драйверы песочниц, схема политик, поведение прокси, учётные данные провайдеров, SDK, развёртывание Helm, маршрутизация вывода и агентные навыки. Каждый компонент создаёт вопросы совместимости и безопасности. Ранним пользователям стоит фиксировать версии, держать расходуемую тестовую среду, просматривать изменения между релизами и сохранять путь отката. Телеметрию нужно проверять отдельно. Репозиторий сообщает, что OpenShell по умолчанию собирает анонимные операционные категории и счётчики, исключая имена, имена хостов, пути файлов, prompts, учётные данные, названия провайдеров, названия моделей и пользовательский контент. Также описаны способы отключить телеметрию или исключить её при сборке. Это более полезное раскрытие информации, чем молчание, но организациям со строгими требованиями к приватности следует проверить реализацию и конфигурацию собственной сборки, а не полагаться только на резюме. ## Альтернативы и дополнения OpenShell не единственный способ уменьшить полномочия агента. Минимального контейнера без монтирования хоста может хватить для узкого шага сборки. Rootless-контейнер, microVM, выделенная виртуальная машина, удалённый рабочий узел или задание CI дают разные компромиссы изоляции. Примитивы Linux, такие как Landlock и seccomp, тоже можно использовать напрямую, если команде нужен меньший контрольный контур. Эти подходы решают разные части задачи. Контейнеры и pods дают основу исполнения. MicroVM может обеспечить более сильную границу изоляции ценой времени запуска и управления образами. CI-раннеры удобны для воспроизводимых заданий, но могут быть неудобны для интерактивной разработки. Прямая политика ядра бывает лёгкой, однако тогда команде придётся самостоятельно строить брокер учётных данных, сетевое посредничество, управление жизненным циклом и правила аудита. Аргумент OpenShell заключается в том, что для агентных нагрузок эти части нужно согласовать. Политика должна описывать не только то, что процесс может читать, но и какой исполняемый файл может вызывать какой endpoint, какая учётная запись связана с этим endpoint, как меняется активная политика и как результат записывается в журнал. Именно эта координация — главная причина существования проекта. Поэтому корректное сравнение выглядит не как «OpenShell против Docker». Сравнивать следует OpenShell вместе с рантаймом и один только рантайм, измеряя дополнительные политики и шлюз по отношению к вносимой сложности. Для простой недоверенной команды сборки OpenShell может быть излишним. Для агента, который долгое время просматривает репозиторий, устанавливает инструменты, вызывает API и запускает дочерние процессы, дополнительный слой может оказаться оправданным. ## Разумный план оценки Начните с расходуемого хоста и небольшого репозитория. Зафиксируйте операционную систему, функции ядра, контейнерный движок, версию OpenShell, образ песочницы, версию агента и конфигурацию провайдеров. Не начинайте с промышленными секретами или проекта, содержащего посторонние учётные данные. Создайте базовую песочницу. Проверьте, какие файлы видны, какие пути доступны для записи, кому принадлежат процессы и что происходит, когда команда пытается использовать сеть. Выполните те же проверки из агента, из shell, запущенного агентом, и из дочернего процесса. Добавляйте по одному сервису за раз. Узкий read-only-доступ к пакету или Git-сервису лучше, чем неограниченный доступ в интернет. Проверяйте положительный сценарий и несколько отрицательных. Храните политику в системе контроля версий, проверяйте её как код и записывайте, зачем нужен каждый разрешённый endpoint и бинарный файл. Затем проверьте изменения политики во время сессии. Установите, какие разделы требуют новой песочницы, а какие можно перезагрузить на лету. Убедитесь, что запрещённый запрос остаётся запрещённым до фактического применения одобренного изменения. Проверьте откат и обработку ошибок. Систему контроля доступа нужно оценивать при недоступном шлюзе, некорректной политике, отсутствующем провайдере и тайм-ауте сетевого запроса. Наконец, смоделируйте инцидент. Передайте агенту инструкцию из репозитория, которая просит искать секреты, обращаться к неутверждённому endpoint или менять файл за пределами рабочей директории. Цель не в развлечении за счёт обмана модели. Нужно выяснить, блокирует ли граница действие, понятна ли ошибка, записывается ли событие и может ли оператор ужесточить политику, не уничтожив текущую сессию. ## Вердикт NVIDIA OpenShell интересен тем, что рассматривает полномочия агента как инфраструктуру, а не как обещание, встроенное в системный prompt. Код с лицензией Apache 2.0, декларативные политики, поддерживаемые ядром ограничения файловой системы, сетевое посредничество, учётные данные провайдеров и модель шлюза дают разработчикам конкретный объект для проверки. Проект естественно связан с экосистемой открытого ПО: он поддерживает несколько агентных инструментов, предоставляет SDK, документирует путь через Kubernetes и может работать не только на оборудовании NVIDIA. Предостережения столь же конкретны. Проект не является универсальной системой безопасности, его политики бывает трудно проектировать, предположения о хосте требуют проверки, а широкий набор функций повышает цену аккуратного внедрения. Правило запрета сети по умолчанию полезно только пока исключения остаются узкими. Песочница полезна только тогда, когда понятны хост и образ. Брокер учётных данных полезен лишь при проверенных правах провайдера и проверке запросов. Для аудитории Open Source Radar разумный следующий шаг — лабораторное испытание, а не перенос в промышленную среду. Используйте OpenShell, чтобы построить воспроизводимый стенд для агентных процессов, которым сейчас выдано слишком много полномочий. Измеряйте заблокированные действия, ложные срабатывания, запуск, ревью политик, журналы и восстановление. Если ограничения выдержат проверку и при этом не превратят каждую задачу в очередь согласований, OpenShell может стать практической основой для более безопасной разработки агентов. Если нет, эксперимент всё равно покажет, где именно рабочий процесс зависит от неявных полномочий, а такая информация нужна большинству агентных проектов. ## Источники Материал основан на описании репозитория NVIDIA OpenShell, документации политик песочницы, технических материалах NVIDIA, сведениях о лицензии Apache 2.0 и контексте публичного обсуждения запуска. Указанные источники использованы для сохранения фактов, ограничений, атрибуции и уровня неопределённости исходной статьи.