NVIDIA представила OpenShell: инженерный подход к защите ИИ-агентов от утечек данных

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

Архитектура защиты: контроль на каждом слое

ИИ-агент работает как система, состоящая из модели (интеллект), ханесса (контекст и инструменты) и среды выполнения (инфраструктура). Безопасность обеспечивается только тогда, когда есть ограничения на каждом из этих уровней.

• Разделение полномочий: Право агента обновлять запись клиента не должно автоматически давать ему доступ к экспорту этих данных в внешние системы. Агент может запросить дополнительные права, но не может выдать их сам себе.
• Технические барьеры: Сетевые политики должны блокировать передачу данных в несанкционированные адреса, даже если агент «решит» это сделать из-за вредоносной инструкции в документе.
• Логирование и аудит: Защищенные журналы должны фиксировать каждый вызов инструмента, решение о разрешении и результат. Это позволяет команде безопасности точно восстановить цепочку событий при инциденте: какой инструмент был использован и куда пытался уйти запрос.

Безопасность не может полагаться только на «инструкции» или промпты для модели. Ключевым элементом являются принудительные технические ограничения (firewall, права доступа), которые действуют независимо от того, насколько логично рассуждает ИИ-агент.

Инструментарий и экосистема NVIDIA

Для реализации этих принципов NVIDIA разработала OpenShell — open-source среду выполнения, которая накладывает политики безопасности вне зоны досягаемости самого агента. Она обеспечивает изолированное выполнение команд и контролирует доступ к данным, сети и системным ресурсам.

Экосистема вокруг OpenShell расширяется за счет партнеров из Open Secure AI Alliance:

• Cisco (продукт DefenseClaw) добавляет слой управления (governance).
• JFrog интегрируется для сканирования и верификации «навыков» (skills) агентов, контролируя, какие именно инструменты им доступны.

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

Командам разработки необходимо получать доказательства эффективности защиты до выхода системы в продакшн. Тестирование должно включать попытки:

• получить учётные данные за пределами назначенных задач;
• отправить конфиденциальные данные на внешние серверы;
• изменить права доступа или отключить мониторинг.

Эти тесты повторяются после каждого значимого изменения в модели, инструментах или рабочих процессах. Ответственность за готовность системы несет конкретный руководитель (named owner), который принимает решение о развертывании на основе результатов тестов. Любое обнаруженное уязвимость должно быть воспроизведено, исправлено и превращено в постоянный автотест для будущих релизов.

В примерах инструментов для такого подхода упоминаются CrowdStrike SafeMind (для симуляции атак) и Palo Alto Networks Prisma AIRS (для постоянного red-teaming).

Инструменты для защитников: открытые vs закрытые модели

При расследовании инцидентов критически важна возможность контроля над инфраструктурой.

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

Среди инструментов для автоматизации анализа уязвимостей выделяются Capital One VulnHunter (анализ кода) и ReversingLabs Spectra Assure (детект вредоносного ПО в пакетах).

Практические последствия для бизнеса

• Необходимость пересмотра политик доступа: Компании, внедряющие ИИ-агентов, должны разделить права доступа по принципу минимальной необходимости. Агент, работающий с CRM, не должен иметь сетевых прав на отправление писем или доступ к финансовым базам данных.
• Рост требований к логированию: Традиционные логи приложений недостаточно для аудита действий ИИ. Требуется внедрение систем, способных фиксировать семантический контекст запросов и технические детали вызовов инструментов (tool calls).
• Зависимость от экосистемы проверок: Безопасность перестает быть разовой настройкой. Она становится циклическим процессом: тестирование -> исправление -> повторное тестирование. Это требует интеграции систем безопасности в CI/CD пайплайны разработки ИИ-решений.

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