Защита ИИ-агентов от prompt injection для SOC

CVE-2025-32711 - zero-click эксфильтрация данных через Microsoft 365 Copilot, CVSS 9.3 (Critical), CWE-74 (Injection). Вектор: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N - сетевой доступ, низкая сложность, привилегии не нужны, пользователь ничего не нажимает, scope изменён. Aim Security нашла уязвимость, Microsoft закрыла её в мае 2025-го. Атакующий отправляет письмо с инструкцией в Markdown-разметке. Жертва его даже не открывает. Copilot читает письмо при фоновой обработке через RAG-движок, воспринимает скрытую команду как часть задачи и сливает фрагменты переписки, файлы OneDrive и SharePoint на внешний сервер. SIEM видит стандартный HTTPS-трафик. EDR молчит - нет ни shellcode, ни lateral movement. Ни одного IOC в привычном понимании. Для SOC-команды, которая годами выстраивала detection на сетевых артефактах и endpoint-телеметрии, это слепая зона без дна.

Kill chain: от письма до эксфильтрации через ИИ-агента​

Бизнес-логика атаки: зачем это злоумышленнику​

Prompt injection атаки на корпоративных ИИ-агентов - не jailbreak ради фана. Это вектор кражи данных и несанкционированных действий от имени легитимного пользователя. По данным Palo Alto Networks (Unit 42), в тройке целей при косвенных инъекциях: несанкционированный вывод данных (28.6%), уничтожение информации (14.2%) и обход модерации контента (9.5%). ИИ-агент с доступом к почте, CRM и документам - идеальный посредник: его запросы легитимны для SIEM, а украденные данные монетизируются стандартно - от продажи корпоративных секретов до целевого шантажа.

Контекст для Blue Team: если агент обрабатывает персональные данные (ПДн), успешная prompt injection с эксфильтрацией - это инцидент по ФЗ-152 с потенциальными оборотными штрафами. Приказ ФСТЭК №21 требует мер защиты ПДн, но пока не содержит явных требований к LLM-инфраструктуре - серая зона, где отвечает тот, кто интегрировал агента в контур обработки.

По данным CrowdStrike Global Threat Report 2025, вредоносное использование GenAI для социальной инженерии удвоилось за 2024 год. IBM X-Force фиксирует: генерация фишинговых писем с помощью GenAI быстрее в 11.4 раза при сопоставимом качестве - тот же принцип применим к созданию обфусцированных prompt injection payload. Безопасность ИИ-агентов в компании - задача не ML-инженеров, а SOC.

Прямая и косвенная инъекция: разница для detection​

MITRE ATT&CK формализовала оба вектора как техники тактики Execution:

Прямая инъекция (T1699, Direct Prompt Injection) - атакующий вводит вредоносную команду через интерфейс агента. Детектируется проще: есть конкретная сессия, пользователь, ввод. Фильтрация паттернов (ignore previous instructions, you are now in developer mode) работает как первый рубеж. Но по данным OWASP LLM Prompt Injection Prevention Cheat Sheet, input screening - "is not a security boundary". Перефразирование, Base64-кодирование и typoglycemia-атаки (скрэмблирование букв: ignroe prevoius systme instructions) обходят keyword-фильтры на раз.

Косвенная инъекция (T1698, Indirect Prompt Injection) - инструкция спрятана во внешнем контенте: письме, веб-странице, документе в RAG-базе, ответе другого агента через MCP. Это доминирующий вектор в корпоративных инцидентах с 2024 года, по данным Sysdig. Именно через T1698 сработал EchoLeak - инъекция сидела в письме, которое жертва даже не открывала.

Дополнительный вектор - Content Injection (T1659, тактики Initial Access и Command and Control): доставка payload в контент, обрабатываемый агентом.

"Смертельная триада": фреймворк оценки рисков​

Исследователь Саймон Уиллисон сформулировал концепцию "lethal trifecta" - ИИ-агент эксплуатируем, когда у него одновременно:

1. Доступ к приватным данным - переписка, документы, CRM
2. Обработка недоверенного контента - входящая почта, веб-страницы, загруженные файлы
3. Возможность передавать информацию вовне - API-вызовы, генерация ссылок, отправка сообщений

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

