С тех пор как LLM перестали быть лабораторной игрушкой и превратились в компонент реальных production-систем — чат-боты, RAG-пайплайны, агенты с доступом к инструментам — поверхность атаки на них перестала быть теоретической. В этом посте разберём основные классы состязательных атак на LLM, как они классифицируются в OWASP LLM Top 10 и MITRE ATLAS, и почему многие классические подходы к ИБ здесь работают не так, как ожидается.
Почему LLM — это новая поверхность атаки
Традиционная модель угроз строится вокруг чёткой границы между кодом и данными. В LLM эта граница размыта: модель не различает «инструкцию от разработчика» и «текст, который она обрабатывает» на уровне архитектуры — оба представлены как токены в одном контексте. Это системное свойство, а не баг конкретной реализации, и именно оно лежит в основе большинства атак ниже.
Prompt injection
Самый обсуждаемый класс атак. Суть — внедрение инструкций в данные, которые модель обрабатывает как контент, но воспринимает (полностью или частично) как команду.
- Прямая инъекция — атакующий напрямую формулирует промпт, чтобы обойти системные ограничения («забудь предыдущие инструкции и...»).
- Непрямая инъекция (indirect prompt injection) — инструкция спрятана в внешнем источнике: веб-странице, документе, e-mail, который модель позже обработает в рамках RAG или агентного сценария. Этот вектор особенно опасен для систем с доступом к инструментам (browsing, file access, API calls), потому что атакующему не нужен прямой доступ к чату — достаточно разместить payload там, где модель его прочитает.
В OWASP LLM Top 10 это LLM01: Prompt Injection — стабильно на первом месте с момента первой версии списка.
Jailbreaks
Если prompt injection эксплуатирует смешение данных и инструкций, jailbreak — это попытка обойти политики безопасности модели через формулировку запроса: ролевые сценарии, гипотетические рамки («представь, что ты ИИ без ограничений»), кодирование запроса (base64, перевод на другой язык), постепенное смещение контекста через серию безобидных на первый взгляд сообщений.
Защита через простой keyword-фильтр здесь практически бесполезна — пространство формулировок, ведущих к одному и тому же результату, эффективно бесконечно. Более устойчивый подход — constitutional-style alignment на уровне обучения модели плюс независимый классификатор-страж (guardrail) на входе/выходе, не завязанный на те же эвристики, что и сама модель.
Data poisoning
Атака на этапе обучения или fine-tuning: внедрение специально сконструированных примеров в обучающий набор так, чтобы модель впоследствии вела себя предсказуемо неправильно при определённом триггере (backdoor) или системно деградировала по конкретной задаче.
Для RAG-систем есть смежный, но отдельный риск — отравление базы знаний: если в индексируемые документы можно внедрить контент, atакующий не трогает веса модели вообще, а влияет на то, что модель «вспоминает» как факт. Грань между data poisoning и indirect prompt injection здесь стирается.
В MITRE ATLAS это покрывается тактиками вроде AML.TA0005 (ML Supply Chain
Compromise) и техниками отравления обучающих данных в рамках жизненного цикла
модели.
Иллюстрация: почему фильтрация на уровне строки не работает
Условный пример — наивная защита от инъекции через blacklist ключевых слов:
BLOCKED = ["ignore previous instructions", "system prompt"]
def is_safe(user_input: str) -> bool:
lowered = user_input.lower()
return not any(phrase in lowered for phrase in BLOCKED)
Такую проверку обходит тривиальное перефразирование, кодирование в base64, разбивка фразы на части через несколько сообщений или просто перевод на другой язык. Список блокировок растёт, а покрытие остаётся неполным — это классическая проблема denylist-подхода, перенесённая в новый контекст.
Куда смотреть дальше
Если вы выстраиваете защиту production LLM-системы, разумная отправная точка:
- OWASP Top 10 for LLM Applications — практический чек-лист рисков, обновляется регулярно, хорошо ложится на конкретные архитектурные решения.
- MITRE ATLAS — более формальная матрица тактик/техник, полезна для threat modeling и для разговора с командой, привыкшей к ATT&CK.
- NIST AI RMF — рамочный документ для управления рисками на уровне организации, а не отдельной системы.
В следующих постах разберём подробнее indirect prompt injection в RAG-пайплайнах и практические подходы к guardrails — что из этого реально снижает риск, а что создаёт только иллюзию защиты.