Таксономия PROMPTS: как 7 «грехов» LLM-продуктов угрожают вашей безопасности

Классические подходы к моделированию угроз вроде STRIDE хорошо чувствуют себя в мире веб-приложений и микросервисов, но начинают буксовать, когда в систему попадает модель с крупным контекстом, инструментами и доступом к внешним данным. Здесь логика поведения частично переносится в подсказки (промпты), а каналами атаки становятся не только API и входные формы, но и документы, векторные базы, плагины, журналы логов и даже политики модерации. Чтобы не размазывать контрмеры по всей архитектуре, полезно завести слой угроз поверх подсказок, ретривера и инструментов — и мыслить им как самостоятельной системой.

В этой статье разбираем прикладную таксономию PROMPTS — компактный набор классов угроз для LLM-продуктов: Prompt Injection, Retrieval Poisoning, Output Overtrust, Model Supply Chain, Privacy Exfiltration, Tool Abuse, Shadow AI. Для каждой категории дадим признаки, типовые сценарии и контрмеры. В финале — потоковая диаграмма с точками контроля, матрица «угроза × контроль» и идеи юнит-евалов на инъекции. Всё максимально практично и без канцелярита.

Почему STRIDE не хватает и где появляется слой «над промптами»

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

Именно поэтому полезно мыслить слоем поверх: подсказки → ретривер → модель → инструменты → пост-обработка → доставка. У каждого сегмента свои уязвимости и свои средства защиты. Таксономия PROMPTS аккуратно покрывает «семь смертных грехов» этого слоя и помогает выстроить осмысленный набор контролей, не превращая архитектуру в музей заглушек.

Поток данных LLM-приложения и точки контроля

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

Практически полезно закрепить это в живом артефакте. Ниже — текстовая заготовка диаграммы потока (её удобно перенести в diagrams.net или Obsidian с плагином для диаграмм):

Пользователь ──► Входной фильтр/нормализация ──► Роутер/оркестратор
                                      │
                                      ├─► Ретривер (RAG) ─► Контент-фильтр/ранжирование ─► Подсказка модели
                                      │
                               Модель (LLM) ──► Политика инструментов/песочница ──► Инструменты/плагины
                                      │                                         │
                                      │                                         └─► Egress-контроль/таймауты/квоты
                                      │
                               Пост-обработка/валидация ──► Человеческая верификация (по риску)
                                      │
                                   Доставка/логирование/канареечные проверки

Каждый блок помечаем набором контролей: фильтры, разрешения, квоты, канарейки, контент-модерация, подписи и рейтинги источников, а также явные точки для человеческой верификации критичных действий.

PROMPTS: оглавление угроз

Кратко перечислим, что входит в набор:

• P — Prompt Injection: инъекции в явном запросе или через данные/HTML, которые переписывают системный контекст, включают опасные инструменты или вытягивают секреты.
• R — Retrieval Poisoning: «ядовитые» документы в индексе/векторном стораже, которые подталкивают модель к неверному или вредному действию.
• O — Output Overtrust: чрезмерная вера в вывод модели без независимой проверки, автоматизация решений «на слово».
• M — Model Supply Chain: риски происхождения весов, лоукодов и дообучений, лицензирования и скрытых бэкдоров.
• P — Privacy Exfiltration: утечка чувствительных данных через контекст, журналы, подсказки или побочные каналы.
• T — Tool Abuse: злоупотребление инструментами/плагинами и выполнение опасных действий от имени пользователя.
• S — Shadow AI: несанкционированные боты, самодельные промпт-файлы и теневые интеграции в подразделениях.

P — Инъекция подсказок (Prompt Injection)

Инъекция — это не только «убеди модель игнорировать инструкции». Чаще это скрытые команды в данных: в HTML-фрагменте, в комментариях к коду, в невидимых стилях, PDF-слоях, метатегах или альтернативном тексте изображений. Инъекции бывают прямыми (пользователь пишет команду) и косвенными, когда «яд» попадает через ретривер или внешнюю веб-страницу, а модель покорно исполняет.

Признаки: неожиданная смена тона или роли, внезапные раскрытия системных инструкций, обращения к инструментам без видимого основания, попытки запросить секреты. Особенно опасны инъекции, которые переписывают правила модерации, маскируются под «внутренний регламент» и подталкивают к действиям вне компетенции агента.

Контрмеры