Помимо EchoLeak, за 2024-2025 годы зафиксировано несколько публичных prompt injection инцидентов на корпоративные ИИ-системы. Атака Reprompt на Copilot Personal (Varonis) использовала URL-параметр для инъекции - один клик запускал эксфильтрацию. По данным Sysdig, цепочка indirect prompt injection + отсутствие approval при создании файлов, приводящая к RCE, продемонстрирована на Cursor IDE (CVE-2025-54135, CVSS 8.5 HIGH) и GitHub MCP. Каждый инцидент укладывается в паттерн "смертельной триады".

Prompt injection в MITRE ATT&CK: маппинг для SOC​

Уязвимости языковых моделей - уже не экзотика из мира ML, а формализованные техники ATT&CK:


OWASP LLM Top 10 (2025) дополняет ATT&CK-картину:

• LLM01:2025 - Prompt Injection - первое место второй год подряд
• LLM06:2025 - Excessive Agency - избыточные полномочия агента усиливают blast radius инъекции
• LLM07:2025 - System Prompt Leakage - утечка системного промпта раскрывает бизнес-логику и упрощает последующие атаки на нейросети

Если SOC уже строит detection по ATT&CK-матрице, добавление T1698 и T1699 - обязательный шаг. Корреляция с T1659 позволяет отслеживать начальный вектор доставки.

Что видит SOC-аналитик: baseline и аномалии​

Вторник, 9:15 утра. Разгребаю утренние алерты. В логах API-шлюза корпоративного ИИ-ассистента - серия вызовов send_message за ночь. Baseline для этого агента - 3-5 вызовов в час. За последние 8 часов - 47. В параметрах нескольких вызовов - URL с base64-encoded строкой в query parameters. Декодирую: фрагмент внутренней переписки о квартальных результатах. SIEM не сработал - HTTPS, легитимный User-Agent, объём трафика в пределах стандартных порогов. Только ручная проверка логов tool calls выявила аномалию.

Типичная картина успешной косвенной prompt injection. Вопрос - как перестроить мониторинг, чтобы алерт прилетел до эксфильтрации, а не после.

Критические точки сбора событий​

Для detection prompt injection на ИИ-агентах нужен отдельный слой логирования. В стандартном SOC его нет:


Microsoft в стратегии защиты от indirect prompt injection (блог MSRC, июль 2025) выделяет три уровня: предотвращение инъекции (hardened system prompts, техника Spotlighting для изоляции недоверенных данных), обнаружение (Prompt Shields, интеграция с Defender for Cloud), предотвращение последствий (governance, consent workflows, детерминистическая блокировка методов эксфильтрации). Для защиты LLM в бизнесе нужны guardrails на каждом из этих уровней.

Baseline поведения агента​

Набор метрик для построения baseline (аналогично DE.AE-01 по NIST CSF - baseline сетевых операций):

• Частота tool calls - рост за пределами 2σ от среднего за неделю
• Распределение вызываемых инструментов - появление ранее неиспользуемых функций
• Длина и структура output - резкие изменения в формате ответа
• Внешние URL в output - генерация ссылок, отсутствующих в запросе пользователя
• Обращения к RAG-источникам - запрос документов вне типичного паттерна пользователя

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

Detection rules: корреляция в SIEM​

Порог 20 tool calls/час - отправная точка, калибруйте под реальный baseline конкретного агента. Дополнительно мониторьте попытки извлечения системного промпта (OWASP LLM07:2025): паттерны repeat the text above, what are your instructions, print your system prompt во входящих запросах. Это не security boundary (манипуляция промптами обходит фильтры), но создаёт дополнительный сигнал для корреляции.

Архитектурный hardening корпоративных ИИ-систем​

Минимальные привилегии агента (OWASP LLM06)​

OWASP LLM06:2025 (Excessive Agency) - главный усилитель blast radius. Тут всё как с обычными сервисными учётками, только хуже, потому что агент сам решает, какой инструмент вызвать. Чеклист:

