Почему промпт-инъекции — это симптом, а не болезнь безопасности ИИ

Что вы представляете, когда кто-то говорит об AI-driven компании? Может быть, как чат-боты улучшают опыт клиентов? Или как сотрудники разворачивают любые модели для своих нужд? А может, как ИИ-агенты разбирают кучу электронных писем и назначают встречи в календаре, копилоты пишут код за разработчиков и исправляют баги? Что в этой красивой истории может пойти не так и почему безопасность систем искусственного интеллекта не ограничивается защитой от джейлбрейков и промпт-инъекций – разберёмся в этой статье.

Привет, Хабр! Меня зовут Тимур, я старший эксперт по защите ИИ в Альфа-Банке, а до этого в лаборатории ИТМО активно разрабатывал LLAMATOR — инструмент для тестирования устойчивости LLM к промпт-атакам. И вот что я понял за полтора года погружения в безопасность ИИ.

На конференциях, митапах и в профильных телеграм-каналах я часто сталкиваюсь с такими лозунгами:

• «Системы теперь взламываются не кодом, а текстом!»

• «Нужно больше алаймента, гардрейлов и системных промптов!»

• «Нужно больше тестирования промпт-инъекциями!»

Промпт-инъекции действительно эффектно демонстрируют самые разнообразные уязвимости ИИ-приложений, но только ли в них дело? Спасут ли наши приложения гардрейлы, которые тоже являются ML-моделями, или обычным набором правил, и уязвимы к новым техникам атак? Более того, вредоносные действия LLM может генерировать сама из-за закладки в шаблонизаторе или просто потому, что так логиты сложились. Как раз об этом пример с отравленными метаданными и случай с токсичностью Gemini.

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

В кейсе с уязвимым MCP-сервером GitHub агенту было достаточно посмотреть в публичном репозитории issue, который содержал скрытую инструкцию. Согласно инструкции, агент подтянул в контекст данные из приватного репозитория и затем сам же опубликовал их в публичном pull request. MCP-сервер работал корректно, уязвимость возникла из-за отсутствия контроля потоков данных и границ доверия: внешний контент беспрепятственно влиял на вызовы инструментов с избыточными правами.

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

Ещё показательнее инцидент с GitHub Copilot, где промпт-инъекция привела к изменению локального конфиг-файла VS Code и удалённому выполнению кода. Добавление auto-approve для инструментов перевело агента в режим полного доверия, после чего он начал выполнять shell-команды без участия пользователя. В результате — удалённое выполнение кода на машине разработчика. Здесь промпт-инъекция стала лишь способом добраться до более опасного класса уязвимостей: неконтролируемого изменения среды исполнения.

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

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

Пора признать, что подход:

• «Давайте скажем модели быть полезной и безопасной».

• «Давайте добавим в контекст политики отказа».

• «Давайте протестируем атаки с промпт-инъекциями».

…вообще не работает.

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

Мы в Альфе пришли к такому чек-листу безопасности ИИ-приложений:

1. Настроены системные инструкции. Да, банальность — база. Но именно с чёткого разграничения ролей, разрешений и ограничений, и с техники «сэндвича» начинается наша эшелонированная защита.

2. Подключена валидация и фильтрация входов и выходов от чувствительных данных, системных сведений, токсичного контента, вредоносного кода, скрытых символов и управляющих команд с помощью JSON-схем, regexp-фильтров и гардрейлов.

3. Предусмотрена валидация действий агента. Здесь мы уже проверяем, что агенту можно, а что нельзя, корректны ли параметры вызовов тулов или MCP-серверов.

4. Каждый инструмент идемпотентный и обратимый или подтверждается информированным о последствиях Human-in-the-Loop с обязательным логированием личности подтверждающего.

5. Каждый агент обладает минимальным набором привилегий: права агентов чётко разграничены, в контекст LLM не могут попадать метаданные запросов и ключи доступа.

6. Zero-trust в механизмах аутентификации и авторизации агентов и инструментов: централизованное управление учётными данными (IAM), Just-in-Time доступ, доверенные хранилища секретов, mutual TLS.

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

8. Заданы и контролируются квоты на генерацию токенов и каждое действие агентов для обеспечения доступности сервисов.

9. Подключено логирование контекста, запросов, действий и ответов агентов, мониторинг и анализ аномалий поведения агентов в реальном времени с возможностью трассировки.

10. Настроено регулярное тестирование моделей, ассистентов и агентов – AI Red Teaming.

К слову об AI Red Teaming. Большинство open source инструментов устроены так, что они просто проверяют, можно ли заставить модель сказать «Х», если применить очередную крутую атаку. Как мы выяснили, обычного тестирования промпт-инъекциями недостаточно. AI Red Teaming должен отвечать не только на вопрос, как ведёт себя модель, но и на вопрос, можно ли через ассистента или агента взломать систему:

• повысить привилегии,

• выполнить несанкционированные или некорректные вызовы инструментов,

• получить доступ к метаданным запросов, системным инструкциям, описаниям инструментов, персональным данным, коммерческой или банковской тайне,

• «отравить» память агента или внедрить вредоносную инструкцию в базы данных,

• вызывать недоступность системы или смежных служб.

OWASP в прошлом году выпустил подробный гайд, в котором они выделяют 4 уровня тестирования безопасности ИИ-систем:

1. Модель: этичность и устойчивость к атакам.

2. Расширения: системные промпты, гардрейлы, базы знаний.

3. Система: интеграции, инфраструктура, цепочки поставок.

4. Runtime: пользовательские взаимодействия, поведение агентов, влияние на бизнес-процессы.

И такие проверки должны быть постоянными и встроенными в жизненный цикл ИИ-приложений.

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

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