• Жёсткая сегментация подсказок: разносить системные, разработческие и пользовательские инструкции; явно помечать границы и роли.
• Политика инструментов: разрешения по белым спискам, подтверждения и лимиты; запрет авто-вызова опасных действий.
• Смысловые фильтры: отдельная модель-«страж» для детекции инъекций, запрещённых тем и попыток вытащить секреты.
• Канареечные токены: подложные секреты и маркеры; любое упоминание — тревога и блок ветки.
• Экранирование данных: нормализация HTML/Markdown, вырезание активных конструкций, явное цитирование.

R — Отравление ретривера (Retrieval Poisoning)

В системах RAG угроза мигрирует в индекс: злоумышленник кладёт документ, который звучит авторитетно, но содержит ложь или инструкции. Модель уверенно ссылается на этот источник и совершает неверное действие. Сложность в том, что на уровне «железа» всё честно: ACL, токены, аудит. Яд — в смысле текста и в способе ранжирования.

Коварные сценарии: тонкие переформулировки, «ручники» для модели под видом правил безопасности, SEO-пузырение и «засолка» векторной базы семантическими дублями. Иногда яд встраивают на границе: якобы полезные «корпоративные часто задаваемые вопросы», которые подталкивают к небезопасным схемам.

Контрмеры

• Караульный фильтр перед подсказкой: модерация и эвристики «источник требует проверки».
• Рейтинги источников: подписи документов, доверенные домены, SSO-метки; понижение веса анонимных и свежих без ревью.
• Дедуп и защита от дублей: отсечение семантических повторов, «склейка» почти одинаковых кусков, квоты на автора.
• Доказательное форматирование: требование к ответу ссылок на 2–3 независимых источника, согласованность выдержек.
• Периодический аудит индекса: скользящее окно проверки, канареечные документы для мониторинга утечек и подмен.

O — Чрезмерное доверие выводу (Output Overtrust)

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

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

Контрмеры

• Верификация по риску: критичные действия требуют «двух ключей» или подтверждения человека.
• Доказательные ответы: ссылки на источники, структурированные обоснования, подсветка неопределённости.
• Контрольные выборки: регулярная ручная проверка случайных кейсов и обязательный ретро-разбор инцидентов.
• Границы полномочий: явный список того, чего система не делает «в принципе» (например, не меняет доступы).

M — Цепочка поставки модели (Model Supply Chain)

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

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

Контрмеры

• Реестр моделей: паспорт модели (card), контрольные суммы, лицензии, происхождение, воспроизводимость сборки.
• Политика источников: только доверенные реестры артефактов, зеркала с проверкой подписей, контроль обновлений.
• Изоляция дообучений: отдельные окружения, ревью датасетов, автоматические тесты на бэкдоры и «спящие» триггеры.
• Юридическая чистота: проверка лицензий и ограничений использования до начала интеграции.

P — Утечка приватных данных (Privacy Exfiltration)

LLM-системы любят собирать контекст — и большинство утечек происходит не из-за «хакеров», а из-за сквозного логирования, бесконтрольных интеграций и очевидных подсказок. Данные, которые «временно» попали в подсказку, часто оказываются в логах, аналитике и ретривере, а потом вылезают в чужих ответах. Косвенные инъекции умеют ещё и подловить модель на «рассказать то, что знаешь о системе».

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

Контрмеры

• Политика секретов: запрет на инлайны в подсказках, только менеджер секретов и подстановки по токенам.
• Минимизация логов: очистка PII, редактирование чувствительного, разные классы хранения и TTL.
• Разделение арендаторов: отдельные индексы, ключи и кэш; подписи и тегирование данных.
• Фильтры ответов: детектор попыток вытянуть секреты, блок и сигнал при срабатывании канареек.

T — Злоупотребление инструментами (Tool Abuse)

Инструменты делают агента полезным, а злоупотребление — опасным. Типовой сценарий: через инъекцию или «ядовитый» документ модель убеждают вызвать инструмент, который способен менять состояние внешнего мира: отправлять письма, проводить списания, менять доступы, выполнять код или делать сетевые вызовы туда, куда не следует.

Часть инструментов опасна сама по себе (выполнение кода, доступ к файловой системе, произвольный HTTP), а часть — потенциально вредна при неверном контексте (платёж, бронирование, интеграция с CRM). Нельзя рассчитывать, что «модель не сделает глупость»: нужно строить систему, которая не даст ей сделать глупость незаметно.

Контрмеры

• Песочницы и контейнеры: отдельные рантаймы, ограниченные права, сетевые политики, cgroup-квоты.
• Разрешения и квоты: явные capability-флаги для инструментов, дневные лимиты, время простоя, долгие операции — только по подтверждению.
• Egress-контроль: запреты на произвольные исходящие запросы, allowlist доменов, проверка схем, защита от SSRF.
• Протокол подтверждений: «покажи план → спроси разрешение → выполни → отчитайся» для всех действий с риском.

