NVIDIA Open Agent Safety Platform: защита AI-агентов для бизнеса
28 сентября 2026 года NVIDIA представила Open Agent Safety Platform — открытую программную платформу и референсный дизайн для контроля AI-агентов. В неё входят OpenShell, среда исполнения с политиками доступа, и Sentry, аппаратный компонент референсного дизайна для наблюдения за агентами через BlueField-4 DPU.
Для руководителя это важный сдвиг в разговоре о безопасности AI-агентов. Когда агент получает доступ к CRM, почте, базе знаний или внутреннему API, вопрос упирается в конкретные границы: какие данные он видит, какие инструменты вызывает, кто подтверждает рискованное действие и где остаётся журнал. Границы стоит закрепить в правах доступа, порядке согласования и журнале действий.
Граница доступа
Три запроса AI-агентов. Выберите безопасный следующий шаг.
1. Агент поддержки
Просит отправить клиенту компенсацию.
2. Агент аналитики
Просит выгрузить всю CRM для отчёта.
3. Маркетинговый агент
Просит один токен к почте и CRM.
Что NVIDIA представила 28 сентября
Согласно официальному анонсу NVIDIA, Open Agent Safety Platform объединяет OpenShell и референсный дизайн с NVIDIA Sentry. OpenShell задаёт защищённую среду исполнения агента. Политики ограничивают его доступ к файлам, сети, инструментам, процессам и учётным данным. Действия агента можно отслеживать во время работы.
В референсном дизайне NVIDIA Sentry использует BlueField-4 DPU для наблюдения за агентом вне основного хоста. По заявлению компании, этот компонент может изолировать агента при выходе за установленные границы.
Публикация SecurityWeek описывает ключевую конструкцию релиза: OpenShell служит runtime-слоем с песочницей и политиками, а Sentry выступает отдельным аппаратным наблюдателем. CyberScoop также отмечает управление файлами, сетью, инструментами, процессами и credential-политиками в тестовом контуре.
Какой риск закрывает защита AI-агентов
AI-агент способен выполнять цепочку действий. Он читает письмо, ищет сведения в базе знаний, обращается к CRM, создаёт задачу и готовит ответ клиенту. Польза появляется вместе с риском: один широкий токен, лишний scope или разрешённый вызов инструмента может открыть больше возможностей, чем предполагал владелец процесса.
Правила в модели дополните техническим контролем доступов и интеграций. В рабочем контуре стоит разделить пять вещей:
- Роль агента. Укажите один процесс и результат: подготовить карточку лида, классифицировать обращение, собрать отчёт или сформировать черновик ответа.
- Данные. Оставьте доступ только к полям, документам и периодам, которые нужны этой роли.
- Инструменты. Для каждого API, MCP-сервера и действия задайте отдельные права, лимиты и владельца.
- Подтверждение. Отправка сообщения клиенту, изменение условий, удаление данных, платежи и выдача прав должны проходить через человека.
- Наблюдаемость. После каждого запуска должны сохраняться входные данные, вызванные инструменты, результат, решение о подтверждении и причина эскалации.
Такая схема даёт руководителю и службе безопасности проверяемый список: кто владеет агентом, какие у него права и где сотрудник принимает решение.
Что проверить до запуска корпоративного AI-агента
Релиз NVIDIA полезен как повод пересмотреть уже запущенные сценарии. Начните с инвентаризации: какие агенты существуют, кто ими владеет, к каким системам они подключены, от чьего имени работают и какие действия способны выполнить без участия сотрудника.
Затем соберите карту полномочий. Для каждого подключения зафиксируйте тип данных, метод аутентификации, scope, срок жизни токена, лимит запросов и журнал аудита. Если у агента есть доступ к CRM, почте и файловому хранилищу, не выдавайте одинаковые права всем инструментам. Разделите чтение, подготовку черновика, создание внутренней задачи и внешнее действие.
Отдельно проверьте составной риск. В многоагентной связке один агент может читать данные, второй — формировать решение, третий — вызывать API. Проверьте, какой результат дают полномочия агентов в общей цепочке. Поэтому тестировать нужно весь бизнес-процесс, включая передачу контекста и эскалации.
Для проверки можно взять исторические обезличенные случаи, если они отражают реальные задачи и подготовлены с учётом правил обработки данных. Команда заранее описывает правильный результат, запускает сценарий, сверяет журнал и разбирает отклонения. Затем можно дать агенту ограниченный набор новых задач, где сотрудник подтверждает внешние действия. Метрики пилота простые: доля корректных результатов, число ручных исправлений, число эскалаций, время обработки и нарушения политики доступа.
Почему политики важнее длинного промпта
Промпт задаёт агенту цель, формат ответа, последовательность шагов и условие эскалации. Сетевые вызовы, выданные токены и запись в CRM ограничивайте техническими политиками.
Политика доступа работает на другом уровне. Она определяет, какие действия разрешены технически. Например, агент службы поддержки может читать карточку клиента, искать ответ в базе знаний и создавать внутренний тикет. Отправку компенсации, изменение тарифа и выгрузку базы клиентов политика оставляет человеку с нужной ролью.
Руководитель видит порядок работы: задача поступила, агент собрал контекст в заданных границах, подготовил результат, передал его на подтверждение и сохранил журнал. Если сценарий требует больше прав, команда меняет политику через отдельную процедуру, по согласованной процедуре.
Кто отвечает за контроль AI-агента
У технической платформы должен быть владелец на стороне бизнеса. Обычно это руководитель функции, где работает агент: коммерческий директор для лидов, руководитель поддержки для обращений, финансовый директор для сверок. Он утверждает, какой результат считается полезным, какие исключения требуют человека и какую метрику проверяет команда.
IT и информационная безопасность отвечают за интеграции, идентификацию, журнал и правила доступа. Владелец процесса отвечает за регламент работы и качество результата. Юрист или специалист по персональным данным подключается там, где агент обрабатывает клиентские документы, договоры или персональные сведения. Эти участники согласуют полномочия и порядок проверки до запуска.
Полезно завести карточку сценария. В ней достаточно зафиксировать цель, владельца, входные данные, разрешённые системы, запретные действия, точку подтверждения, способ отката и метрики. Когда агент получает новую функцию, карточка проходит короткую повторную проверку. У команды появляется понятная история: кто одобрил изменение, какие права выдали и какой тест провели.
Где инфраструктурный контроль требует дополнения
Open Agent Safety Platform относится к уровню runtime и инфраструктуры. Для бизнеса этого слоя недостаточно, если в процессе нет каталога агентов, классификации данных и правил работы с подрядчиками. Организация должна знать, какие SaaS-продукты уже используют встроенных агентов, куда передаются данные и как отключить доступ при смене сотрудника или поставщика.
Также важно проверять качество решений. Техническая политика ограничивает действия агента; точность ответа команде придётся оценивать отдельно. Поэтому нужны эталонные кейсы, выборочная проверка сотрудником, критерии эскалации и регулярный разбор ошибок.
Именно поэтому запуск AI-агента лучше планировать как совместную задачу бизнеса, IT и безопасности. Инфраструктурные ограничения, регламент процесса и оценка качества должны появиться в одном пилоте. Решение о расширении сценария принимайте по журналу действий, итогам проверки и стоимости эксплуатации.
Как применить принцип NVIDIA в AI-офисе
Многоагентная система полезна, когда работа состоит из повторяемых ролей. Один агент собирает входящие сигналы, второй готовит материал, третий проверяет качество, четвёртый фиксирует результат и уведомляет владельца процесса. У каждой роли должны быть собственные данные, инструменты и критерий завершения.
В такой архитектуре имеет смысл вести единый реестр доступов и событий. Руководитель видит, какой агент использовал интеграцию, какой запрос сделал, какой ответ получил и почему задача ушла сотруднику. Для внешних сообщений, финансовых операций и изменения прав добавляют явное подтверждение.
Если вы строите несколько связанных ролей, рассмотрите HERMES как среду для мультиагентного сценария и координации задач. По этой ссылке читатель получает $15 на подписку HERMES. Перед подключением к корпоративным системам всё равно зафиксируйте роли, минимальные доступы, журнал действий и точки проверки человеком.
Практику подключения инструментов и ограничения полномочий полезно сопоставить с материалом о MCP для AI-агентов. Для оценки процесса до запуска пригодится статья о контроле качества AI-агентов.
План пилота для руководителя
Выберите один процесс с понятным входом и измеримым итогом. Например, первичная квалификация заявки: агент читает форму, сверяет обязательные поля, подготавливает карточку и предлагает ответственного. Зафиксируйте, какие поля доступны, какие действия разрешены и в какой момент подключается менеджер.
Затем прогоните подготовленные случаи. Проверьте, не получает ли агент лишние данные, не пытается ли вызвать ненужный инструмент и остаётся ли журнал достаточным для разбора. После этого включите сценарий для ограниченного набора новых заявок. Сравните результаты с заранее выбранными критериями перед расширением пилота.
Регулярно разбирайте с владельцем процесса завершённые задачи, эскалации и отклонения. По ним видно, где нужно уточнить правило, сократить доступ или дополнить базу знаний. После правки повторно проверьте сценарий.
Анонс NVIDIA от 28 сентября 2026 года показывает, как поставщик предлагает вынести контроль за действиями агента на уровень среды исполнения и оборудования. Руководителю стоит начать с процесса, владельца, границ доступа и правил подтверждения. После пилота команда сможет решить, нужен ли ей такой инфраструктурный уровень контроля.
Если хочешь внедрить ИИ агентов в свой бизнес, но не знаешь с чего начать, пиши мне в телеграм t.me/berdoff, я проведу бесплатную консультацию, поделюсь своим опытом.
