Как защитить ИИ-агентов: четыре типовых провала от NVIDIA AI Red Team

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

Четыре типовых провала

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

Второй — инструменты, дающие произвольное выполнение кода. Многие каркасы открывают агенту Bash или командный инструмент: они удобны, но когда выводом модели управляет команда, атакующий, влияющий на этот вывод напрямую или через непрямую prompt injection, получает выполнение команд в среде — вплоть до выгрузки данных и закрепления на хосте. Иногда полный RCE с reverse shell получается простой просьбой написать и выполнить Python-скрипт или установить удалённый пакет.

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

Отдельный вывод: защиты на промптах и схемы LLM-as-a-judge ненадёжны. Судья-модель охотно пропускает команды вроде pytest или npm install — а под влиянием атакующего ввода это уже произвольное выполнение команд. Социальная инженерия, атаки «лягушка в кипятке» (frog-boiling) и увод через легитимные рабочие процессы тоже проходят мимо модельных защит. Нужны детерминированные архитектурные меры, работающие вне плоскости контроля модели.

Что действительно работает

  • Жёсткий контроль доступа: агент только для явно авторизованных пользователей, права агента соответствуют правам вызывающего — принцип наименьших привилегий. В тестах агенты, которые игнорировали неавторизованных пользователей, эксплуатировать было заметно сложнее.
  • Ограничение выполнения кода: песочное окружение, например Docker или NVIDIA OpenShell.
  • Исходящий трафик по умолчанию запрещён, доступ только через разрешающие списки с наименьшими привилегиями.
  • Никаких постоянных секретов в окружении агента.
  • Строгая проверка источников пакетов и прав инструментов.

Для команд, которые внедряют агентов в продуктовые процессы, список удобно читать как чек-лист безопасности до инцидента, а не после.

Источник: developer.nvidia.com