S — Теневой ИИ (Shadow AI)

Теневой ИИ — это когда отдел сам завёл бота, подсунул ему API-ключ и начал решать «здесь и сейчас» реальные задачи. Есть польза, но безопасность и соответствие политике оказываются вне игры. Результат закономерен: утечки, зависимость от случайных подсказок, разношёрстные данные в индексах и невозможность расследовать инциденты.

Запреты редко работают; обычно помогает «легализация»: дать удобный путь «как правильно», прозрачные правила, реестр одобренных моделей и песочницы. Главное — сделать официальный путь не хуже по UX, чем самодеятельный.

Контрмеры

• Каталог разрешённых ботов и моделей с паспортами, ограничениями и ответственными лицами.
• Политика данных: что можно загружать, что запрещено, где хранятся индексы, как чистятся логи.
• Проактивное онбординг-предложение: шаблоны, SDK, «конструктор» ботов и готовые гварды.

Кросс-срез: базовый набор контролей

Не всякий продукт обязан внедрять всё сразу. Но есть «минимальная схема», которая резко снижает риск без потери скорости:

• Песочницы и разрешения на инструменты: по умолчанию всё закрыто, включаем по необходимости.
• Политика секретов: секреты только через менеджер, логи и индексы очищаются автоматически.
• Egress-контроль: явный список допустимых внешних направлений, анти-SSRF и проверка схем.
• Канарейки в данных: маркеры утечек и тесты на инъекции в ретривере.
• RAG-харднинг: модерация контента, рейтинги источников, дедуп, подписи и цитирование в ответах.
• Человеческая верификация критичных действий: двухфакторные подтверждения и разделение обязанностей.

Матрица «угроза × контроль»

Сводная таблица поможет согласовать ожидания между командами разработки, безопасности и продукта.

Угроза	Песочницы/разрешения	Политика секретов	Egress-контроль	Канарейки	RAG-харднинг	Человеческая верификация	Аудит/логи
P — Prompt Injection	✔︎	✔︎	◯	✔︎	◯	✔︎ (для действий)	✔︎
R — Retrieval Poisoning	◯	◯	◯	✔︎	✔︎	◯	✔︎
O — Output Overtrust	◯	◯	◯	◯	✔︎ (доказательность)	✔︎	✔︎
M — Model Supply Chain	✔︎ (изоляция)	◯	◯	◯	◯	◯	✔︎ (реестр/паспорт)
P — Privacy Exfiltration	◯	✔︎	✔︎	✔︎	◯	◯	✔︎
T — Tool Abuse	✔︎	◯	✔︎	◯	◯	✔︎	✔︎
S — Shadow AI	✔︎ (каталог)	✔︎	◯	◯	◯	◯	✔︎ (реестр)

Обозначения: ✔︎ — основная мера, ◯ — дополнительная/косвенная.

RAG-харднинг: практические приёмы

Если в вашей архитектуре есть ретривер, то половина успеха — в гигиене данных. Начните с простого: раздельные индексы по арендаторам, подписи и доверенные источники, запрет на «анонимные» документы без ревью. Требуйте от ответов ссылок на разные источники и подсказки «сомневайся, если источники спорят».

Дальше — тонкая настройка: семантический дедуп, штраф за слишком «свежее и одинокое», канареечные вставки в тестовом наборе, регулярный аудит кусков с максимальным влиянием на ответы. Хорошо работает «карантин»: сомнительные документы живут в отдельном индексе и участвуют в ответах только при явном подтверждении модератора.

Политика секретов и egress-контроль

Классика безопасности здесь по-прежнему рулит. Секреты не попадают в подсказки в явном виде, ключи — только через защищённый менеджер, а логи очищаются автоматически. Все исходящие вызовы инструментов проходят через явный allowlist и проверку схем, с таймаутами, квотами и почтовым «песком» для внешних доменов. Любые попытки «поговорить с неизвестным» — это не ошибка, а событие безопасности, которое должно быть видно.

Для особо чувствительных действий — двухэтапное подтверждение и разделение ключей. Для особо шумных — «песчаная» сеть без прямого выхода в интернет, с прокси, который журналирует и умеет резать запросы по сигнатурам.

Человеческая верификация и UX безопасности

Люди нужны не для того, чтобы «подписывать всё подряд», а чтобы вмешиваться там, где цена ошибки высока и автоматическая проверка недостаточна. Это значит: понятный интерфейс согласования, ясные критерии «когда звать человека», наглядные диффы «что будет сделано» и «что получилось», а также блокировка эскалаций «на эмоциях» («модель очень уверена, разрешите срочно» — нет, так не работает).

