Безопасность AI-агентов: 4 ключа к защите от атак

Интеграция AI-агентов в рабочие процессы современных предприятий перешла из стадии экспериментов в фазу активного внедрения. Представьте себе цифрового коллегу, который не просто отвечает на вопросы, но и самостоятельно анализирует отчеты об ошибках, пишет код, тестирует исправления, отправляет патчи и уведомляет человека о необходимости ревью. Такие агенты обещают колоссальный прирост производительности, освобождая сотрудников от рутины. Однако за этим удобством скрывается серьезная угроза: подключение большой языковой модели (LLM) к живым инструментам и корпоративным данным через «агентный арматурный каркас» (agentic harness) может превратить полезного ассистента в программное обеспечение с привилегиями, поверхность атаки которого до конца не изучена.

Команда NVIDIA AI Red Team провела масштабное исследование, оценив множество AI-агентов — от простых интерактивных инструментов для кодинга до автономных цифровых помощников, работающих в режиме 24/7. Результаты оказались пугающе единообразными: независимо от используемого фреймворка или платформы, уязвимые агенты демонстрируют одни и те же критические ошибки в архитектуре безопасности. Понимание этих уязвимостей и применение правильных контрмер — это не просто рекомендация, а необходимость для любого предприятия, стремящегося использовать силу AI без риска компрометации инфраструктуры.

01Четыре критические уязвимости AI-агентов

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

1. Отсутствие контроля доступа к агенту

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

2. Инструменты агента, позволяющие выполнять произвольный код

Многие агентные платформы предоставляют доступ к оболочке Bash или инструментам выполнения команд. Это удобно для широкого спектра задач, но создает риск выполнения произвольного кода. Если модель может управлять выполнением команд, злоумышленник, влияющий на вывод модели (через прямой ввод или косвенную инъекцию промптов), может выполнить вредоносные действия. Это включает в себя эксфильтрацию данных или закрепление в хост-системе. Даже без прямого доступа к командной строке возможность чтения и записи файлов может привести к выполнению кода через модификацию конфигурационных файлов, таких как ~/.bashrc или ~/.gitconfig.

3. Отсутствие ограничений исходящего сетевого трафика (Egress)

Исходящие сетевые соединения позволяют злоумышленникам эксфильтровать данные и создавать прямые соединения, такие как обратные оболочки (reverse shells) и SOCKS-прокси. Это дает атакующему прямой контроль над средой выполнения агента. Когда такие ограничения были применены, исследователям приходилось замедлять темп атак, так как каждый шаг требовал обхода фильтров, что делало эксплуатацию менее надежной и более заметной.

4. Секреты в открытом виде в среде агента

Агентам часто требуются доступы к секретам: токены платформ, API-ключи, токены доступа к системам контроля версий (VCS) и даже OAuth-токены обновления. Традиционная практика передачи секретов через переменные окружения в памяти контейнера становится опасной, когда в этой среде выполняется произвольный код. Команды вроде env или printenv позволяют мгновенно увидеть все секреты. Кроме того, CLI-инструменты часто кэшируют учетные данные на диске в предсказуемых местах, таких как .env файлы, история bash или .netrc.

02Почему защитные промпты и LLM-as-a-Judge не работают

Многие разработчики пытаются решить проблему безопасности, добавляя в системный промпт инструкции избегать рискованного поведения или используя вторую модель для оценки входов и выходов (паттерн LLM-as-a-Judge). Однако команда NVIDIA AI Red Team установила, что эти методы ненадежны против состязательных техник. Атаки, основанные на социальной инженерии, «выпаривании лягушки» и перенаправлении через легитимные рабочие процессы, регулярно обходят такие защиты. Причина проста: эти защиты сами enforced by LLM и наследуют вероятностную, ненадежную природу самой модели. Архитектурные детерминированные контрольные механизмы, работающие вне контура модели, являются единственным надежным решением.

03Стратегия 1: Строгий контроль доступа

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

04Стратегия 2: Ограничение выполнения кода

