NVIDIA использует новый пост своей AI Red Team, чтобы поднять более широкий вопрос о внедрении корпоративного ИИ: если компании хотят поставить ИИ-агентов перед реальными инструментами, кодовыми базами и внутренними данными, им нужны инфраструктурные меры контроля вне самой модели.

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

Предупреждение NVIDIA касается архитектуры агентов, а не настройки промптов

Пост под названием «Four Ways to Deploy More Secure AI Agents» исходит от NVIDIA AI Red Team и сосредоточен на том, что происходит, когда большая языковая модель подключается к живым системам через агентский harness. NVIDIA описывает проблему в практических корпоративных терминах: цифровой сотрудник, который может просмотреть баг-репорт, внести исправление, запустить тесты и отправить патч, повышает продуктивность, но та же схема может создать привилегированное ПО с широкой и плохо понимаемой поверхностью атаки.

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

Главный аргумент компании в том, что защиты внутри плоскости управления моделью недостаточно надежны под давлением противника. Согласно посту, защиты на основе промптов и схемы «LLM-as-a-judge» стабильно уязвимы для социальной инженерии, постепенной манипуляции по типу «варки лягушки» и атак, скрытых внутри, казалось бы, легитимных рабочих процессов. Позиция NVIDIA такова: нужны детерминированные меры контроля, enforced вне модели.

Четыре меры контроля, которым NVIDIA рекомендует отдать приоритет

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

Во-вторых, NVIDIA предупреждает, что выполнение команд по-прежнему остается самым опасным риском в доступных агентах. Многие агентские фреймворки предоставляют shell, потому что это гибко и снижает необходимость в специализированных инструментах. Но если вывод модели может запускать выполнение команд, то prompt injection или вредоносный пользовательский ввод могут превратить обычные команды разработчика в путь к произвольному выполнению кода. NVIDIA отмечает, что команды, обычные для рабочих процессов разработки ПО, включая установку пакетов и запуск тестов, могут выглядеть достаточно безобидно, чтобы пройти модель-ревьюер, и при этом все же позволять компрометацию.

Компания рекомендует изолированные среды выполнения, такие как Docker или NVIDIA OpenShell, ограничения на уровне ОС, не позволяющие записывать вне невыполняемых рабочих пространств, и очень узкие allowlist для исполняемых команд, если доступ к командной строке неизбежен. Также подчеркивается более тонкий риск: даже без shell инструменты чтения и записи файлов могут позволить повышение привилегий, если агент может изменять стартовые файлы, конфигурационные файлы или другие места, которые позже будут выполнены другим процессом.

В-третьих, NVIDIA заявляет, что исходящую связь следует жестко ограничить политиками network egress по умолчанию deny. По данным Red Team, неограниченные исходящие соединения упрощают эксфильтрацию данных и позволяют reverse shell или другой прямой операторский доступ в среду выполнения агента. NVIDIA сообщает, что когда egress-контроль применялся правильно, атаки становились медленнее, менее надежными и труднее поддерживаемыми, потому что взаимодействие должно было продолжать проходить через агента, а не через прямой внешний канал. Для разработчиков это означает конкретное правило развертывания: разрешать только минимально необходимые внешние конечные точки для задачи агента.

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

Почему это важно сейчас для кодовых инструментов и корпоративного ИИ

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

Это делает данное руководство особенно актуальным для команд, разворачивающих помощник по кодированию или другие автономные инструменты рабочих процессов. Агент, ориентированный на код, часто должен запускать тесты, просматривать файлы, устанавливать пакеты и подключаться к системам контроля версий. Именно такие возможности, по мнению NVIDIA, могут стать небезопасными, если меры защиты опираются главным образом на суждение модели. Упоминание файлов вроде конфигурации git и model context protocol также указывает на формирующуюся экосистему агентских инструментов, где гибкие интеграции могут незаметно создавать новые пути для закрепления.

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

Доказательства, утверждения и что остается непроверенным

