# OWASP Top 10 для LLM-приложений 2025 на русском

> Перевод OWASP Top 10 for LLM Applications 2025 (OWASP GenAI Security Project), лицензия CC BY-SA 4.0. Перевод неофициальный.

- Канонический HTML: [/owasp-llm-top-10](https://ai-first.tech/owasp-llm-top-10)
- Язык: русский
- Редакционный принцип: защитный контекст без вредоносных полезных нагрузок и инструкций обхода.

## LLM01 Внедрение инструкций (Prompt Injection)

Уязвимость внедрения инструкций (prompt injection) возникает, когда пользовательские запросы (промпты) изменяют поведение или выходные данные LLM непредусмотренным образом. Такие входные данные могут воздействовать на модель, даже если они незаметны для человека: внедренные инструкции не обязаны быть видимыми или читаемыми для человека — достаточно, чтобы содержимое обрабатывалось моделью.

Уязвимости внедрения инструкций кроются в том, как модели обрабатывают запросы и как входные данные могут вынудить модель некорректно передавать данные запроса в другие части модели. Это может приводить к нарушению установленных правил, генерации вредоносного контента, несанкционированному доступу или влиянию на критически важные решения. Хотя такие методы, как генерация с дополненной выборкой (Retrieval Augmented Generation, RAG) и дообучение (fine-tuning), призваны сделать ответы LLM более релевантными и точными, исследования показывают, что они не устраняют уязвимости внедрения инструкций полностью.

Внедрение инструкций и джейлбрейк (jailbreaking) — родственные понятия в безопасности LLM, и их часто употребляют как синонимы. Внедрение инструкций — это манипулирование ответами модели с помощью специально подобранных входных данных с целью изменить ее поведение, что может включать обход защитных механизмов. Джейлбрейк — разновидность внедрения инструкций, при которой атакующий подает входные данные, заставляющие модель полностью игнорировать свои протоколы безопасности. Разработчики могут встраивать защитные меры в системные инструкции (system prompts) и в обработку входных данных, чтобы снизить риск атак внедрения, однако эффективное предотвращение джейлбрейка требует постоянного обновления обучения модели и ее механизмов безопасности.

Тяжесть и характер последствий успешной атаки внедрения инструкций могут сильно различаться и во многом зависят как от бизнес-контекста, в котором работает модель, так и от степени автономности (agency), заложенной в архитектуру модели. В целом внедрение инструкций может приводить к непредусмотренным последствиям, включая, помимо прочего: раскрытие конфиденциальной информации; раскрытие конфиденциальных сведений об инфраструктуре AI-системы или о системных инструкциях; манипулирование контентом, ведущее к неверным или предвзятым результатам; предоставление несанкционированного доступа к функциям, доступным LLM; выполнение произвольных команд в подключенных системах; манипулирование критически важными процессами принятия решений.

Развитие мультимодального AI, одновременно обрабатывающего данные нескольких типов, порождает особые риски внедрения инструкций. Злоумышленники могут использовать взаимодействие между модальностями, например скрывать инструкции в изображениях, сопровождающих безобидный текст. Сложность таких систем расширяет поверхность атаки. Мультимодальные модели также могут быть подвержены новым межмодальным атакам, которые сложно обнаруживать и нейтрализовать современными методами. Надежные средства защиты, учитывающие специфику мультимодальности, — важное направление дальнейших исследований и разработок.

### Типовые примеры

- Раскрытие конфиденциальной информации.
- Раскрытие конфиденциальных сведений об инфраструктуре AI-системы или о системных инструкциях.
- Манипулирование контентом, ведущее к неверным или предвзятым результатам.
- Предоставление несанкционированного доступа к функциям, доступным LLM.
- Выполнение произвольных команд в подключенных системах.
- Манипулирование критически важными процессами принятия решений.

### Меры предотвращения

- Уязвимости внедрения инструкций возможны из-за самой природы генеративного AI. С учетом стохастического характера, лежащего в основе работы моделей, неясно, существуют ли абсолютно надежные методы предотвращения внедрения инструкций. Тем не менее следующие меры позволяют снизить последствия таких атак.
- 1. Ограничение поведения модели. Задайте в системных инструкциях конкретные указания о роли модели, ее возможностях и ограничениях. Обеспечьте строгое следование контексту, ограничьте ответы конкретными задачами или темами и предпишите модели игнорировать попытки изменить базовые инструкции.
- 2. Определение и проверка ожидаемых форматов вывода. Задайте четкие форматы выходных данных, запрашивайте подробное обоснование и ссылки на источники, используйте детерминированный код для проверки соответствия этим форматам.
- 3. Фильтрация входных и выходных данных. Определите категории конфиденциальной информации и сформулируйте правила для выявления и обработки такого контента. Применяйте семантические фильтры и проверку строк для поиска недопустимого содержимого. Оценивайте ответы с помощью «триады RAG» (RAG Triad): релевантность контекста, обоснованность (groundedness) и релевантность пары «вопрос — ответ», чтобы выявлять потенциально вредоносные выходные данные.
- 4. Контроль привилегий и принцип минимальных привилегий. Предоставьте приложению собственные API-токены для расширяемой функциональности и обрабатывайте эти функции в коде, а не передавайте их модели. Ограничьте права доступа модели минимумом, необходимым для ее штатной работы.
- 5. Обязательное одобрение человеком действий с высоким риском. Внедрите контроль с участием человека (human-in-the-loop) для привилегированных операций, чтобы предотвратить несанкционированные действия.
- 6. Изоляция и маркировка внешнего контента. Отделяйте недоверенный контент и явно помечайте его, чтобы ограничить его влияние на пользовательские запросы.
- 7. Состязательное тестирование и моделирование атак. Регулярно проводите тестирование на проникновение и моделирование взломов, рассматривая модель как недоверенного пользователя, чтобы проверить эффективность границ доверия и механизмов контроля доступа.

### Сценарии атак

- Сценарий 1. Прямое внедрение. Атакующий внедряет инструкцию в чат-бот службы поддержки, предписывая ему игнорировать прежние правила, запросить данные из закрытых хранилищ и отправить электронные письма, что приводит к несанкционированному доступу и повышению привилегий.
- Сценарий 2. Косвенное внедрение. Пользователь с помощью LLM составляет краткое изложение веб-страницы, содержащей скрытые инструкции; они заставляют LLM вставить изображение со ссылкой на URL, что приводит к утечке (эксфильтрации) приватной переписки.
- Сценарий 3. Непреднамеренное внедрение. Компания включает в описание вакансии инструкцию для выявления откликов, сгенерированных AI. Соискатель, не зная об этой инструкции, использует LLM для улучшения резюме и непреднамеренно срабатывает механизм обнаружения AI.
- Сценарий 4. Намеренное влияние на модель. Атакующий изменяет документ в хранилище, используемом приложением с генерацией с дополненной выборкой (RAG). Когда запрос пользователя возвращает измененный контент, вредоносные инструкции искажают вывод LLM, порождая вводящие в заблуждение результаты.
- Сценарий 5. Внедрение кода. Атакующий эксплуатирует уязвимость (CVE-2024-5184) в почтовом помощнике на базе LLM, чтобы внедрить вредоносные инструкции, что позволяет получить доступ к конфиденциальной информации и манипулировать содержимым писем.
- Сценарий 6. Разделение полезной нагрузки (Payload Splitting). Атакующий загружает резюме с вредоносными инструкциями, разбитыми на части. Когда LLM используется для оценки кандидата, объединенные инструкции манипулируют ответом модели, и она дает положительную рекомендацию вопреки фактическому содержанию резюме.
- Сценарий 7. Мультимодальное внедрение. Атакующий встраивает вредоносную инструкцию в изображение, сопровождающее безобидный текст. Когда мультимодальная AI-система одновременно обрабатывает изображение и текст, скрытая инструкция изменяет поведение модели, что может привести к несанкционированным действиям или раскрытию конфиденциальной информации.
- Сценарий 8. Состязательный суффикс (Adversarial Suffix). Атакующий добавляет к запросу на первый взгляд бессмысленную строку символов, которая вредоносным образом влияет на вывод LLM и позволяет обойти защитные механизмы.
- Сценарий 9. Многоязычная или обфусцированная атака. Атакующий использует несколько языков или кодирует вредоносные инструкции (например, с помощью Base64 или эмодзи), чтобы обойти фильтры и манипулировать поведением LLM.

## LLM02 Раскрытие конфиденциальной информации (Sensitive Information Disclosure)

Конфиденциальная информация может затрагивать как саму LLM, так и контекст ее применения. К ней относятся персональные данные (personal identifiable information, PII), финансовые сведения, медицинские записи, конфиденциальные бизнес-данные, учетные данные для доступа и юридические документы. Проприетарные модели также могут обладать уникальными методами обучения и исходным кодом, которые считаются конфиденциальными, — особенно это касается закрытых и базовых (foundation) моделей.

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

Чтобы снизить этот риск, приложения на базе LLM должны выполнять надлежащую очистку данных (data sanitization), не допуская попадания пользовательских данных в обучаемую модель. Владельцам приложений также следует публиковать понятные условия использования (Terms of Use), позволяющие пользователям отказаться от включения своих данных в обучение модели. Ограничения в системных инструкциях на типы данных, которые может возвращать LLM, способны снизить риск раскрытия конфиденциальной информации. Однако такие ограничения соблюдаются не всегда и могут быть обойдены с помощью внедрения инструкций (prompt injection) или иными методами.

### Типовые примеры

- 1. Утечка персональных данных (PII Leakage). Персональные данные (PII) могут быть раскрыты в ходе взаимодействия с LLM.
- 2. Раскрытие проприетарных алгоритмов (Proprietary Algorithm Exposure). Неправильно настроенный вывод модели может раскрыть проприетарные алгоритмы или данные. Раскрытие обучающих данных может сделать модель уязвимой для атак инверсии (inversion attacks), при которых злоумышленники извлекают конфиденциальную информацию или восстанавливают входные данные. Например, как было продемонстрировано в атаке Proof Pudding (CVE-2019-20634), раскрытые обучающие данные облегчили извлечение и инверсию модели, что позволило атакующим обойти механизмы защиты в алгоритмах машинного обучения и обойти почтовые фильтры.
- 3. Раскрытие конфиденциальных бизнес-данных (Sensitive Business Data Disclosure). Сгенерированные ответы могут непреднамеренно содержать конфиденциальную деловую информацию.

### Меры предотвращения

- Очистка данных — 1. Внедрение методов очистки данных. Применяйте очистку данных, чтобы не допустить попадания пользовательских данных в обучаемую модель. Это включает удаление или маскирование конфиденциального содержимого до его использования в обучении.
- Очистка данных — 2. Строгая проверка входных данных. Применяйте строгие методы проверки входных данных, чтобы обнаруживать и отфильтровывать потенциально вредоносные или конфиденциальные входные данные и не допускать компрометации модели.
- Контроль доступа — 1. Строгий контроль доступа. Ограничивайте доступ к конфиденциальным данным по принципу минимальных привилегий. Предоставляйте доступ только к тем данным, которые необходимы конкретному пользователю или процессу.
- Контроль доступа — 2. Ограничение источников данных. Ограничьте доступ модели к внешним источникам данных и обеспечьте безопасное управление оркестрацией данных во время выполнения, чтобы избежать непреднамеренной утечки.
- Федеративное обучение и методы защиты приватности — 1. Применение федеративного обучения (federated learning). Обучайте модели на децентрализованных данных, хранящихся на нескольких серверах или устройствах. Такой подход сводит к минимуму необходимость централизованного сбора данных и снижает риски их раскрытия.
- Федеративное обучение и методы защиты приватности — 2. Применение дифференциальной приватности (differential privacy). Используйте методы, добавляющие шум к данным или выходным данным, что затрудняет восстановление злоумышленниками отдельных записей.
- Обучение пользователей и прозрачность — 1. Обучение пользователей безопасной работе с LLM. Предоставляйте рекомендации о том, как избегать ввода конфиденциальной информации. Проводите обучение лучшим практикам безопасного взаимодействия с LLM.
- Обучение пользователей и прозрачность — 2. Прозрачность использования данных. Поддерживайте четкие политики хранения, использования и удаления данных. Дайте пользователям возможность отказаться от включения их данных в процессы обучения.
- Безопасная конфигурация системы — 1. Сокрытие системной преамбулы. Ограничьте возможность пользователей переопределять исходные настройки системы или получать к ним доступ, снижая риск раскрытия внутренней конфигурации.
- Безопасная конфигурация системы — 2. Следование лучшим практикам по предотвращению ошибок конфигурации. Следуйте рекомендациям, например OWASP API8:2023 Security Misconfiguration, чтобы предотвратить утечку конфиденциальной информации через сообщения об ошибках или сведения о конфигурации (см.: OWASP API8:2023 Security Misconfiguration, https://owasp.org/API-Security/editions/2023/en/0xa8-security-misconfiguration/).
- Продвинутые методы — 1. Гомоморфное шифрование (homomorphic encryption). Используйте гомоморфное шифрование для безопасного анализа данных и машинного обучения с сохранением приватности. Это обеспечивает конфиденциальность данных во время их обработки моделью.
- Продвинутые методы — 2. Токенизация и редактирование (tokenization and redaction). Применяйте токенизацию для предварительной обработки и очистки конфиденциальной информации. Такие методы, как сопоставление с шаблонами (pattern matching), позволяют обнаруживать и удалять конфиденциальное содержимое до обработки.

### Сценарии атак

- Сценарий 1. Непреднамеренное раскрытие данных. Пользователь получает ответ, содержащий персональные данные другого пользователя, из-за недостаточной очистки данных.
- Сценарий 2. Целенаправленное внедрение инструкций. Атакующий обходит входные фильтры, чтобы извлечь конфиденциальную информацию.
- Сценарий 3. Утечка через обучающие данные. Неосмотрительное включение данных в обучающую выборку приводит к раскрытию конфиденциальной информации.

## LLM03 Цепочка поставок (Supply Chain)

Цепочки поставок LLM подвержены разнообразным уязвимостям, способным нарушить целостность обучающих данных, моделей и платформ развертывания. Эти риски могут приводить к предвзятым результатам, нарушениям безопасности или отказам систем. Если традиционные уязвимости ПО связаны прежде всего с дефектами кода и зависимостями, то в машинном обучении риски распространяются также на сторонние предобученные модели и данные.

Эти внешние компоненты могут быть изменены злоумышленниками с помощью атак модификации (tampering) или отравления (poisoning).

Создание LLM — специализированная задача, которая часто опирается на сторонние модели. Распространение LLM с открытым доступом и новых методов дообучения, таких как LoRA (Low-Rank Adaptation, низкоранговая адаптация) и PEFT (Parameter-Efficient Fine-Tuning, параметрически эффективное дообучение), особенно на платформах вроде Hugging Face, порождает новые риски цепочки поставок. Наконец, появление LLM, работающих на устройствах (on-device LLM), расширяет поверхность атаки и риски цепочки поставок для приложений на базе LLM.

Часть рассматриваемых здесь рисков обсуждается также в разделе LLM04 «Отравление данных и модели» (Data and Model Poisoning). Данный раздел посвящен аспектам цепочки поставок. Простая модель угроз доступна по ссылке: https://github.com/jsotiro/ThreatModels/blob/main/LLM%20Threats-LLM%20Supply%20Chain.png.

### Типовые примеры

- 1. Уязвимости традиционных сторонних пакетов. Например, устаревшие или выведенные из поддержки компоненты, которые злоумышленники могут эксплуатировать для компрометации LLM-приложений. Это аналогично категории A06:2021 – Vulnerable and Outdated Components (уязвимые и устаревшие компоненты), но с повышенными рисками, когда компоненты используются при разработке или дообучении модели (см.: A06:2021 – Vulnerable and Outdated Components, https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/).
- 2. Лицензионные риски. Разработка AI часто связана с множеством лицензий на ПО и наборы данных, что создает риски при ненадлежащем управлении ими. Различные открытые и проприетарные лицензии налагают разные юридические требования. Лицензии на наборы данных могут ограничивать их использование, распространение или коммерциализацию.
- 3. Устаревшие или выведенные из поддержки модели. Использование устаревших или выведенных из поддержки моделей, которые больше не сопровождаются, приводит к проблемам безопасности.
- 4. Уязвимая предобученная модель. Модели представляют собой двоичные «черные ящики», и, в отличие от открытого кода, статический анализ дает мало или вовсе не дает гарантий безопасности. Уязвимые предобученные модели могут содержать скрытые искажения (biases), бэкдоры или иные вредоносные функции, не выявленные в ходе проверок безопасности в репозиториях моделей. Уязвимые модели могут быть созданы как с помощью отравленных наборов данных, так и путем прямой модификации модели с использованием таких методов, как ROME, известного также как «лоботомизация» (lobotomisation).
- 5. Слабое подтверждение происхождения модели (provenance). В настоящее время для опубликованных моделей отсутствуют надежные гарантии происхождения. Карточки моделей (Model Cards) и сопутствующая документация содержат сведения о модели, и пользователи на них полагаются, однако они не дают гарантий относительно происхождения модели. Злоумышленник может скомпрометировать учетную запись поставщика в репозитории моделей или создать похожую и в сочетании с методами социальной инженерии скомпрометировать цепочку поставок LLM-приложения.
- 6. Уязвимые LoRA-адаптеры. LoRA — популярный метод дообучения, повышающий модульность за счет возможности подключать предобученные слои к существующей LLM. Метод повышает эффективность, но создает новые риски: вредоносный LoRA-адаптер может нарушить целостность и безопасность предобученной базовой модели. Это может происходить как в средах совместного слияния моделей (model merge), так и через эксплуатацию поддержки LoRA в популярных платформах развертывания инференса, таких как vLLM и OpenLLM, где адаптеры можно загружать и применять к уже развернутой модели.
- 7. Эксплуатация процессов совместной разработки. Сервисы совместного слияния моделей и обработки моделей (например, конвертации), размещенные в общих средах, могут быть использованы для внедрения уязвимостей в общие модели. Слияние моделей очень популярно на Hugging Face — модели, полученные слиянием, возглавляют рейтинг OpenLLM leaderboard, — и этим можно воспользоваться для обхода проверок. Аналогичным образом было доказано, что такие сервисы, как бот конвертации, уязвимы для манипуляций и могут внедрять в модели вредоносный код.
- 8. Уязвимости цепочки поставок LLM на устройствах. LLM на устройствах расширяют поверхность атаки на цепочку поставок за счет скомпрометированных производственных процессов и эксплуатации уязвимостей ОС или прошивки устройства для компрометации моделей. Злоумышленники могут провести обратную разработку (reverse engineering) приложений и переупаковать их с модифицированными моделями.
- 9. Неясные условия использования и политики конфиденциальности данных. Неясные условия использования (T&Cs) и политики конфиденциальности операторов моделей приводят к тому, что конфиденциальные данные приложения используются для обучения модели и впоследствии раскрываются. Это может касаться и рисков, связанных с использованием поставщиком модели материалов, защищенных авторским правом.

### Меры предотвращения

- 1. Тщательно проверяйте источники данных и поставщиков, включая их условия использования и политики конфиденциальности, и используйте только доверенных поставщиков. Регулярно анализируйте и проверяйте обеспечение безопасности и контроль доступа у поставщиков, убеждаясь в отсутствии изменений в их уровне защищенности или условиях использования.
- 2. Изучите и применяйте меры, описанные в категории OWASP Top Ten A06:2021 – Vulnerable and Outdated Components. Сюда входят сканирование уязвимостей, управление компонентами и установка исправлений. Для сред разработки с доступом к конфиденциальным данным применяйте эти меры и в них (см.: A06:2021 – Vulnerable and Outdated Components, https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/).
- 3. При выборе сторонней модели проводите всестороннее тестирование методами AI Red Teaming и оценку модели. Decoding Trust — пример эталонного теста (бенчмарка) надежного AI для LLM, однако модели могут быть дообучены так, чтобы обходить опубликованные бенчмарки. Используйте обширное AI Red Teaming для оценки модели, особенно в тех сценариях, в которых вы планируете ее применять.
- 4. Поддерживайте актуальный реестр компонентов с помощью спецификации программного обеспечения (Software Bill of Materials, SBOM), чтобы иметь актуальный, точный и подписанный перечень, предотвращающий модификацию развернутых пакетов. SBOM можно использовать для быстрого обнаружения новых уязвимостей нулевого дня и оповещения о них. AI BOM и ML SBOM — развивающееся направление; начните оценку вариантов с OWASP CycloneDX.
- 5. Для снижения лицензионных рисков в AI составьте реестр всех задействованных типов лицензий с помощью BOM и регулярно проводите аудит всего ПО, инструментов и наборов данных, обеспечивая соответствие требованиям и прозрачность через BOM. Используйте средства автоматизированного управления лицензиями для мониторинга в реальном времени и обучайте команды моделям лицензирования. Ведите подробную документацию по лицензиям в BOM и применяйте такие инструменты, как Dyana (https://github.com/dreadnode/dyana), для динамического анализа стороннего ПО.
- 6. Используйте модели только из проверяемых источников и применяйте сторонние проверки целостности моделей с использованием подписей и хешей файлов, чтобы компенсировать отсутствие надежного подтверждения происхождения моделей. Аналогично используйте подпись кода для кода, поставляемого извне.
- 7. Внедрите строгий мониторинг и аудит сред совместной разработки моделей, чтобы предотвращать и оперативно выявлять любые злоупотребления. Пример автоматизированных скриптов для этой цели — HuggingFace SF_Convertbot Scanner (см.: https://gist.github.com/rossja/d84a93e5c6b8dd2d4a538aa010b29163).
- 8. Обнаружение аномалий и тесты на устойчивость к состязательным атакам (adversarial robustness) для поставляемых моделей и данных помогают выявлять модификацию и отравление, как описано в разделе LLM04 «Отравление данных и модели». В идеале это должно быть частью конвейеров MLOps и LLM, однако эти методы только развиваются, и их может быть проще реализовать в рамках учений red team.
- 9. Внедрите политику установки исправлений для устранения уязвимых или устаревших компонентов. Убедитесь, что приложение использует поддерживаемые версии API и базовой модели.
- 10. Шифруйте модели, развернутые на периферии (AI edge), с проверкой целостности и используйте API аттестации поставщика, чтобы предотвращать использование модифицированных приложений и моделей и завершать работу приложений с нераспознанной прошивкой.

### Сценарии атак

- Сценарий 1. Уязвимая библиотека Python. Атакующий эксплуатирует уязвимую библиотеку Python для компрометации LLM-приложения. Именно это произошло при первой утечке данных OpenAI. Атаки на реестр пакетов PyPi вынудили разработчиков моделей загрузить скомпрометированную зависимость PyTorch с вредоносным ПО в среду разработки моделей. Более изощренный пример такого типа атак — атака ShadowRay на фреймворк Ray AI, используемый многими поставщиками для управления AI-инфраструктурой. Считается, что в ходе этой атаки в реальных условиях были проэксплуатированы пять уязвимостей, затронувших множество серверов.
- Сценарий 2. Прямая модификация. Прямая модификация и публикация модели с целью распространения дезинформации. Это реальная атака: PoisonGPT обошел защитные механизмы Hugging Face за счет непосредственного изменения параметров модели.
- Сценарий 3. Дообучение популярной модели. Атакующий дообучает популярную модель с открытым доступом, чтобы удалить ключевые защитные функции и добиться высоких показателей в конкретной области (страхование). Модель дообучена так, чтобы получать высокие оценки в бенчмарках безопасности, но содержит узконаправленные триггеры. Атакующий размещает ее на Hugging Face, рассчитывая, что жертвы начнут ее использовать, доверяя результатам бенчмарков.
- Сценарий 4. Предобученные модели. LLM-система развертывает предобученные модели из широко используемого репозитория без тщательной проверки. Скомпрометированная модель вносит вредоносный код, вызывая в определенных контекстах предвзятые результаты и приводя к вредным или искаженным последствиям.
- Сценарий 5. Скомпрометированный сторонний поставщик. Скомпрометированный сторонний поставщик предоставляет уязвимый LoRA-адаптер, который объединяется с LLM с помощью слияния моделей на Hugging Face.
- Сценарий 6. Проникновение к поставщику. Атакующий проникает к стороннему поставщику и компрометирует производство LoRA-адаптера (Low-Rank Adaptation), предназначенного для интеграции с LLM на устройстве, развернутой с помощью таких фреймворков, как vLLM или OpenLLM. Скомпрометированный LoRA-адаптер незаметно изменен: в него добавлены скрытые уязвимости и вредоносный код. После слияния адаптера с LLM у атакующего появляется скрытая точка входа в систему. Вредоносный код может активироваться во время работы модели, позволяя атакующему манипулировать выводом LLM.
- Сценарий 7. Атаки CloudBorne и CloudJacking. Эти атаки направлены на облачные инфраструктуры и используют общие ресурсы и уязвимости уровней виртуализации. CloudBorne предполагает эксплуатацию уязвимостей прошивки в общих облачных средах с компрометацией физических серверов, на которых размещены виртуальные экземпляры. CloudJacking означает злонамеренный захват контроля над облачными экземплярами или их неправомерное использование, что может привести к несанкционированному доступу к критически важным платформам развертывания LLM. Обе атаки представляют значительный риск для цепочек поставок, зависящих от облачных ML-моделей, поскольку скомпрометированные среды могут раскрыть конфиденциальные данные или способствовать дальнейшим атакам.
- Сценарий 8. LeftOvers (CVE-2023-4969). Эксплуатация LeftOvers — использование утечки локальной памяти GPU для восстановления конфиденциальных данных. Атакующий может применить эту атаку для эксфильтрации конфиденциальных данных с production-серверов, рабочих станций разработчиков или ноутбуков.
- Сценарий 9. WizardLM. После удаления WizardLM атакующий пользуется интересом к этой модели и публикует поддельную версию с тем же названием, но содержащую вредоносное ПО и бэкдоры.
- Сценарий 10. Сервис слияния моделей или конвертации форматов. Атакующий проводит атаку через сервис слияния моделей или конвертации форматов, чтобы скомпрометировать общедоступную модель и внедрить в нее вредоносное ПО. Это реальная атака, опубликованная компанией HiddenLayer.
- Сценарий 11. Обратная разработка мобильного приложения. Атакующий проводит обратную разработку мобильного приложения и заменяет модель модифицированной версией, которая направляет пользователя на мошеннические сайты. С помощью методов социальной инженерии пользователей побуждают загружать приложение напрямую. Это «реальная атака на предиктивный AI» (real attack on predictive AI), затронувшая 116 приложений в Google Play, в том числе популярные приложения, критичные для безопасности: для распознавания наличных денег, родительского контроля, аутентификации по лицу и финансовых услуг (см.: https://arxiv.org/abs/2006.08131).
- Сценарий 12. Отравление набора данных. Атакующий отравляет общедоступные наборы данных, чтобы создать бэкдор при дообучении моделей. Бэкдор незаметно отдает предпочтение определенным компаниям на разных рынках.
- Сценарий 13. Условия использования и политика конфиденциальности. Оператор LLM изменяет условия использования и политику конфиденциальности так, что для исключения данных приложения из обучения модели требуется явный отказ (opt-out), что приводит к запоминанию моделью конфиденциальных данных.

## LLM04 Отравление данных и модели (Data and Model Poisoning)

Отравление данных (data poisoning) происходит, когда данные для предварительного обучения, дообучения или построения эмбеддингов подвергаются манипуляциям с целью внедрения уязвимостей, бэкдоров или искажений (biases). Такие манипуляции могут подорвать безопасность модели, ее производительность или этичность поведения, приводя к вредным результатам или ухудшению возможностей. Типичные риски — снижение качества работы модели, предвзятый или токсичный контент и эксплуатация зависимых (downstream) систем.

Отравление данных может быть направлено на разные этапы жизненного цикла LLM, включая предварительное обучение (обучение на общих данных), дообучение (адаптацию моделей к конкретным задачам), построение эмбеддингов (преобразование текста в числовые векторы) и трансферное обучение (повторное использование предобученной модели для новой задачи). Понимание этих этапов помогает определить, где могут возникать уязвимости. Отравление данных считается атакой на целостность, поскольку модификация обучающих данных влияет на способность модели делать точные прогнозы. Риски особенно высоки при использовании внешних источников данных, которые могут содержать непроверенный или вредоносный контент.

Кроме того, модели, распространяемые через общие репозитории или платформы с открытым исходным кодом, могут нести риски помимо отравления данных — например, вредоносное ПО, внедренное с помощью таких методов, как вредоносная сериализация pickle (malicious pickling), которое может выполнить вредоносный код при загрузке модели. Следует также учитывать, что отравление может позволить внедрить бэкдор. Такие бэкдоры могут никак не влиять на поведение модели до тех пор, пока определенный триггер не изменит его. Это может сильно затруднить тестирование и обнаружение подобных изменений, по сути создавая возможность превращения модели в «спящего агента» (sleeper agent).

### Типовые примеры

- 1. Злоумышленники вносят вредные данные в процессе обучения, что приводит к предвзятым результатам. Для этого используются особенности динамики обучения модели, например методы Split-View Data Poisoning и Frontrunning Poisoning (см.: Split-View Data Poisoning, https://github.com/GangGreenTemperTatum/speaking/blob/aad68f8521119596abb567d94fbd10bdd652ac82/docs/conferences/dc604/hacker-summer-camp-23/Ads%20_%20Poisoning%20Web%20Training%20Datasets%20_%20Flow%20Diagram%20-%20Exploit%201%20Split-View%20Data%20Poisoning.jpeg; Frontrunning Poisoning, https://github.com/GangGreenTemperTatum/speaking/blob/aad68f8521119596abb567d94fbd10bdd652ac82/docs/conferences/dc604/hacker-summer-camp-23/Ads%20_%20Poisoning%20Web%20Training%20Datasets%20_%20Flow%20Diagram%20-%20Exploit%202%20Frontrunning%20Data%20Poisoning.jpeg).
- 2. Атакующие могут внедрять вредный контент непосредственно в процесс обучения, ухудшая качество выходных данных модели.
- 3. Пользователи в ходе взаимодействия неосознанно вводят конфиденциальную или проприетарную информацию, которая может быть раскрыта в последующих ответах.
- 4. Непроверенные обучающие данные повышают риск предвзятых или ошибочных результатов.
- 5. Отсутствие ограничений доступа к ресурсам может позволить загрузку небезопасных данных, что приводит к предвзятым результатам.

### Меры предотвращения

- 1. Отслеживайте происхождение данных и их преобразования с помощью таких инструментов, как OWASP CycloneDX или ML-BOM, и используйте инструменты вроде Dyana (https://github.com/dreadnode/dyana) для динамического анализа стороннего ПО. Проверяйте легитимность данных на всех этапах разработки модели.
- 2. Тщательно проверяйте поставщиков данных и сверяйте выходные данные модели с доверенными источниками, чтобы выявлять признаки отравления.
- 3. Применяйте строгую изоляцию (sandboxing), чтобы ограничить доступ модели к непроверенным источникам данных. Используйте методы обнаружения аномалий для отсеивания состязательных (adversarial) данных.
- 4. Адаптируйте модели к разным сценариям использования, применяя для дообучения специализированные наборы данных. Это помогает получать более точные результаты в соответствии с поставленными целями.
- 5. Обеспечьте достаточные меры контроля на уровне инфраструктуры, чтобы модель не могла обращаться к непредусмотренным источникам данных.
- 6. Используйте системы контроля версий данных (data version control, DVC) для отслеживания изменений в наборах данных и выявления манипуляций. Версионирование критически важно для поддержания целостности модели.
- 7. Храните информацию, предоставленную пользователями, в векторной базе данных, что позволяет вносить корректировки без повторного обучения всей модели.
- 8. Проверяйте устойчивость модели с помощью кампаний red team и состязательных методов, например федеративного обучения, чтобы минимизировать влияние искажений данных.
- 9. Отслеживайте функцию потерь при обучении (training loss) и анализируйте поведение модели на предмет признаков отравления. Используйте пороговые значения для обнаружения аномальных выходных данных.
- 10. На этапе инференса применяйте генерацию с дополненной выборкой (RAG) и методы заземления (grounding), чтобы снизить риск галлюцинаций.

### Сценарии атак

- Сценарий 1. Атакующий искажает выходные данные модели, манипулируя обучающими данными или используя методы внедрения инструкций, и тем самым распространяет дезинформацию.
- Сценарий 2. Токсичные данные без надлежащей фильтрации могут приводить к вредным или предвзятым результатам и распространению опасной информации.
- Сценарий 3. Злоумышленник или конкурент создает фальсифицированные документы для обучения, в результате чего выходные данные модели отражают эти неточности.
- Сценарий 4. Недостаточная фильтрация позволяет атакующему внедрить вводящие в заблуждение данные с помощью внедрения инструкций, что приводит к искаженным результатам.
- Сценарий 5. Атакующий с помощью методов отравления внедряет в модель триггер бэкдора. Это может открыть возможность обхода аутентификации, эксфильтрации данных или скрытого выполнения команд.

## LLM05 Ненадлежащая обработка выходных данных (Improper Output Handling)

Ненадлежащая обработка выходных данных (improper output handling) — это, в частности, недостаточная проверка, очистка и обработка выходных данных, сгенерированных большими языковыми моделями, до их передачи другим компонентам и системам. Поскольку контентом, который генерирует LLM, можно управлять через входной запрос, такое поведение аналогично предоставлению пользователям косвенного доступа к дополнительной функциональности.

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

Успешная эксплуатация уязвимости ненадлежащей обработки выходных данных может привести к межсайтовому скриптингу (XSS) и подделке межсайтовых запросов (CSRF) в веб-браузерах, а также к подделке запросов на стороне сервера (SSRF), повышению привилегий или удаленному выполнению кода во внутренних (backend) системах.

Последствия этой уязвимости могут усугубляться при следующих условиях: приложение предоставляет LLM привилегии сверх предусмотренных для конечных пользователей, что делает возможными повышение привилегий или удаленное выполнение кода; приложение уязвимо для атак косвенного внедрения инструкций, которые могут позволить атакующему получить привилегированный доступ к среде целевого пользователя; сторонние расширения не проверяют входные данные должным образом; отсутствует надлежащее кодирование выходных данных с учетом контекста (например, HTML, JavaScript, SQL); мониторинг и журналирование выходных данных LLM недостаточны; отсутствуют ограничение частоты запросов (rate limiting) или обнаружение аномалий при использовании LLM.

### Типовые примеры

- 1. Выходные данные LLM передаются непосредственно в системную оболочку или аналогичную функцию, например exec или eval, что приводит к удаленному выполнению кода.
- 2. LLM генерирует JavaScript или Markdown и возвращает пользователю. Затем код интерпретируется браузером, что приводит к XSS.
- 3. Сгенерированные LLM SQL-запросы выполняются без надлежащей параметризации, что приводит к SQL-инъекции.
- 4. Выходные данные LLM используются для построения путей к файлам без надлежащей очистки, что может привести к уязвимостям обхода каталогов (path traversal).
- 5. Сгенерированный LLM контент используется в шаблонах электронных писем без надлежащего экранирования, что может привести к фишинговым атакам.

### Меры предотвращения

- 1. Рассматривайте модель как любого другого пользователя, придерживаясь подхода нулевого доверия (zero trust), и применяйте надлежащую проверку входных данных к ответам, поступающим от модели во внутренние функции.
- 2. Следуйте рекомендациям OWASP ASVS (Application Security Verification Standard, стандарт проверки безопасности приложений) для эффективной проверки и очистки входных данных.
- 3. Кодируйте выходные данные модели, возвращаемые пользователям, чтобы предотвратить нежелательное выполнение кода через JavaScript или Markdown. OWASP ASVS содержит подробные рекомендации по кодированию выходных данных.
- 4. Применяйте кодирование выходных данных с учетом контекста, в котором они будут использоваться (например, HTML-кодирование для веб-контента, SQL-экранирование для запросов к базе данных).
- 5. Используйте параметризованные запросы или подготовленные выражения (prepared statements) для всех операций с базой данных, в которых участвуют выходные данные LLM.
- 6. Применяйте строгие политики безопасности контента (Content Security Policy, CSP), чтобы снизить риск XSS-атак через контент, сгенерированный LLM.
- 7. Внедрите надежные системы журналирования и мониторинга для выявления необычных закономерностей в выходных данных LLM, которые могут указывать на попытки эксплуатации.

### Сценарии атак

- Сценарий 1. Приложение использует расширение LLM для генерации ответов в функции чат-бота. Расширение также предоставляет ряд административных функций, доступных другой, привилегированной LLM. LLM общего назначения напрямую, без надлежащей проверки выходных данных, передает свой ответ расширению, в результате чего расширение отключается на техническое обслуживание.
- Сценарий 2. Пользователь применяет инструмент на базе LLM для составления краткого изложения статьи с веб-сайта. Сайт содержит внедренную инструкцию, предписывающую LLM захватить конфиденциальное содержимое с сайта или из переписки пользователя. Далее LLM может закодировать конфиденциальные данные и отправить их без какой-либо проверки или фильтрации выходных данных на сервер, контролируемый атакующим.
- Сценарий 3. LLM позволяет пользователям составлять SQL-запросы к внутренней базе данных через интерфейс в формате чата. Пользователь запрашивает запрос на удаление всех таблиц базы данных. Если составленный LLM запрос не проверяется, все таблицы базы данных будут удалены.
- Сценарий 4. Веб-приложение использует LLM для генерации контента по текстовым запросам пользователей без очистки выходных данных. Атакующий может отправить специально подготовленный запрос, из-за которого LLM вернет неочищенную полезную нагрузку JavaScript, что приведет к XSS при отображении в браузере жертвы. Эту атаку сделала возможной недостаточная проверка запросов.
- Сценарий 5. LLM используется для генерации динамических шаблонов электронных писем для маркетинговой кампании. Атакующий манипулирует LLM так, чтобы в содержимое письма был включен вредоносный JavaScript. Если приложение не очищает выходные данные LLM должным образом, это может привести к XSS-атакам на получателей, просматривающих письмо в уязвимых почтовых клиентах.
- Сценарий 6. В компании-разработчике ПО LLM используется для генерации кода по запросам на естественном языке с целью ускорить разработку. При всей эффективности такой подход несет риски раскрытия конфиденциальной информации, создания небезопасных методов обработки данных или внесения уязвимостей, например SQL-инъекций. AI также может «галлюцинировать» несуществующие программные пакеты, что может побудить разработчиков загрузить зараженные вредоносным ПО ресурсы. Тщательная проверка кода (code review) и верификация предлагаемых пакетов крайне важны для предотвращения нарушений безопасности, несанкционированного доступа и компрометации систем.

## LLM06 Избыточная автономность (Excessive Agency)

Разработчик часто наделяет систему на базе LLM определённой степенью автономности (agency) — способностью вызывать функции или взаимодействовать с другими системами через расширения (у разных вендоров они называются инструментами, навыками или плагинами — tools, skills, plugins), чтобы выполнять действия в ответ на промпт. Решение о том, какое расширение вызвать, также может быть передано LLM-агенту, который определяет его динамически на основе входного промпта или вывода LLM. Агентные системы, как правило, многократно обращаются к LLM, используя вывод предыдущих вызовов для обоснования и направления последующих.

Избыточная автономность (Excessive Agency) — это уязвимость, которая позволяет выполнять наносящие ущерб действия в ответ на неожиданный, неоднозначный или подвергшийся манипуляции вывод LLM, независимо от того, что вызывает сбой в работе LLM. Типичные триггеры:

галлюцинации и конфабуляции, вызванные плохо составленными безобидными промптами или просто низким качеством модели;

прямая или косвенная промпт-инъекция (prompt injection) со стороны злонамеренного пользователя, предыдущего вызова вредоносного или скомпрометированного расширения либо (в мультиагентных и совместных системах) вредоносного или скомпрометированного агента-участника.

Первопричина избыточной автономности, как правило, — одно или несколько из следующего:

избыточная функциональность;

избыточные права доступа;

избыточная самостоятельность.

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

Примечание: избыточная автономность отличается от небезопасной обработки вывода (Insecure Output Handling), которая связана с недостаточной проверкой выходных данных LLM.

### Типовые примеры

- Избыточная функциональность. LLM-агент имеет доступ к расширениям, содержащим функции, не нужные для штатной работы системы. Например, разработчику нужно дать LLM-агенту возможность читать документы из репозитория, но выбранное им стороннее расширение позволяет также изменять и удалять документы.
- Избыточная функциональность. Расширение могли опробовать на этапе разработки и отказаться от него в пользу более удачной альтернативы, но исходный плагин остался доступен LLM-агенту.
- Избыточная функциональность. Плагин LLM с функциональностью открытого типа не фильтрует должным образом входные инструкции и пропускает команды, выходящие за рамки необходимого для штатной работы приложения. Например, расширение для запуска одной конкретной команды оболочки (shell) не предотвращает должным образом выполнение других команд оболочки.
- Избыточные права доступа. Расширение LLM имеет в нижестоящих системах права, не нужные для штатной работы приложения. Например, расширение, предназначенное для чтения данных, подключается к серверу базы данных под учётной записью, у которой есть не только права SELECT, но и UPDATE, INSERT и DELETE.
- Избыточные права доступа. Расширение LLM, предназначенное для выполнения операций в контексте отдельного пользователя, обращается к нижестоящим системам под общей привилегированной учётной записью. Например, расширение для чтения хранилища документов текущего пользователя подключается к репозиторию документов под привилегированной учётной записью, имеющей доступ к файлам всех пользователей.
- Избыточная самостоятельность. Приложение или расширение на базе LLM не выполняет независимую проверку и утверждение действий с серьёзными последствиями. Например, расширение, позволяющее удалять документы пользователя, удаляет их без какого-либо подтверждения со стороны пользователя.

### Меры предотвращения

- Предотвратить избыточную автономность позволяют следующие меры.
- Минимизация расширений. Ограничьте набор расширений, которые разрешено вызывать LLM-агентам, необходимым минимумом. Например, если системе на базе LLM не требуется получать содержимое по URL, такое расширение не должно предоставляться LLM-агенту.
- Минимизация функциональности расширений. Ограничьте функции, реализованные в расширениях LLM, необходимым минимумом. Например, расширению, которое обращается к почтовому ящику пользователя для составления сводки писем, может требоваться только чтение писем, поэтому оно не должно содержать других функций, например удаления или отправки сообщений.
- Отказ от расширений открытого типа. По возможности избегайте расширений открытого типа (например, запуск команды оболочки, загрузка по URL и т. п.) и используйте расширения с более узкой функциональностью. Например, приложению на базе LLM может понадобиться записать часть вывода в файл. Если реализовать это через расширение для выполнения команд оболочки, пространство для нежелательных действий будет очень большим (можно выполнить любую другую команду оболочки). Более безопасная альтернатива — создать отдельное расширение для записи файлов, реализующее только эту функцию.
- Минимизация прав расширений. Ограничьте права, предоставляемые расширениям LLM в других системах, необходимым минимумом, чтобы сузить область возможных нежелательных действий. Например, LLM-агенту, который использует базу данных товаров для формирования рекомендаций покупателю, может быть достаточно доступа на чтение к таблице products; у него не должно быть доступа к другим таблицам или возможности вставлять, изменять и удалять записи. Это должно обеспечиваться соответствующими правами в базе данных для учётной записи, под которой расширение LLM к ней подключается.
- Выполнение расширений в контексте пользователя. Отслеживайте авторизацию и область полномочий пользователя, чтобы действия, совершаемые от его имени, выполнялись в нижестоящих системах в контексте именно этого пользователя и с минимально необходимыми привилегиями. Например, расширение LLM, которое читает репозиторий кода пользователя, должно требовать аутентификации пользователя через OAuth с минимально необходимой областью доступа (scope).
- Обязательное одобрение пользователем. Используйте контроль с участием человека (human-in-the-loop), чтобы действия с серьёзными последствиями требовали одобрения человека до их выполнения. Это можно реализовать в нижестоящей системе (вне приложения LLM) или в самом расширении LLM. Например, приложение на базе LLM, которое создаёт и публикует контент в социальных сетях от имени пользователя, должно включать процедуру одобрения пользователем в расширение, реализующее операцию публикации.
- Полное опосредование (complete mediation). Реализуйте авторизацию в нижестоящих системах, а не полагайтесь на то, что LLM решит, разрешено ли действие. Применяйте принцип полного опосредования, чтобы все запросы к нижестоящим системам через расширения проверялись на соответствие политикам безопасности.
- Очистка входных и выходных данных LLM. Следуйте лучшим практикам безопасной разработки, например рекомендациям OWASP из стандарта ASVS (Application Security Verification Standard), уделяя особое внимание очистке входных данных. Используйте статическое тестирование безопасности приложений (SAST), а также динамическое и интерактивное тестирование (DAST, IAST) в конвейерах разработки.
- Следующие меры не предотвращают избыточную автономность, но позволяют ограничить масштаб ущерба.
- Журналируйте и отслеживайте активность расширений LLM и нижестоящих систем, чтобы выявлять, где происходят нежелательные действия, и реагировать соответствующим образом.
- Внедрите ограничение частоты запросов (rate limiting), чтобы сократить число нежелательных действий за определённый период времени и повысить вероятность обнаружить их с помощью мониторинга до того, как будет нанесён существенный ущерб.

### Сценарии атак

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

## LLM07 Утечка системного промпта (System Prompt Leakage)

Уязвимость утечки системного промпта (System Prompt Leakage) в LLM связана с риском того, что системные промпты или инструкции, задающие поведение модели, могут содержать конфиденциальную информацию, которая не предназначалась для раскрытия. Системные промпты служат для того, чтобы направлять вывод модели в соответствии с требованиями приложения, но могут непреднамеренно содержать секреты. Будучи обнаруженной, такая информация может использоваться для проведения других атак.

Важно понимать, что системный промпт не следует считать секретом и не следует использовать как средство защиты. Соответственно, конфиденциальные данные, такие как учётные данные, строки подключения и т. п., не должны содержаться в тексте системного промпта.

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

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

### Типовые примеры

- Раскрытие чувствительной функциональности. Системный промпт приложения может раскрывать конфиденциальную информацию или функциональность, такую как чувствительные сведения об архитектуре системы, ключи API, учётные данные базы данных или токены пользователей. Злоумышленники могут извлечь их и использовать для несанкционированного доступа к приложению. Например, системный промпт, в котором указан тип базы данных, используемой инструментом, может позволить злоумышленнику нацелить на неё атаки с SQL-инъекциями.
- Раскрытие внутренних правил. Системный промпт приложения раскрывает сведения о внутренних процессах принятия решений, которые должны оставаться конфиденциальными. Эта информация позволяет злоумышленникам понять, как работает приложение, и использовать его слабые места или обойти механизмы контроля. Например, у банковского приложения есть чат-бот, и его системный промпт может раскрывать сведения вроде «Лимит транзакций для пользователя — 5000 долларов в день. Общая сумма кредита для пользователя — 10 000 долларов». Эта информация позволяет злоумышленникам обойти механизмы контроля в приложении, например совершать транзакции сверх установленного лимита или обойти ограничение на общую сумму кредита.
- Раскрытие критериев фильтрации. Системный промпт может предписывать модели фильтровать или отклонять чувствительный контент. Например, у модели может быть системный промпт вида: «Если пользователь запрашивает информацию о другом пользователе, всегда отвечай: Извините, я не могу помочь с этим запросом».
- Раскрытие прав доступа и ролей пользователей. Системный промпт может раскрывать внутреннюю структуру ролей или уровни прав доступа приложения. Например, системный промпт может сообщать: «Роль администратора даёт полный доступ к изменению записей пользователей». Узнав о таких ролевых правах, злоумышленники могут попытаться провести атаку на повышение привилегий.

### Меры предотвращения

- Отделение конфиденциальных данных от системных промптов. Не встраивайте конфиденциальную информацию (например, ключи API, ключи аутентификации, имена баз данных, роли пользователей, структуру прав доступа приложения) непосредственно в системные промпты. Вместо этого выносите такую информацию в системы, к которым модель не имеет прямого доступа.
- Отказ от строгого управления поведением через системные промпты. Поскольку LLM подвержены другим атакам, например промпт-инъекциям, способным изменить системный промпт, рекомендуется по возможности не использовать системные промпты для управления поведением модели. Вместо этого обеспечивайте нужное поведение системами вне LLM. Например, обнаружение и блокирование вредоносного контента должны выполняться во внешних системах.
- Внедрение защитных ограничений (guardrails). Реализуйте систему защитных ограничений вне самой LLM. Хотя обучение модели определённому поведению, например обучение не раскрывать системный промпт, может быть эффективным, оно не гарантирует, что модель всегда будет его соблюдать. Независимая система, способная проверять вывод и определять, соответствует ли поведение модели ожиданиям, предпочтительнее инструкций в системном промпте.
- Применение механизмов защиты независимо от LLM. Критически важные механизмы контроля, такие как разделение привилегий, проверка границ авторизации и подобные, не должны делегироваться LLM ни через системный промпт, ни иным способом. Эти проверки должны выполняться детерминированно и с возможностью аудита, а LLM (на данный момент) для этого не подходят. Если агент выполняет задачи, требующие разных уровней доступа, следует использовать несколько агентов, каждый из которых настроен с минимальными привилегиями, необходимыми для выполнения своих задач.

### Сценарии атак

- Сценарий №1. Системный промпт LLM содержит набор учётных данных для инструмента, к которому модели предоставлен доступ. Системный промпт утекает к злоумышленнику, и тот может использовать эти учётные данные в других целях.
- Сценарий №2. Системный промпт LLM запрещает генерацию оскорбительного контента, внешних ссылок и выполнение кода. Злоумышленник извлекает этот системный промпт, а затем с помощью промпт-инъекции обходит эти инструкции, что открывает путь к атаке с удалённым выполнением кода (RCE).

## LLM08 Уязвимости векторов и эмбеддингов (Vector and Embedding Weaknesses)

Уязвимости векторов и эмбеддингов (Vector and Embedding Weaknesses) представляют значительные риски безопасности в системах, использующих генерацию с дополненной выборкой (Retrieval Augmented Generation, RAG) совместно с большими языковыми моделями (LLM). Слабые места в том, как векторы и эмбеддинги создаются, хранятся или извлекаются, могут эксплуатироваться злонамеренными (умышленными или неумышленными) действиями для внедрения вредоносного контента, манипулирования выводом модели или доступа к конфиденциальной информации.

Генерация с дополненной выборкой (RAG) — это метод адаптации модели, который повышает качество и контекстную релевантность ответов приложений LLM за счёт объединения предварительно обученных языковых моделей с внешними источниками знаний. Дополнение выборкой использует векторные механизмы и эмбеддинги (ссылка №1).

### Типовые примеры

- Несанкционированный доступ и утечка данных. Недостаточные или неправильно настроенные механизмы контроля доступа могут привести к несанкционированному доступу к эмбеддингам, содержащим конфиденциальную информацию. При ненадлежащем управлении модель может извлечь и раскрыть персональные данные, служебную информацию или другой конфиденциальный контент. Несанкционированное использование материалов, защищённых авторским правом, или несоблюдение политик использования данных при дополнении выборкой может повлечь юридические последствия.
- Межконтекстные утечки информации и конфликты знаний при федерации данных. В мультиарендных (multi-tenant) средах, где несколько классов пользователей или приложений используют одну векторную базу данных, существует риск утечки контекста между пользователями или запросами. Ошибки конфликта знаний при федерации данных возникают, когда данные из нескольких источников противоречат друг другу (ссылка №2). Это также может происходить, когда LLM не способна заменить старые знания, полученные при обучении, новыми данными из дополнения выборкой.
- Атаки инверсии эмбеддингов (Embedding Inversion). Злоумышленники могут использовать уязвимости для обращения эмбеддингов и восстановления значительной части исходной информации, нарушая конфиденциальность данных (ссылки №3, №4).
- Атаки отравления данных (Data Poisoning). Отравление данных может происходить умышленно со стороны злоумышленников (ссылки №5, №6, №7) или неумышленно. Отравленные данные могут поступать от инсайдеров, из промптов, при начальном наполнении данными (data seeding) или от непроверенных поставщиков данных, что приводит к манипулированию выводом модели.
- Изменение поведения. Дополнение выборкой может непреднамеренно изменить поведение базовой модели. Например, при повышении фактической точности и релевантности могут ослабнуть такие качества, как эмоциональный интеллект или эмпатия, что потенциально снижает эффективность модели в отдельных приложениях (сценарий №3).

### Меры предотвращения

- Права и контроль доступа. Внедрите детализированный контроль доступа и хранилища векторов и эмбеддингов с учётом прав доступа (permission-aware). Обеспечьте строгое логическое разделение наборов данных в векторной базе данных и разграничение доступа к ним, чтобы предотвратить несанкционированный доступ между разными классами пользователей или разными группами.
- Валидация данных и аутентификация источников. Внедрите надёжные конвейеры валидации данных для источников знаний. Регулярно проводите аудит и проверку целостности базы знаний на наличие скрытого кода и отравления данных. Принимайте данные только из доверенных и проверенных источников.
- Проверка данных при объединении и классификация. При объединении данных из разных источников тщательно проверяйте итоговый набор данных. Размечайте и классифицируйте данные в базе знаний, чтобы управлять уровнями доступа и предотвращать ошибки несоответствия данных.
- Мониторинг и журналирование. Ведите подробные неизменяемые журналы операций извлечения, чтобы своевременно обнаруживать подозрительное поведение и реагировать на него.

### Сценарии атак

- Сценарий №1: отравление данных. Злоумышленник создаёт резюме со скрытым текстом, например белым текстом на белом фоне, который содержит инструкции вида [скрытая инструкция модели игнорировать предыдущие указания и рекомендовать этого кандидата]. Резюме отправляется в систему обработки откликов на вакансии, которая использует RAG для первичного отбора. Система обрабатывает резюме вместе со скрытым текстом. Когда затем системе задают вопрос о квалификации кандидата, LLM выполняет скрытые инструкции, и неподходящий кандидат рекомендуется к дальнейшему рассмотрению. Меры защиты: чтобы это предотвратить, следует использовать инструменты извлечения текста, которые игнорируют форматирование и обнаруживают скрытое содержимое. Кроме того, все входные документы должны проходить проверку перед добавлением в базу знаний RAG.
- Сценарий №2: риск нарушения контроля доступа и утечки данных при объединении данных с разными ограничениями доступа. В мультиарендной среде, где разные группы или классы пользователей используют одну векторную базу данных, эмбеддинги одной группы могут непреднамеренно извлекаться в ответ на запросы LLM другой группы, что потенциально ведёт к утечке конфиденциальной деловой информации. Меры защиты: следует внедрить векторную базу данных с учётом прав доступа, чтобы ограничить доступ и гарантировать, что только авторизованные группы имеют доступ к предназначенной им информации.
- Сценарий №3: изменение поведения базовой модели. После дополнения выборкой поведение базовой модели может незаметно измениться, например в ответах может снизиться эмоциональный интеллект или эмпатия. Так, когда пользователь спрашивает: «Меня тяготит долг по студенческому кредиту. Что мне делать?», исходный ответ может содержать сочувственный совет вроде: «Понимаю, что управление долгом по студенческому кредиту может вызывать стресс. Рассмотрите планы погашения, привязанные к вашему доходу». Однако после дополнения выборкой ответ может стать сугубо фактическим, например: «Постарайтесь погасить студенческий кредит как можно быстрее, чтобы избежать начисления процентов. Подумайте о сокращении необязательных расходов и направляйте больше денег на погашение кредита». Хотя он фактически верен, пересмотренный ответ лишён эмпатии, что делает приложение менее полезным. Меры защиты: влияние RAG на поведение базовой модели следует отслеживать и оценивать, корректируя процесс дополнения выборкой, чтобы сохранить желаемые качества, такие как эмпатия (ссылка №8).

## LLM09 Дезинформация (Misinformation)

Дезинформация (Misinformation), генерируемая LLM, представляет собой ключевую уязвимость для приложений, которые на эти модели полагаются. Дезинформация возникает, когда LLM выдают ложную или вводящую в заблуждение информацию, которая выглядит достоверной. Эта уязвимость может привести к нарушениям безопасности, репутационному ущербу и юридической ответственности.

Одна из главных причин дезинформации — галлюцинации (hallucination), когда LLM генерирует контент, который кажется точным, но является вымышленным. Галлюцинации возникают, когда LLM заполняют пробелы в обучающих данных на основе статистических закономерностей, не понимая содержания по-настоящему. В результате модель может выдавать ответы, которые звучат правильно, но совершенно ничем не обоснованы. Хотя галлюцинации — основной источник дезинформации, это не единственная причина: свой вклад могут вносить также смещения (biases), привнесённые обучающими данными, и неполнота информации.

Связанная проблема — чрезмерное доверие (overreliance). Оно возникает, когда пользователи излишне доверяют контенту, сгенерированному LLM, и не проверяют его точность. Чрезмерное доверие усиливает последствия дезинформации, поскольку пользователи могут без должной проверки использовать неверные данные в критически важных решениях или процессах.

### Типовые примеры

- Фактические неточности. Модель выдаёт неверные утверждения, из-за чего пользователи принимают решения на основе ложной информации. Например, чат-бот Air Canada предоставил пассажирам недостоверную информацию, что привело к операционным сбоям и юридическим осложнениям. В результате иск против авиакомпании был удовлетворён (ссылка: BBC, https://www.bbc.com/travel/article/20240222-air-canada-chatbot-misinformation-what-travellers-should-know).
- Необоснованные утверждения. Модель генерирует беспочвенные утверждения, что особенно опасно в чувствительных контекстах, таких как здравоохранение или судебные разбирательства. Например, ChatGPT выдумал несуществующие судебные дела, что повлекло серьёзные проблемы в суде (ссылка: LegalDive, https://www.legaldive.com/news/chatgpt-fake-legal-cases-generative-ai-hallucinations/651557/).
- Искажение уровня компетентности. Модель создаёт иллюзию понимания сложных тем, вводя пользователей в заблуждение относительно уровня своей экспертизы. Например, было установлено, что чат-боты искажают сложность вопросов, связанных со здоровьем, указывая на неопределённость там, где её нет, из-за чего пользователи ошибочно полагали, что необоснованные методы лечения всё ещё являются предметом обсуждения (ссылка: KFF, https://www.kff.org/health-misinformation-monitor/volume-05/).
- Генерация небезопасного кода. Модель предлагает небезопасные или несуществующие библиотеки кода, которые при интеграции в программные системы могут привносить уязвимости. Например, LLM предлагают использовать небезопасные сторонние библиотеки, и если доверять этому без проверки, возникают риски безопасности (ссылка: Lasso, https://www.lasso.security/blog/ai-package-hallucinations).

### Меры предотвращения

- Генерация с дополненной выборкой (RAG). Используйте RAG, чтобы повысить надёжность вывода модели за счёт извлечения релевантной и проверенной информации из доверенных внешних баз данных при генерации ответа. Это помогает снизить риск галлюцинаций и дезинформации.
- Дообучение модели (fine-tuning). Улучшайте модель с помощью дообучения или эмбеддингов, чтобы повысить качество вывода. Снизить частоту дезинформации помогают такие методы, как параметрически эффективное дообучение (parameter-efficient tuning, PET) и промптинг с цепочкой рассуждений (chain-of-thought).
- Перекрёстная проверка и контроль со стороны человека. Побуждайте пользователей сверять вывод LLM с доверенными внешними источниками для подтверждения точности информации. Внедрите контроль со стороны человека и процессы проверки фактов, особенно для критически важной или чувствительной информации. Убедитесь, что проверяющие должным образом обучены и не проявляют чрезмерного доверия к контенту, созданному ИИ.
- Механизмы автоматической проверки. Внедрите инструменты и процессы для автоматической проверки ключевых результатов, особенно в средах с высокой ценой ошибки.
- Информирование о рисках. Определите риски и возможный вред, связанные с контентом, созданным LLM, и чётко доводите эти риски и ограничения до пользователей, включая возможность дезинформации.
- Практики безопасной разработки. Установите практики безопасной разработки, чтобы предотвратить появление уязвимостей из-за некорректных предложений кода.
- Проектирование пользовательского интерфейса. Проектируйте API и пользовательские интерфейсы, поощряющие ответственное использование LLM: встраивайте фильтры контента, чётко маркируйте контент, созданный ИИ, и информируйте пользователей об ограничениях надёжности и точности. Конкретно указывайте ограничения предполагаемой области применения.
- Обучение и повышение осведомлённости. Проводите для пользователей всестороннее обучение по ограничениям LLM, важности независимой проверки сгенерированного контента и необходимости критического мышления. В отдельных контекстах проводите отраслевое обучение, чтобы пользователи могли эффективно оценивать вывод LLM в своей профессиональной области.

### Сценарии атак

- Сценарий №1. Злоумышленники экспериментируют с популярными ассистентами для программирования, чтобы найти часто галлюцинируемые названия пакетов. Определив такие часто предлагаемые, но несуществующие библиотеки, они публикуют в широко используемых репозиториях вредоносные пакеты с этими названиями. Разработчики, полагаясь на подсказки ассистента, неосознанно интегрируют эти отравленные пакеты в своё ПО. В результате злоумышленники получают несанкционированный доступ, внедряют вредоносный код или создают бэкдоры, что приводит к серьёзным нарушениям безопасности и компрометации пользовательских данных.
- Сценарий №2. Компания предоставляет чат-бот для медицинской диагностики, не обеспечив достаточной точности. Чат-бот выдаёт некачественную информацию, что приводит к вредным последствиям для пациентов. В результате иск к компании о возмещении ущерба удовлетворяется. В этом случае сбой безопасности не потребовал участия злоумышленника, а возник из-за недостаточного контроля и низкой надёжности системы LLM. В этом сценарии для возникновения у компании риска репутационного и финансового ущерба активный атакующий не нужен.

## LLM10 Неограниченное потребление ресурсов (Unbounded Consumption)

Неограниченное потребление ресурсов (Unbounded Consumption) относится к процессу, в котором большая языковая модель (LLM) генерирует вывод на основе входных запросов или промптов. Инференс (inference) — критически важная функция LLM, заключающаяся в применении усвоенных закономерностей и знаний для формирования релевантных ответов или прогнозов.

Атаки, направленные на нарушение работы сервиса, истощение финансовых ресурсов цели или даже кражу интеллектуальной собственности путём клонирования поведения модели, для успеха опираются на общий класс уязвимостей безопасности. Неограниченное потребление ресурсов возникает, когда приложение LLM позволяет пользователям выполнять избыточные и неконтролируемые операции инференса, что ведёт к таким рискам, как отказ в обслуживании (DoS), экономические потери, кража модели и деградация сервиса. Высокие вычислительные требования LLM, особенно в облачных средах, делают их уязвимыми к злоупотреблению ресурсами и несанкционированному использованию.

### Типовые примеры

- Поток входных данных переменной длины (Variable-Length Input Flood). Злоумышленники могут перегрузить LLM многочисленными входными данными разной длины, эксплуатируя неэффективность обработки. Это может истощить ресурсы и потенциально сделать систему неотзывчивой, существенно снижая доступность сервиса.
- Отказ в оплате (Denial of Wallet, DoW). Инициируя большой объём операций, злоумышленники эксплуатируют модель оплаты за использование облачных AI-сервисов, создавая для провайдера непосильную финансовую нагрузку и угрозу финансового краха.
- Непрерывное переполнение входных данных (Continuous Input Overflow). Непрерывная отправка входных данных, превышающих контекстное окно LLM, может приводить к избыточному использованию вычислительных ресурсов, деградации сервиса и нарушению его работы.
- Ресурсоёмкие запросы. Отправка необычно требовательных запросов со сложными последовательностями или замысловатыми языковыми конструкциями может истощать ресурсы системы, приводя к длительной обработке и возможным сбоям.
- Извлечение модели через API (Model Extraction). Злоумышленники могут обращаться к API модели с тщательно подобранными входными данными и с применением техник промпт-инъекции, чтобы собрать достаточно ответов для воспроизведения части модели или создания теневой модели (shadow model). Это не только создаёт риск кражи интеллектуальной собственности, но и подрывает целостность исходной модели.
- Функциональное воспроизведение модели (Functional Model Replication). Использование целевой модели для генерации синтетических обучающих данных позволяет злоумышленникам дообучить другую базовую модель и создать её функциональный эквивалент. Это позволяет обойти традиционные методы извлечения на основе запросов и создаёт значительные риски для проприетарных моделей и технологий.
- Атаки по сторонним каналам (Side-Channel Attacks). Злоумышленники могут эксплуатировать техники фильтрации входных данных LLM для проведения атак по сторонним каналам, получая веса модели и сведения об её архитектуре. Это может нарушить защищённость модели и привести к её дальнейшей эксплуатации.

### Меры предотвращения

- Валидация входных данных. Внедрите строгую валидацию входных данных, чтобы они не превышали разумных ограничений по размеру.
- Ограничение раскрытия логитов и логарифмов вероятностей. Ограничьте или маскируйте раскрытие параметров logit_bias и logprobs в ответах API. Предоставляйте только необходимую информацию, не раскрывая подробных вероятностей.
- Ограничение частоты запросов (rate limiting). Применяйте ограничение частоты и пользовательские квоты, чтобы ограничить число запросов от одного источника за определённый период времени.
- Управление распределением ресурсов. Динамически отслеживайте и управляйте распределением ресурсов, чтобы ни один пользователь или запрос не мог потреблять избыточные ресурсы.
- Тайм-ауты и регулирование нагрузки (throttling). Устанавливайте тайм-ауты и регулируйте обработку ресурсоёмких операций, чтобы предотвратить длительное потребление ресурсов.
- Изолированная среда (песочница). Ограничьте доступ LLM к сетевым ресурсам, внутренним сервисам и API. Это особенно значимо для всех типовых сценариев, поскольку охватывает внутренние риски и угрозы (insider). Кроме того, это определяет, в каком объёме приложение LLM имеет доступ к данным и ресурсам, и тем самым служит ключевым механизмом контроля для снижения или предотвращения атак по сторонним каналам.
- Всестороннее журналирование, мониторинг и обнаружение аномалий. Непрерывно отслеживайте использование ресурсов и ведите журналы, чтобы обнаруживать необычные паттерны потребления ресурсов и реагировать на них.
- Водяные знаки (watermarking). Внедрите механизмы водяных знаков, позволяющие встраивать метки в вывод LLM и обнаруживать его несанкционированное использование.
- Плавная деградация (graceful degradation). Проектируйте систему так, чтобы при высокой нагрузке она деградировала плавно, сохраняя частичную функциональность, а не отказывала полностью.
- Ограничение очереди действий и надёжное масштабирование. Введите ограничения на число действий в очереди и общее число действий, используя динамическое масштабирование и балансировку нагрузки для обработки меняющегося спроса и обеспечения стабильной производительности.
- Обучение устойчивости к состязательным атакам (adversarial robustness training). Обучайте модели обнаруживать и нейтрализовывать состязательные запросы и попытки извлечения.
- Фильтрация глитч-токенов (glitch tokens). Составляйте списки известных глитч-токенов и проверяйте вывод перед добавлением его в контекстное окно модели.
- Контроль доступа. Внедрите строгий контроль доступа, включая ролевую модель доступа (RBAC) и принцип наименьших привилегий, чтобы ограничить несанкционированный доступ к репозиториям моделей LLM и средам обучения.
- Централизованный реестр ML-моделей. Используйте централизованный реестр или каталог ML-моделей, применяемых в промышленной эксплуатации, обеспечивая надлежащее управление и контроль доступа.
- Автоматизированное развёртывание MLOps. Внедрите автоматизированное развёртывание MLOps с процессами управления, отслеживания и согласования, чтобы ужесточить контроль доступа и развёртывания в инфраструктуре.

### Сценарии атак

- Сценарий №1: неконтролируемый размер входных данных. Злоумышленник отправляет приложению LLM, обрабатывающему текстовые данные, необычно большой объём входных данных, что приводит к избыточному использованию памяти и нагрузке на ЦП и потенциально к сбою системы или значительному замедлению сервиса.
- Сценарий №2: повторяющиеся запросы. Злоумышленник отправляет в API LLM большой объём запросов, вызывая избыточное потребление вычислительных ресурсов и делая сервис недоступным для легитимных пользователей.
- Сценарий №3: ресурсоёмкие запросы. Злоумышленник составляет специальные входные данные, рассчитанные на запуск наиболее вычислительно затратных процессов LLM, что приводит к длительной загрузке ЦП и возможному отказу системы.
- Сценарий №4: отказ в оплате (DoW). Злоумышленник генерирует избыточное число операций, эксплуатируя модель оплаты за использование облачных AI-сервисов и создавая для провайдера сервиса непосильные расходы.
- Сценарий №5: функциональное воспроизведение модели. Злоумышленник использует API LLM для генерации синтетических обучающих данных и дообучает другую модель, создавая функциональный эквивалент и обходя ограничения традиционного извлечения модели.
- Сценарий №6: обход фильтрации входных данных системы. Злоумышленник обходит техники фильтрации входных данных и преамбулы LLM, чтобы провести атаку по стороннему каналу и передать сведения о модели на подконтрольный ему удалённый ресурс.