SECURITY · 3 июля 2026 г.

Инъекция промпта — не баг, который запатчат

Команды упорно относятся к инъекции промпта как к обычной уязвимости — той, что рано или поздно закроет апдейт модели или хитрый фильтр. Не закроет. Отчёт OWASP 2026 и растущий ряд исследователей теперь описывают её как постоянное свойство того, как работают LLM: модель действительно не отличает твои инструкции от данных, которые читает. Как только это принимаешь, задача меняется. Ты перестаёшь пытаться предотвратить инъекцию и начинаешь делать так, чтобы удавшаяся не могла нанести ущерб, — а это сводится к тому, чтобы ни один агент не держал три силы, превращающие отравленный вход в утечку.

Раз в несколько месяцев по кругу идёт новая защита от инъекции промпта — системный промпт получше, классификатор, ловящий «игнорируй прошлые инструкции», файн-тюн, который якобы послушнее. И раз в несколько месяцев кто-то проходит мимо неё чуть переформулированной атакой. Мы упорно относимся к этому как к багу на пути к патчу. Это не он.

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

Почему это не «чинится»

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

Хватит спрашивать «как не дать модели обмануться?». Считай, что её обманут, каждый раз, и спрашивай: «а до чего этот обман реально дотянется?».

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

Полезная рамка — «смертельная троица» Саймона Уиллисона: инъекция превращается в утечку, только когда у одного агента одновременно есть все три —

доступ к приватным данным (твоя почта, твоя БД, твои файлы),
контакт с недоверенным содержимым (всё, на что может повлиять атакующий, — страница, документ, тикет),
способ отправить данные наружу (HTTP-запрос, письмо, даже рендер картинки по подготовленному URL).

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

Минимум привилегий на инструменты, по задаче. Агент, читающий недоверенное содержимое, не держит заодно ключи от клиентской базы. Ограничивай доступы задачей перед ним, а не всей организацией.
Разорви ногу вывода данных. Агент, глотающий внешний текст, не должен иметь открытого исходящего канала. Никакого произвольного HTTP, только доменный allow-list, никаких тихих подтягиваний картинок по URL от атакующего.
Раздели конвейер. Пусть один компонент суммирует недоверенный документ без доступа к данным и без сети, и передаёт дальше только проверенный результат привилегированному шагу. Два безопасных агента бьют одного смертельного.
Человеческий шлюз на необратимое. Отправка денег, удаление записей, письма клиентам — одобряет человек. Скучный, ограниченный дизайн — тот, что выживает.

Это не гипотетическая сантехника. Отравленная зависимость — бэкдорнутый LLM-шлюз, полежавший на PyPI три часа, десятки тысяч установок — даёт тебе недоверенное содержимое и привилегии одним движением. Троица — это то, как маленькая компрометация становится большой.

Итог

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

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