Эта история почти полностью основана на собственном сообщении NVIDIA через NVIDIA Developer Blog, а второй источник лишь отражает тот же материал в ленте Google News. Это означает, что ключевые выводы следует читать как наблюдения Red Team от поставщика, а не как независимые отраслевые измерения.

Тем не менее NVIDIA дает полезную конкретику. Компания говорит, что ее AI Red Team оценила несколько агентов за последние шесть месяцев и обнаружила повторяющиеся эксплуатируемые шаблоны в разных фреймворках и harnesses. Она также приводит конкретные примеры рискованного поведения, включая использование shell для запуска установки пакетов или скриптов, запись в стартовые shell-файлы и использование неограниченного исходящего трафика для эксфильтрации или удаленного доступа.

Однако пост не указывает, сколько агентов было протестировано, какие вендоры или open-source стеки участвовали, как часто проявлялся каждый режим отказа и сколько инцидентов произошло в продакшене. Он также не приводит сравнительных бенчмарков, показывающих эффективность одного набора контролей по сравнению с другим. Поэтому руководство лучше всего понимать как практический архитектурный совет от Red Team с опытом прямого тестирования, а не как исчерпывающее исследование рынка.

Критика фильтрации промптов и схем LLM-as-a-judge также является оценкой NVIDIA. Многие команды безопасности, вероятно, согласятся с общим направлением, но статья не содержит внешне валидированных результатов тестов в предоставленных доказательствах. Это не делает предупреждение менее значимым; это лишь означает, что читателям следует отделять общий урок от предположения, будто все агентские продукты ломаются одинаково.

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

Для разработчиков самый очевидный сдвиг — от безопасности на уровне приложения к безопасности на уровне системы. Если ИИ-агент может взаимодействовать с ресурсами, близкими к production, то дизайн развертывания начинает иметь большее значение, чем хитрое prompt engineering. Границы sandbox, передача идентичности, allowlist для конечных точек и изоляция секретов становятся ключевыми продуктовыми решениями.

У этого есть последствия для стоимости и рабочих процессов. Sandboxing может замедлять выполнение или усложнять среду разработки. Политики egress по умолчанию deny требуют от команд детального картирования зависимостей. Сопоставление прав по пользователям может потребовать более глубокой интеграции с корпоративными системами идентификации. Но такие ограничения могут быть необходимы, если компании хотят перевести ИИ-агентов из экспериментов в одобренные корпоративные рабочие процессы.

Руководство также предлагает более зрелое определение автоматизации рабочих процессов. Вместо того чтобы спрашивать, может ли агент завершить процесс end-to-end, командам, возможно, нужно спрашивать, способен ли он сделать это в строго ограниченном радиусе поражения. Это повлияет на архитектурные решения на всех корпоративных ИИ-платформах, включая то, какие инструменты открыты, где они работают и какой уровень автономии приемлем.

За чем следить дальше

Полезным сигналом будет то, начнут ли крупные агентские фреймворки и корпоративные платформы поставлять эти меры контроля по умолчанию, а не как необязательные шаги по hardening. В частности, разработчикам стоит следить за более тесной интеграцией sandboxing, более гранулярными моделями идентификации и авторизации, более удобными политиками сетевого egress и дизайнами секретов, которые избегают долговременных учетных данных.

Второй сигнал — будут ли больше вендоров публиковать данные adversarial testing вместо общих заявлений о безопасности. Пост NVIDIA поднимает заслуживающие доверия опасения, но рынку по-прежнему не хватает согласованных сторонних доказательств того, насколько распространены такие режимы отказа агентов в разных продуктах.

Наконец, стоит отслеживать, станут ли secure-by-default паттерны частью закупок ИИ-агентов, особенно в регулируемых отраслях. Если покупатели начнут требовать доказательства изоляции и соблюдения наименьших привилегий, архитектура безопасности может стать конкурентным преимуществом, а не просто бэк-офисным чек-листом.

Взгляд Creati.ai

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

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