«Безопасность ИИ — это инженерная задача»: NVIDIA ограничивает агентов на каждом слое стека

Защита агентов — это инженерия, а не настройка

Безопасность ИИ — инженерная задача: она требует определённых требований безопасности, принудительно исполняемых контролей, названных ответственных и доказательств того, что защиты работают. Именно так формулирует главную мысль своей колонки Saša Zdjelar из NVIDIA, опубликованной 21 сентября 2026 года.

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

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

Безопасность зависит от всего стека агента

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

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

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

Граница должна выдерживать ошибку агента

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

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

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

OpenShell: политика вне досягаемости агента

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

Устройство runtime описано там же: для каждого агента и подагента создаётся отдельная изолированная песочница, движок политик оценивает действия на уровне бинарников, путей и методов, а шлюз становится точкой контроля, где действия автономного агента оцениваются до попадания в хост-среду. Решения «разрешить» и «запретить» при этом логируются, что и даёт аудит-след.

Технический блог NVIDIA добавляет к этому рамку: OpenShell обеспечивает слой безопасного runtime, который принудительно исполняет изоляцию, идентичность, политику, учётные данные и аудит для автономных агентов, а пять проектных правил задают жёсткость конструкции — верхние слои предлагают действия, нижние решают, политика находится ниже границы безопасности, каждый эффект проверяется, доступ выдаётся just-in-time, а изоляция даёт возможность восстановления. Практическое следствие из этого разделения: поведенческие контроли направляют агента, инфраструктурные ограничивают его полномочия.

Альянс, Cisco и JFrog строят на OpenShell

Партнёры уже строят на OpenShell: Open Secure AI Alliance собирает и делит открытый защитный стек из моделей, инструментов и техник, чтобы усилить киберзащиту и защищённость ПО и агентов. Логика альянса — смотреть на систему целиком: агент это больше, чем языковая модель, и безопасность зависит от моделей, harness-ов, механизмов выравнивания, runtime, идентичности, политики, точек исполнения, наблюдаемости и восстановления.

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

JFrog подключилась к той же схеме со стороны реестра навыков: Agent Skills Registry должен давать управление и проверяемый trust layer, необходимый агентным рабочим силам для безопасной работы в корпоративном масштабе. Аргумент компании прямой: как вредоносный пакет может скомпрометировать приложение, так и непроверенный навык может направить агента на вредные действия.

Доказательства безопасности до развёртывания

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

Результаты использует названный ответственный: он решает, готова ли система к развёртыванию, и следит за тем, чтобы провалившиеся проверки приводили к исправлению, а каждая находка превращалась в повторяемый тест — так проверяется, что исправление продолжает работать в следующих релизах. Примеры из колонки — CrowdStrike SafeMind с повторяемыми симуляциями атак и Palo Alto Networks Prisma AIRS с непрерывным red teaming по мере изменения моделей и приложений.

SafeMind описан как агентная система для защитников на базе NVIDIA Nemotron: наступательная модель находит путь атаки, оборонительная его закрывает, а harness-ы работают с обеими в одном цикле на данных телеметрии Falcon. Prisma AIRS позиционируется как механизм сетевого принуждения для AI Factory и позволяет строить L7-микропериметры вокруг автономных агентов.

Открытые модели и общий обмен доказательствами

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

В списке примеров — Capital One VulnHunter, который не является традиционным пассивным сканером уязвимостей, а ведёт агентный рабочий процесс поиска эксплуатируемых дефектов, построения путей атаки и точечных исправлений кода, и ReversingLabs Spectra Assure для анализа пакетов ПО на вредоносный код и подмену.

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