Prompt injection (инъекция промпта) — это атака на LLM-приложение, при которой недоверенный ввод подмешивается к инструкциям, созданным более доверенной стороной, и из-за этого меняет поведение модели. В трактовке NIST ключевая проблема — конкатенация непроверенного ввода и доверенного промпта; OpenAI описывает этот класс как разновидность социальной инженерии для разговорного ИИ.
Если модель читает не только ваш system prompt, но и текст пользователя, внешние документы, веб-страницы, retrieved content или изображения в одном контексте, злоумышленник может встроить туда конкурирующие инструкции. Поэтому prompt injection — не «удачный злой промпт», а риск уровня приложения.
Практический вердикт: если вы подмешиваете внешние данные в контекст LLM, считайте prompt injection угрозой по умолчанию и проектируйте обработку такого ввода как недоверенную.
Английский термин: prompt injection. В классификации MITRE ему соответствует CWE-1427: Improper Neutralization of Input Used for LLM Prompting. В материалах OWASP встречаются варианты direct prompt injection и indirect prompt injection.
Простыми словами
Грубо говоря, вы даёте помощнику два листа бумаги. На первом — ваши правила: «сделай краткое резюме и не отклоняйся от задачи». На втором — текст, который нужно обработать. Если на втором листе кто-то заранее написал «игнорируй прошлые правила и следуй моим», а помощник не умеет отличать данные от команд, он может начать слушаться не вас, а содержимое документа.
Именно в этом суть prompt injection: приложение думает, что передаёт модели «данные для обработки», а модель видит просто ещё один кусок текста с инструкциями. Для человека граница очевидна, для системы — нет, если эту границу не задать архитектурно и не проверять.
Как это работает
NIST определяет prompt injection как атаку, которая эксплуатирует склейку недоверенного ввода с промптом, созданным более доверенной стороной, например разработчиком приложения. MITRE описывает корневую слабость похожим образом: система не различает пользовательский ввод и директивы разработчика.
[Инструкции разработчика / system prompt] (доверенный слой)
+
[Пользовательский или внешний контент] (недоверенный слой)
|
склейка в один общий prompt
|
модель читает всё как текст
|
вредоносные инструкции конкурируют с доверенными
|
приложение получает ответ с искажённым поведением- Разработчик задаёт доверенные инструкции: роль, правила, ограничения.
- Приложение добавляет недоверенный текст: пользовательский ввод, документ, страницу, retrieved content или другой внешний материал.
- Модель интерпретирует весь контекст как последовательность токенов и не знает сама по себе, какой кусок текста «данные», а какой — «команда».
- Атакующий внедряет в недоверенный слой новые инструкции, которые пытаются изменить поведение модели.
OWASP в своём cheat sheet рассматривает несколько связанных вариантов: прямую инъекцию, косвенную инъекцию, мультимодальную инъекцию и сценарии вокруг RAG poisoning. Термин indirect prompt injection закрепился после работы 2023 года Not what you’ve signed up for, где авторы показали компрометацию реальных LLM-интегрированных приложений через внешний контент.
OpenAI подчёркивает ещё один важный угол зрения: это социальная инженерия, но направленная уже не на человека, а на разговорный ИИ. Вредоносная инструкция маскируется под обычный контент и пользуется тем, что модель читает контекст линейно.
Где применяется
- Чат-интерфейсы с пользовательским вводом. Самый простой случай — прямая инъекция, когда атакующий пишет вредоносные инструкции прямо в поле запроса.
- RAG-системы. Когда приложение добавляет в prompt найденные фрагменты из базы знаний, поиска или других источников, риск переносится на retrieved content.
- Приложения, которые читают внешние документы и страницы. Это типичный сценарий косвенной инъекции: вредоносный текст живёт не в запросе пользователя, а во внешнем материале, который потом попадает в контекст.
- Мультимодальные пайплайны. OWASP отдельно выделяет мультимодальную инъекцию, где вредоносные инструкции могут приходить через контент другого типа, например через изображение с текстом.
Для практиков важно, что это не нишевая тема. В текущем релизе OWASP GenAI LLM Top 10 2026 prompt injection вынесен как отдельный риск, а в OWASP LLMSVS v2.0 появились требования сканировать prompts и completions на prompt injection и обращаться с ними как с недоверенным вводом.
Практический пример
Ниже — упрощённый сценарий, который показывает, где возникает уязвимость. Это не код из конкретного SDK, а схема, иллюстрирующая определение NIST и требования OWASP/LLMSVS.
Уязвимая схема
# Доверенные инструкции разработчика
system_instructions = "Сделай краткое резюме документа"
# Недоверенный внешний контент
external_doc = load_document()
# Пользовательская задача
user_task = "Ответь кратко"
# Ошибка: всё склеивается в один prompt без отдельной проверки
prompt = system_instructions + "nn" + external_doc + "nn" + user_task
answer = llm(prompt)Если внутри external_doc окажется текст вроде «игнорируй предыдущие указания и следуй моим», модель увидит его как часть общего контекста. Именно такую архитектурную проблему и описывают NIST и MITRE.
Более безопасная схема
system_instructions = "Сделай краткое резюме документа"
external_doc = load_document() # всегда считать недоверенным
user_task = "Ответь кратко"
if scan_for_prompt_injection(external_doc):
reject_or_review(external_doc)
prompt = build_prompt(system_instructions, external_doc, user_task)
answer = llm(prompt)
if scan_for_prompt_injection(answer):
block_or_review(answer)Что здесь важно с точки зрения источников:
- OWASP рекомендует думать о prompt injection как о полноценной уязвимости и проверять защиту тестами, ориентированными на верификацию.
- LLMSVS v2.0 требует сканировать не только входной prompt, но и completion.
- Недоверенный контент нужно считать недоверенным независимо от того, пришёл он от пользователя напрямую или через внешнюю систему.
Если вы отдельно настраиваете доверенный слой инструкций, пригодится материал Как составить system prompt. Для наблюдаемости и учёта промптов в командах разработки часто смотрят на PromptLayer — prompt registry, observability и evals для LLM-приложений.
Чем отличается от близких терминов
| Термин | Что это | Где появляется вредоносный текст | Практический смысл |
|---|---|---|---|
| Prompt injection | Зонтичный класс атак на склейку доверенных и недоверенных инструкций | В любом недоверенном слое контекста | Общая категория риска |
| Direct prompt injection | Прямая инъекция | Обычно прямо в пользовательском вводе | Проще тестировать, но нельзя считать единственным сценарием |
| Indirect prompt injection | Косвенная инъекция | Во внешнем документе, странице или другом контенте, который приложение само подмешивает в prompt | Особенно важна для RAG и интеграций с внешними источниками |
| RAG poisoning | Связанный риск для retrieval-augmented generation | В источнике данных или retrieved content, который затем участвует в генерации | Не тождественен prompt injection, но тесно связан с ним в OWASP-материалах |
Отдельно не стоит путать уязвимость prompt injection с обычной работой над подсказками. Для этого полезно развести в голове защиту и техники prompt engineering, например Prompt tuning (мягкий промпт) или Negative prompt (негативный промпт).
Ограничения и заблуждения
- Заблуждение: «это проблема только чат-ботов». Нет. NIST, MITRE и OWASP описывают prompt injection как риск именно для LLM-приложений, особенно когда приложение смешивает данные из разных уровней доверия.
- Заблуждение: «достаточно написать более строгий system prompt». CWE-1427 указывает на архитектурную слабость: система не различает ввод пользователя и директивы разработчика. Одного текста с правилами недостаточно, если недоверенный контент всё равно попадает в общий контекст без проверок.
- Заблуждение: «опасна только прямая атака в поле ввода». Работа 2023 года про indirect prompt injection показала, что вредоносные инструкции могут приходить через внешний контент, который сам пользователь может даже не видеть как «атаку».
- Ограничение практики: OWASP ведёт несколько связанных артефактов по теме — cheat sheet, GenAI LLM Top 10 и LLMSVS. Термины и нумерация между ними могут различаться, хотя базовый риск совпадает.
- Ограничение этой статьи: в проверенном пакете источников нет единого официального числа, которое можно честно назвать «процентом защиты» от prompt injection. Поэтому здесь нет обещаний вида «этот приём решает проблему полностью».
Редакционная оговорка: часть официальных страниц из пакета источников не показывает явно дату последнего обновления. Текст сверён по доступному содержимому на 2026-08-16.
Связанные материалы на COMRAD404
- Как составить system prompt — чтобы понять, где проходит доверенный слой инструкций.
- Prompt tuning (мягкий промпт) — чтобы не путать настройку поведения модели с уязвимостью.
- Negative prompt (негативный промпт) — соседний термин из prompt engineering, но не механизм защиты от инъекции.
- PromptLayer — prompt registry, observability и evals для LLM-приложений — инструментальный контекст для аудита промптов и проверок.
Источники
- prompt injection – Glossary | CSRC
- AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations | CSRC
- Understanding prompt injections | OpenAI
- LLM Prompt Injection Prevention – OWASP Cheat Sheet Series
- OWASP Top 10 for Large Language Model Applications | OWASP Foundation
- LLMSVS v2.0 — OWASP Large Language Model Security Verification Standard (LLMSVS)
- CWE – CWE-1427: Improper Neutralization of Input Used for LLM Prompting (4.20)
- Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection
Вопросы и ответы
Что такое прямая и косвенная инъекция промпта?
Прямая инъекция попадает в систему через явный пользовательский ввод. Косвенная — через внешний контент, который приложение позже само добавляет в prompt; именно этот сценарий подробно выделен в работе 2023 года про indirect prompt injection.
Почему хороший system prompt не решает проблему сам по себе?
Потому что MITRE CWE-1427 описывает корневую слабость как неспособность различать директивы разработчика и пользовательский или внешний ввод. Если оба слоя смешаны в одном контексте, одного набора правил недостаточно: нужны проверки и обращение с таким вводом как с недоверенным.
Связан ли prompt injection с RAG?
Да. OWASP рассматривает RAG poisoning рядом с prompt injection, потому что retrieved content тоже попадает в контекст модели. Но это не одно и то же: prompt injection — это внедрение управляющих инструкций в контекст, а RAG poisoning касается компрометации источника данных, из которого этот контент берётся.
Нужно ли проверять только входные данные?
Нет. OWASP LLMSVS v2.0 требует сканировать и prompts, и completions на prompt injection и обращаться с ними как с недоверенным вводом. На практике это означает проверку не только того, что вы отправляете модели, но и того, что получаете обратно.