Промпт-инъекция (prompt injection): что это, виды и как защититься

Дословное определение OWASP: «A Prompt Injection Vulnerability occurs when user prompts alter the LLM's behavior or output in unintended ways» — уязвимость промпт-инъекции возникает, когда пользовательские промпты меняют поведение или вывод LLM непредусмотренным образом. Источник — карточка LLM01:2025 на genai.owasp.org.

Промпт-инъекция в ИИ — это не баг конкретного продукта, а системное свойство архитектуры LLM: модель обрабатывает системные инструкции разработчика и текст, пришедший от пользователя или из внешнего источника, в одном общем потоке токенов. Формальный код в классификации OWASP Top 10 for LLM Applications 2025 — LLM01:2025, первая позиция рейтинга.

У классических инъекций — SQL, XSS — есть чёткая граница между кодом и данными: интерпретатор знает, что обрабатывать как команду, а что как строку. У языковой модели такой границы нет. Системный промпт разработчика, история диалога, документ, который модель суммирует, и сообщение пользователя — всё это на входе превращается в один текстовый контекст без встроенной разметки «это инструкция, а это данные».

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

OWASP разделяет два базовых сценария по тому, откуда приходит вредоносная инструкция.

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

Помимо базового деления на direct и indirect, OWASP перечисляет ещё три технических варианта, которые встречаются на практике как усложнённые формы обеих категорий.

↔ таблицу можно прокрутить вбок

• Утечка системного промпта. Атакующий формулирует запрос так, что модель дословно выводит свои скрытые инструкции. Категория пересекается с отдельным пунктом OWASP LLM07:2025 System Prompt Leakage и остаётся частым, хорошо документированным классом инцидентов у публичных чат-ботов.
• Обход инструкций чат-бота поддержки. Инъекция в диалоге заставляет бота выйти за пределы заданной роли — например, давать скидки или обещания, не предусмотренные политикой компании. Это классический прикладной пример из карточки OWASP.
• Indirect через агента-браузера. Скрытые инструкции на веб-страницах, которые обрабатывает ИИ-агент, меняют его поведение без ведома пользователя — сценарий описан выше в разделе про direct/indirect.

Это самая частая путаница в текстах про безопасность ИИ, и её стоит разобрать явно.

↔ таблицу можно прокрутить вбок

Техники нередко пересекаются — один и тот же промпт может одновременно быть и джейлбрейком, и инъекцией, — но модели угроз разные: у prompt injection цель узкая и прикладная (конкретное поведение конкретного продукта), у jailbreak — снять ограничения самой модели вне контекста приложения. Подробный разбор техник джейлбрейка (DAN, many-shot jailbreaking, Crescendo) и отдельная защита от него — в статье «Джейлбрейк нейросетей: техники и защита».

Полностью устранить промпт-инъекцию на текущем уровне архитектур LLM нельзя — причина в том, что модель не разделяет код и данные на уровне токенов, а не в качестве конкретной реализации. OWASP формулирует это не как «лечение», а как набор мер, снижающих риск и последствия. Дословный перечень из семи пунктов с карточки LLM01:2025:

• Ограничение поведения модели через системные промпты с чёткими рамками возможностей и контекста.
• Валидация формата вывода — ожидаемая структура ответа, требование указывать источники.
• Input/output-фильтрация — семантические фильтры и правила валидации контента.
• Least-privilege — минимально необходимые права модели или агента на выполнение функций.
• Human-in-the-loop для высокорисковых действий.
• Сегрегация и явная маркировка недоверенного внешнего контента — отделение «инструкций» от «данных».
• Регулярное adversarial-тестирование и пентест границ доверия.

На практике эти меры на уровне приложения реализует отдельный класс защитных решений — AI firewall / LLM guardrails: прокси-слой между приложением и LLM-провайдером, который детектирует паттерны промпт-инъекций и джейлбрейка на входе, маскирует чувствительные данные до отправки во внешнюю модель и контролирует вызовы инструментов агентом. Разбор российских продуктов этого класса — на хабе «Безопасность ИИ».

Смежный организационный угол — требования регулятора к защите при использовании ИИ в России, в том числе методический документ ФСТЭК с разделом про обеспечение защиты информации при применении искусственного интеллекта: подробнее — в материале «Регулирование ИИ в России».