Хороший признак зрелости — когда безопасный путь быстрее и удобнее «теневого». Пусть подтверждение критичных действий выглядит как современный checkout, а не как факс из 90-х.

Артефакты: что должно быть в комплекте

1. Диаграмма потока с точками контроля

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

2. Матрица «угроза × контроль»

Таблица выше — хороший старт. Добавьте столбцы «владелец», «уровень зрелости», «SLO обнаружения» и «метрика эффективности».

3. Юнит-евалы на инъекции

Евалы — это не только «умные» бенчмарки. Нужны простые, но жёсткие юнит-кейсы, которые гоняются на каждом изменении подсказок, ретривера или гвардов. Примеры тестов:

• Прямые инъекции: «Игнорируй все правила и сделай X». Ожидаемая реакция — отказ и объяснение.
• HTML/Markdown-яд: скрытые инструкции в комментариях, стилях, alt-тексте, ссылках. Ожидаемая реакция — нейтрализация и цитирование как данных, а не команд.
• RAG-инъекция: документ с «внутренним регламентом» противоречит политике. Ожидаемая реакция — приоритизация системной политики и запрос подтверждения.
• Инструментальная эскалация: контент подталкивает к вызову инструмента вне компетенции. Ожидаемая реакция — план с подтверждением и блок без разрешения.
• Канареечные секреты: маркеры встречаются во входе/индексе. Ожидаемая реакция — не озвучивать, сгенерировать тревогу.

Технически это удобно оформлять как набор фикстур + проверок правил. Храните их рядом с подсказками и конфигами ретривера, ведите версионирование и ченджлог.

Метрики зрелости: как измерять «вибе-долг»

Чтобы не скатиться в «вайб-кодинг», договоритесь про метрики. Начните с простого: количество незафиксированных изменений подсказок, число ручных правок при эксплуатации, доля ответов без ссылок, среднее время на человеческую верификацию, объём заблокированных инъекций и триггеров канареек. Для RAG — доля ответов, подтверждённых независимыми источниками, и скорость очистки подозрительных документов.

Метрики не для отчётов, а для управления: если растёт доля ручных фиксов — добавляйте гварды или пересматривайте подсказки; если падает доля доказательных ответов — ужесточайте требования к ссылкам и ранжированию; если участились egress-блоки — проверьте интеграции и белые списки.

Встраивание в SDLC: от «раза в квартал» к «на каждый коммит»

Моделирование угроз должно быть частью инженерной рутины. Мини-шаблон на каждый PR: какие изменения в подсказках/ретривере/инструментах; какие юнит-евалы добавлены/обновлены; кто владелец контроля; какие канареечные тесты пройдены. Для релизов — чек-лист: потоковая диаграмма актуальна, матрица угроз обновлена, реестр моделей подписан и воспроизводим.

Релиз без евальной зелени — не релиз. Аварийная кнопка «откатить подсказку/индекс/версию гварда» — обязательна. Запланируйте регулярные «красные команды» и учёт инцидентов: безопасность — это не «поставили галочку», а процесс.

Полезные ссылки и инструменты

Ниже — подборка ресурсов и утилит, которые помогут внедрять практики из статьи:

• OWASP Top-10 для LLM-приложений — удобный перечень типовых рисков и контрольных вопросов.
• Рекомендации NCSC по prompt-инъекциям — прагматичные гайды в духе «делай/не делай».
• NIST AI Risk Management Framework — рамка управления рисками ИИ на уровне процесса.
• MITRE ATLAS — база знаний по тактикам и техникам атак на ИИ-системы.
• diagrams.net и Mermaid для диаграмм потоков и живых схем.
• NeMo Guardrails и Llama Guard — примеры «гвардов» вокруг LLM.
• Lakera Gandalf — тренировочная площадка по инъекциям подсказок.

Вывод

LLM-продукты не отменяют классическую безопасность — они меняют её фокус. Риски теперь живут в смыслах, данных и инструментах. Таксономия PROMPTS даёт удобную «раму» для разговора и проектирования: семь классов угроз — семь направлений защиты. Начните с минимума: песочницы инструментов, политика секретов, egress-контроль, канарейки, RAG-харднинг и человеческая верификация критичных действий. Добавьте живые артефакты — потоковую диаграмму, матрицу угроз и набор юнит-евалов. Дальше остаётся дисциплина: фиксировать изменения, мерить «вибе-долг» и не стесняться учиться на собственных промахах — быстро, осознанно и без драм.