Чем дольше агент работает автономно, тем меньше помогает подход «поставить защитные фильтры вокруг модели». NVIDIA выводит контроль за пределы самого агента: отдельный рантайм OpenShell следит за тем, к каким системам и данным агент может обращаться, а инфраструктурный слой на BlueField-4 добавляет независимый надзор прямо в железо.

Контроль над ответами модели перестал закрывать главный риск

Защита ИИ долго сводилась к фильтрации входа и выхода модели: пропустить или заблокировать конкретный запрос, проверить сгенерированный ответ. Эта логика отлично работает, пока агент — это чат, который отвечает на вопрос и замолкает.

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

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

Что анонсировала NVIDIA

28 сентября 2026 года NVIDIA представила NVIDIA Open Agent Safety Platform — открытую платформу и эталонный дизайн системы, которые должны усилить безопасность ИИ от тестирования агента до его продакшена. Платформа состоит из двух частей.

Первая — NVIDIA OpenShell, открытый рантайм (выпущена версия 0.1.0). Он задаёт и принудительно применяет правила о том, к каким системам и данным агент может обращаться, — и делает это без переписывания самого агента. Вторая — NVIDIA Sentry, эталонный дизайн системы, который переносит наблюдение в железо: работает на DPU BlueField-4 и непрерывно следит за поведением агента независимо от него.

Такой расклад — это и есть главная мысль анонса. Защита перестала быть свойством модели и превратилась в отдельный инфраструктурный слой, который существует вне агентного процесса.

Как OpenShell ограничивает агента извне

OpenShell сочетает четыре механизма: изолированное исполнение в песочнице, контролируемый доступ к сервисам, защиту учётных данных и формальную проверку правил доступа.

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

Главное отличие от подхода, когда модель просто просят вести себя аккуратно, — способность различать операции внутри одного API. Supervisor умеет инспектировать трафик HTTP, GraphQL и Model Context Protocol, поэтому разрешает запрос на чтение данных и блокирует запись через тот же самый интерфейс. Ограничения остаются в силе, когда агент запускает оболочку, выполняет сгенерированный код, порождает дочерние процессы или предлагает делегировать задачу субагентам. Все решения о доступе записываются в журнал в формате OCSF, а заблокированный запрос получает понятную ошибку, которая помогает агенту решить, что делать дальше.

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

Формальная проверка вместо доверия к словам агента

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

Для этого в OpenShell есть prover — компонент, который проверяет выданные правилами права с помощью формальной логики. Он либо доказывает, что смоделированные права остаются внутри заданной границы, либо указывает конкретное действие, которое эту границу пересекает. Результат опирается на модель правил, а не на объяснения агента — повлиять на проверку уговорами агент не может.

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

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

Практическое значение

Анонс закрывает реальную брешь в цепочке внедрения агентов. Пока агент отвечает на вопросы, его ошибка — это неверный текст. Когда агент действует от имени пользователя, его ошибка — это изменённые данные, лишние списания или раскрытый секрет. Инструменты, которые контролируют именно действия, а не ответы, меняют соотношение риска и пользы для компаний, которые пока не решаются отдавать агентам рутинные операции.

Показательно и то, кто уже подключается. Cadence использует OpenShell для проектирования чипов, Slack строит на нём платформу агентов для автоматизации задач, Gecko Robotics управляет агентами, принимающими решения на физических роботах. Список партнёров платформы — Anthropic, Cisco, CrowdStrike, Dell, HPE, Hugging Face, JPMorganChase, Microsoft, Palantir, Palo Alto Networks, Red Hat, Salesforce, SAP, ServiceNow — указывает, что безопасность агентов рассматривают как отдельный рынок, а не как фичу внутри фреймворков.

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

Что пока не стоит переоценивать

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

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

Наконец, связка с BlueField-4 привязывает инфраструктурный слой к конкретному железу NVIDIA. Программная часть — OpenShell — открыта и расширяется на сторонние платформы, включая Arm и Intel, но полноценный «надзор в кремнии» работает именно на DPU NVIDIA. Для компаний, у которых нет этого оборудования в контуре, часть обещаний остаётся на бумаге.

С чего начать

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

Главный критерий простой: если после настройки агент продолжает делать всё, что делал раньше, — правила слишком широкие. Узкие правила, которые ломают часть сценариев, на этом этапе полезнее: они показывают, какие права агент действительно использует, а какие выдали ему «на всякий случай». Идея изоляции агентного кода в песочнице при этом не уникальна для NVIDIA — схожий подход уже решает задачу изоляции агентного кода на уровне запуска кода.

Безопасность агентов становится инфраструктурой

За этим анонсом стоит сдвиг посерьёзнее конкретного продукта. Долгое время безопасность ИИ была задачей разработчика модели: фильтровать вход, проверять выход. С распространением агентов, которые действуют, а не отвечают, эта модель перестала покрывать главные риски.

Теперь появляется отдельный слой — рантайм и инфраструктура, которые контролируют не то, что агент говорит, а то, что он делает и к чему прикасается. Показательно, что этот слой строят не только стартапы и фреймворки, а NVIDIA, которая отвечает за саму аппаратную основу, на которой агенты работают. Если контроль опускается в кремний, безопасность агента перестаёт быть опцией конкретного проекта — она становится свойством инфраструктуры, на которой агенты вообще существуют.

Ссылки

Ссылки

По теме

По теме