NVIDIA выносит границу безопасности агентов за пределы хоста

Новая платформа NVIDIA Open Agent Safety Platform меняет место, в котором предприятие может попытаться остановить агента. Компания предлагает не только средства контроля вокруг приложения или внутри операционной системы хоста. Её эталонный проект Sentry размещает дополнительный уровень мониторинга на DPU BlueField-4 — изолированном от CPU хоста модуле обработки данных, который в архитектуре NVIDIA Vera Rubin POD находится на пути узла к модели.

Именно это — существенная часть анонса от 28 сентября. Безопасность агентов становится вопросом серверной архитектуры: проходит ли каждый значимый маршрут агента через точку принудительного контроля, находящуюся вне собственного домена отказа рабочей нагрузки?

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

Что изменилось: контроль можно вынести за пределы нагрузки

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

ПО может инспектировать настроенный трафик HTTP, GraphQL и Model Context Protocol. Поэтому политика получает более содержательную единицу контроля, чем обычный сетевой список разрешений: например, она может различать чтение из API и запись в API. OpenShell способен хранить сервисные учётные данные вне нагрузки агента и подставлять их только для разрешённых запросов. Решения политики записываются с использованием Open Cybersecurity Schema Framework, а policy prover предназначен для выявления смоделированных разрешений, выходящих за заданную оператором границу.

Это конкретные механизмы времени исполнения, а не только архитектурное обещание. OpenShell и связанные skills доступны как открытое ПО уже сейчас. SAP сообщает, что её инженеры вносят вклад в OpenShell и встраивают его в SAP Business AI Platform; NVIDIA также называет работы по внедрению у Cadence, Slack и Gecko Robotics. Это свидетельствует об активности экосистемы, но не доказывает, что какое-либо конкретное развёртывание получило исчерпывающую защиту.

Sentry расширяет замысел за пределы программного обеспечения хоста. NVIDIA описывает его как опциональный внешний слой для BlueField-4. В заявленной схеме Vera Rubin POD DPU изолирован от хоста и расположен на пути к модели. Логика проста: если нагрузка хоста скомпрометирована, изменена или просто ведёт себя неверно, отдельно размещённый компонент всё ещё может наблюдать и ограничивать трафик, который обязан пройти этим маршрутом.

Что не изменилось: топология не устраняет обходные пути

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

Последнее условие — самое сложное. Агент может обращаться к инструментам, хранилищам данных, моделям и внешним сервисам несколькими путями. Часть трафика может оставаться внутри хоста, идти через отдельный сетевой интерфейс, сайдкар, локальный процесс или интеграцию, не настроенную для инспекции. Инспекция OpenShell применяется к настроенному HTTP-, GraphQL- и MCP-трафику; это полезная конкретика, но не заявление о видимости каждого возможного взаимодействия. Защиту даёт только тот слой, который действительно поставлен на путь значимой операции.

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

Оптимизированная аппаратная схема также конкретна. NVIDIA указывает, что OpenShell можно расширять на другие платформы, тогда как описанная оптимизированная архитектура использует CPU Vera и DPU BlueField-4. Покупателям не следует выводить из одного эталонного проекта одинаковые характеристики контроля для всех процессоров, компоновок серверов и облачных сред.

Новый вопрос развёртывания — одновременно физический и логический

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

Это не означает, что каждому агенту нужен DPU. У многих нагрузок невелики полномочия, ограничен масштаб ущерба или уже есть контрольные точки на API-шлюзах и сервисных границах. Но агенты, способные записывать данные в бизнес-системы, использовать привилегированные операционные учётные данные или делать широкий спектр исходящих запросов, заслуживают более точного инфраструктурного анализа, чем вывод «контейнер изолирован». Граница контейнера и отдельно расположенная точка принудительного контроля — не один и тот же домен отказа.

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

• Разделяйте доступное ПО и анонсированную эталонную архитектуру: OpenShell 0.1.0 можно оценивать сейчас; Sentry следует считать проектным вводом, пока не подтверждены его поставка и применимость.
• Считайте подстановку учётных данных и инспекцию с пониманием операции конфигурацией развёртывания, а не автоматическим покрытием. Проверяйте, какие маршруты HTTP, GraphQL и MCP настроены, а какие остаются вне границы.
• Применяйте вопрос о DPU избирательно: для высокозначимых путей выясняйте, проходит ли трафик через компонент, изолированный от хоста, и определено ли для него действие отказа или изоляции.
• Измеряйте сдерживание в установленной топологии. Не подменяйте проверку путей и действий, используемых в вашей среде, заявлением поставщика о миллисекундах.

Полезный сдвиг с узким утверждением

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

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