Рассматривайте выполнение произвольного кода как риск с наивысшим уровнем воздействия. Избегайте инструментов командной строки, где это возможно. Если они необходимы, используйте строгие списки разрешений (allowlists) для исполняемых команд и запускайте их в изолированной среде выполнения с сильными сетевыми ограничениями.

Критически важно блокировать запись за пределы неисполняемого рабочего пространства на уровне операционной системы. Агенты должны иметь возможность писать только в специально отведенные, безопасные каталоги. Если агенту требуется выполнять задачи, связанные с разработкой, такие как запуск тестов (pytest) или установка пакетов (npm install), это должно происходить в строго контролируемой песочнице. Аргументы командной строки, такие как имена файлов, должны быть санитизированы и нормализованы перед использованием, чтобы предотвратить атаки типа path traversal или command injection.

05Стратегия 3: Запрет исходящего трафика по умолчанию

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

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

06Стратегия 4: Изоляция секретов

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

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

07Детерминированные контрольные механизмы как основа защиты

Защита в том же контуре управления, что и LLM, особенно основанная на промптах, регулярно обходится. Контрольные механизмы должны быть enforced вне контура модели. Вот рекомендуемый порядок важности контрмер:

1. Контроль доступа к агенту: Только конкретные, аутентифицированные пользователи должны иметь возможность взаимодействовать с агентом.
2. Выполнение произвольного кода только в песочнице: Используйте Docker, NVIDIA OpenShell или виртуальную машину. Среда должна быть должным образом защищена от побега. Она не должна иметь возможности настраивать себя путем записи или редактирования файлов окружения или конфигурации агента.
3. Запрет исходящего трафика по умолчанию: С списком разрешений наименьших привилегий для конкретных сетевых ресурсов на каждой границе, которую затрагивает агент.
4. Не раскрывать секреты в состоянии покоя или в среде: Храните секреты в менеджере секретов, получайте доступ по требованию и ограничивайте их процессом, которому они нужны.
5. Разрешать установку пакетов только из проверенных репозиториев: Блокируйте произвольные установки по URL и VCS по умолчанию.
6. Инструменты с наименьшими привилегиями: Только те инструменты, которые требуются для работы; тщательно проверяйте все, что выполняет код, пишет данные или обращается к сети.
7. Постоянное хранилище с наименьшими привилегиями: Избегайте монтирования томов; если это невозможно, строго ограничивайте их и никогда не монтируйте ничего записываемого в путь, который позже будет выполнен.
8. Используйте последние модели: Особенно для паттернов LLM-as-a-Judge, которые могут быть более устойчивы к состязательным манипуляциям.

08Что это значит на практике

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

На практике это означает:

• Разделение сред выполнения: агенты должны работать в изолированных контейнерах с ограниченными правами.
• Централизованное управление секретами: интеграция с HashiCorp Vault, AWS Secrets Manager или аналогами.
• Сетевая сегментация: агенты не должны иметь прямого доступа к интернету или внутренним сетям без явного разрешения.
• Мониторинг и аудит: все действия агентов должны логироваться и анализироваться на аномалии.

Полностью автономные системы с корпоративными учетными данными inherently рискованны и должны быть тщательно защищены. Хотя передовые модели делают состязательные манипуляции более сложными, при достаточном времени и экспертизе почти все они могут быть обмануты. Только архитектурные контрольные механизмы — контроль доступа, укрепленные песочницы с доступом к корпоративным данным с наименьшими привилегиями, запрет исходящего трафика по умолчанию и секреты, находящиеся вне досягаемости агента, — могут эффективно снизить риск состязательного злоупотребления AI-агентами.

Для тех, кто хочет углубиться в тему, NVIDIA рекомендует ознакомиться с техническим блогом «How to Govern Autonomous Agents in Enterprise AI Factories» и презентацией на Black Hat USA, где рассматриваются вопросы эксплуатации AI-агентов с использованием открытых моделей. Безопасность AI-агентов — это не опция, а обязательное условие для их безопасного и эффективного использования в enterprise-среде.

Источник: NVIDIA Developer ↗