• Документировать разрешённые tool calls для каждого агента - остальное блокировать на API Gateway
• Разделить read-only и write-операции: агент для суммаризации не должен отправлять сообщения
• Отдельные сервисные учётные записи с минимальными правами, не учётка сотрудника
• Весь исходящий трафик агента - через allow-list на прокси, прямой доступ к внешним URL запрещён

Изоляция недоверенного контента​

Microsoft использует технику Spotlighting - маркировка границ между системным промптом и обрабатываемыми данными. На уровне архитектуры:

• Внешние документы и письма передавать агенту с явной маркировкой, не подмешивая в контекст наравне с системными инструкциями
• Случайный token-разделитель (UUID) для каждой сессии - атакующий не закроет тег без знания строки
• Санитизация HTML-комментариев, CSS-скрытого текста (display: none), метаданных до попадания в контекст модели

Валидация output перед выполнением действий​

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

• Исходящие URL проверять по allow-list
• Объём передаваемых данных не превышает порог для типа операции
• Структура ответа соответствует JSON-схеме для конкретного tool call
• Маркеры sensitive data (номера карт, ПДн) в исходящих сообщениях - автоматическая блокировка

Microsoft называет это "deterministic blocking of known data exfiltration methods" - подход не зависит от способности модели распознавать jailbreak LLM или инъекции. И это правильно: модель не должна сама себя защищать.

Human-in-the-Loop для критичных операций​

Для необратимых действий (отправка данных вовне, модификация CRM, финансовые транзакции) - обязательное подтверждение человеком. Это разрывает третье звено "смертельной триады". Даже при успешной инъекции агент не выполнит действие без одобрения. По данным IBM X-Force, среднее время между публикацией CVE и устранением - 29 месяцев. Human-in-the-Loop - компенсирующий контроль на то время, пока архитектурные уязвимости LLM-инфраструктуры не закрыты.

Incident response: playbook при подтверждённой prompt injection​

Containment (первые 30 минут):

1. Отозвать API-ключи и токены скомпрометированного агента
2. Отключить агента от внешних интеграций (почта, CRM, tool calls)
3. Зафиксировать context window и логи tool calls за последние 72 часа
4. Проверить долговременную память агента на stored injection

Investigation (1-4 часа):

1. Определить вектор: какой контент содержал инъекцию (письмо, документ, RAG-источник)
2. Оценить blast radius: какие данные были в context window в момент эксплуатации
3. Проверить логи исходящих запросов: куда и что отправлял агент
4. Очистить RAG-базу от poisoned documents
5. Пересоздать агента с новыми credentials и ужесточёнными привилегиями
6. Добавить обнаруженные паттерны инъекции в detection rules
7. Если затронуты ПДн - уведомление регулятора по ФЗ-152, оценка ущерба субъектам данных

Большинство SOC-команд подходят к detection prompt injection неправильно - пытаются ловить саму инъекцию на входе. Фильтры ключевых слов, ML-классификаторы промптов, regex-паттерны. Тупиковый путь. OWASP Cheat Sheet прямо указывает: input screening "is not a security boundary". Атакующий перефразирует инструкцию тысячей способов, которые deny-list не поймает. Typoglycemia, Base64, Unicode-smuggling - техники обфускации растут быстрее фильтров.

Перспективнее мониторить не вход, а поведение: аномальные tool calls, нетипичные обращения к RAG-источникам, генерация внешних URL в output. Это конечный набор действий, который детектируется стандартным SIEM без дорогих ML-классификаторов. Не нужно решать NLP-задачу - нужно решать задачу мониторинга.

Мультиагентная архитектура с layered agents для санитизации и policy enforcement (arxiv 2503.11517) снижает Injection Success Rate, но добавляет latency и архитектурную сложность. Для SOC без выделенной ML-команды - оверинжиниринг. Руководство Five Eyes по безопасности agentic AI (CISA, NSA и партнёры) прямо говорит: ни одна мера не достаточна сама по себе.

Разрыв между скоростью развёртывания ИИ-агентов и скоростью выстраивания detection будет расти. Кто начнёт собирать телеметрию LLM-агентов и строить baseline сейчас - через год будет иметь работающие правила корреляции. Остальные будут разбирать постмортемы. Тематический тред с playbook'ом по этой группе TTP - на codeby.net.