Формулировка риска и её смысл
OWASP описывает LLM01 как ситуацию, когда входные данные изменяют поведение модели неожиданным для приложения образом. Сухая формулировка скрывает масштаб: «входные данные» — это всё, что модель когда-либо прочитает, а «изменение поведения» — спектр от изменённого тона ответа до выполнения операции в учётной системе.
Позиция устойчиво первая по двум причинам. Во-первых, уязвимость конституциональна для архитектуры больших языковых моделей: инструкции и содержимое кодируются одинаково, надёжного разделителя нет. Во-вторых, LLM01 — усилитель остальных пунктов перечня: скомпрометированная модель раскрывает данные (LLM02), действует через чужие права (LLM06), генерирует вредоносный вывод (LLM05). Закрытая первой позицией система дешевеет по всем остальным.
Два проявления одного риска
Внутри LLM01 различают непосредственное воздействие — команду пишет сам атакующий в интерфейсе приложения, и опосредованное — команда уже сидит в материале, который конвейер подаст модели без участия человека: страница, письмо, файл, запись базы, результат работы другого сервиса. Второе проявление считается более опасным: след атаки теряется в объёме легитимных данных, а одна закладка срабатывает многократно при каждом обращении к источнику.
Подробное сравнение этих форм с примерами вынесено в отдельный материал раздела; здесь важен вывод для приоритизации: меры против одной формы почти не работают против другой, проверять надо обе.
Почему классические средства не спасают
Команды безопасности по инерции пытаются решить задачу знакомыми инструментами, и три попытки типично проваливаются. WAF-подход со списками подозрительных фраз — язык слишком гибок, формулировка обходится заменой пары слов. «Усиленный системный промпт» — помогает против грубых попыток и проигрывает продуманным многошаговым воздействиям. Полный отказ от внешних данных в контексте — убивает сам смысл большинства корпоративных сценариев: ассистент, который ничего не читает, никому не нужен.
Работающая логика иная: признать возможность компрометации и строить систему так, чтобы успешная инъекция стоила дёшево. Отсюда приоритеты OWASP: контроль привилегий и действий, изоляция недоверенных данных, поведение по умолчанию с минимальными правами.
Самодиагностика: двенадцать контрольных вопросов
- Какие каналы внешнего текста приходят в контекст каждой модели вашего парка?
- Отличается ли обработка пользовательского ввода от обработки загруженных документов?
- Проходят ли файлы санитизацию скрытых слоёв и невидимых символов?
- Содержит ли системный промпт секреты, имена систем, персональные данные?
- Есть ли в сервисе инструменты с необратимыми действиями и что мешает их вызову через инъекцию?
- Требуется ли подтверждение человеком для операций за пределами чтения?
- Фильтруется ли вывод на предмет служебной информации перед показом пользователю?
- Журналируются ли запросы, действия и ответы достаточно полно для разбора инцидента?
- Знает ли дежурная смена, как выглядит атака в логах и что отключать первым?
- Прогонялся ли сервис на корпусе инъекций после последнего изменения конвейера?
- Пересматривается ли список источников при расширении интеграций?
- Есть ли владелец процесса, отвечающий за всё перечисленное целиком?
Отрицательные ответы размечают фронт работ: вопросы 1–4 про уменьшение площади, 5–7 про цену компрометации, 8–9 про обнаружение, 10–12 про устойчивость процесса.
Приоритетные контрмеры
| Приоритет | Мера | Что даёт |
|---|---|---|
| 1 | Минимальные права инструментов, подтверждение человеком необратимого | обнуляет тяжёлые последствия |
| 2 | Вынос секретов и чувствительных данных из промптов и контекста | снижает цену раскрытия |
| 3 | Разметка и изоляция внешних блоков данных | сокращает долю срабатываний |
| 4 | Санитизация документов и страниц на входе | убирает массовые закладки |
| 5 | Выходной контроль служебной информации | закрывает эвакуацию контекста |
| 6 | Журналирование и алерты | превращает атаку в обнаруживаемую |
| 7 | Регулярные прогоны корпуса атак | держит защиту актуальной |
Порядок не случаен: верхние строки не требуют разработки и дают наибольший эффект, нижние — инженерная надстройка, которая имеет смысл поверх уже закрытой базы.
Чек-лист приёмки нового сценария с моделью
Перед запуском любого нового ИИ-сценария в продакшен полезно формально ответить на четыре вопроса. Что модель читает — перечислить каналы и источники. Что модель может — перечень действий с правами. Что случится при компрометации — худший разумный сценарий ущерба. Как это заметят — индикаторы в журналах. Ответы фиксируются рядом с описанием сценария и пересматриваются при изменениях. Такая карточка весит страницу, но именно она отличает управляемый ИИ-контур от коллекции экспериментов.
Развитие во времени
Работа по LLM01 не заканчивается первым закрытием находок. Жизненный цикл защиты включает три постоянных процесса. Мониторинг деградации: доля успешных атак растёт незаметно после, казалось бы, безобидных изменений — добавленного сценария, нового источника данных, смены поставщика модели; регулярные прогоны корпуса ловят этот дрейф. Обучение людей: разработчики, знающие механику инъекций, проектируют конвейеры иначе; пользователи, понимающие, почему нельзя вставлять в ассистент внешние тексты без нужды, реже становятся переносчиками; короткие разборы реальных находок работают лучше общих курсов. Эскалация инцидентов: при обнаружении успешной атаки в продакшене действует заранее описанный порядок — сохранение следов, локализация, оценка утечки, уведомления; для утечек персональных данных внешние сроки заданы законом, и внутренний регламент обязан в них укладываться.
Компании, встроившие эти три процесса, говорят об LLM01 языком метрик и графиков; остальные — языком надежд. Разница видна в первом же серьёзном инциденте.