Prompt injection, или инъекция вредоносной инструкции, возникает, когда ИИ-система принимает внешний текст, документ, письмо, веб-страницу или другой контент за команду и начинает действовать вопреки цели пользователя или компании. Атака может изменить ответ, раскрыть конфиденциальные данные, повлиять на решение или заставить ИИ-агента неправомерно использовать подключённые инструменты.
Проблему нельзя решить одним «более строгим» системным промптом. Нужна многоуровневая защита: недоверенный контент отделяют от инструкций, модели дают минимальные права, вызовы инструментов проверяет детерминированный код, значимые действия требуют подтверждения человека, а поведение системы регулярно тестируется и контролируется.
Что такое prompt injection
Большая языковая модель получает в одном контексте информацию из разных источников: системные правила, запрос пользователя, историю диалога, результаты поиска, документы из RAG и ответы инструментов. Человек понимает, что текст письма — это данные, а не команда читающему письмо. Для модели граница менее надёжна, потому что и правила, и контент обычно выражены на естественном языке.
OWASP LLM01:2025 определяет prompt injection как ввод, который непредусмотренно меняет поведение модели или её результат. Вредоносная инструкция может быть видимой или скрытой в контенте, который модель умеет обрабатывать. RAG и дополнительное обучение способны повысить релевантность ответов, но сами по себе не устраняют уязвимость.
Prompt injection отличается от SQL injection и инъекции команд. При традиционной инъекции вредоносная строка интерпретируется как команда базы данных или операционной системы. Prompt injection сначала влияет на решение модели. Опасные последствия появляются, когда приложение доверяет этому решению и без достаточной проверки передаёт его базе данных, API, почтовому сервису, файловой системе или другому инструменту.
Прямая и косвенная инъекция
| Тип | Как вредоносный контент попадает в систему | Типичный пример |
| Прямая prompt injection | Атакующий пишет непосредственно в интерфейс ИИ или API-ввод | Клиент пытается заставить ассистента поддержки проигнорировать правила и раскрыть данные другого клиента |
| Косвенная prompt injection | ИИ читает внешний контент под контролем атакующего | Агент обрабатывает письмо, PDF, веб-страницу или RAG-документ со скрытой вредоносной инструкцией |
| Мультимодальная инъекция | Инструкция встроена в изображение, слой документа или другой формат данных | Модель анализирует изображение с содержимым, которое трудно заметить человеку и которое пытается изменить задачу |
Прямую атаку обычно проще связать с конкретным пользователем и запросом. Косвенную обнаружить сложнее, потому что враждебный ввод может принести в систему добросовестный сотрудник. Он просит обработать документ поставщика или входящее письмо, не зная, что внутри находится команда для ИИ-агента.
Jailbreak — близкое понятие, но обычно означает попытку обойти ограничения безопасности самого поставщика модели. Для корпоративной оценки полезнее более широкий вопрос: способен ли недоверенный ввод изменить предусмотренный процесс приложения, получить доступ к данным или вызвать действие в другой системе?
Как атака превращается в бизнес-инцидент
Для успешной атаки обычно нужна цепочка слабых мер контроля, а не одна ошибка.
Недоверенный контент попадает в контекст ИИ. Источником может быть пользователь, публичный сайт, письмо, загруженный файл, комментарий клиента или база знаний RAG.
Модель интерпретирует контент как инструкцию. Вредоносный текст конкурирует с системными правилами и настоящей задачей пользователя.
Модели доступны ценные данные или инструменты. Она может читать CRM, искать документы, инициировать платёж, отправлять письмо или менять запись.
Приложение доверяет результату модели. Вызов инструмента, ссылка, SQL-фрагмент или адресат сообщения не проходят независимую проверку.
Действие выполняется без содержательного подтверждения. Последствия выходят за пределы чата: данные раскрыты, запись изменена, сообщение отправлено или решение искажено.
Тяжесть риска определяется сочетанием четырёх факторов: объёмом недоверенного ввода, чувствительностью доступных данных, полномочиями агента и отсутствием независимых проверок. Чат-бот, который отвечает только на основе публичных данных и ничего не меняет, относится к другой категории риска, чем агент с доступом к почте, документам и платежам.
Где корпоративный риск особенно высок
RAG-ассистенты и внутренние базы знаний
Retrieval-augmented generation находит релевантные фрагменты документов и добавляет их в контекст до подготовки ответа. Если в базу знаний могут попасть внешние файлы, неконтролируемые комментарии или непроверенный импорт, атакующий способен вставить инструкцию в источник, который позже будет найден по внешне несвязанному запросу.
Сам факт поиска не делает документ доверенным. Система должна сохранять идентичность источника, уровень доступа и статус доверия, а при создании ответа соблюдать те же права пользователя, что и исходное хранилище.
Агенты для почты, документов и веб-доступа
Такие агенты по своей природе читают контент, контролируемый третьими лицами. Враждебная инструкция может находиться в теле письма, приложении, метаданных документа или на веб-странице. Если тот же агент умеет искать другие файлы и отправлять сообщения, косвенная инъекция получает путь от недоверенного ввода к чувствительному действию.
Поддержка клиентов и самообслуживание
Публичного ассистента может систематически проверять любой человек. Риск растёт, если он видит профили клиентов, заказы или скидки и способен менять состояние учётной записи. Авторизацию нельзя передавать модели: каждый запрос данных и каждое действие сервер проверяет по реальной личности и правам пользователя.
Автоматическая оценка документов
ИИ может классифицировать резюме, счета, договоры, предложения для закупок и обращения клиентов. Инструкция внутри документа может попытаться изменить оценку, приоритет или резюме. В таком процессе содержимое документа — материал для анализа, а не доверенная постановка задачи.
Почему системного промпта и фильтра недостаточно
Системный промпт полезен для определения поведения, но не является границей безопасности. Атакующий может изменить формулировку, разделить инструкцию на части, использовать другой язык или спрятать её в ином формате. Чёрный список распознаёт известные фразы, а не вредоносное намерение.
Отдельная защитная модель или классификатор тоже может ошибиться. Она снижает число атак, но не должна быть единственным барьером перед значимым действием. Безопасная архитектура исходит из того, что часть вредоносных вводов достигнет основной модели, а некоторые опасные результаты пройдут через фильтр.
В системном промпте нельзя хранить API-ключи, пароли и другие секреты. Инструкции помогают управлять процессом, но их конфиденциальность не равна защищённому хранилищу секретов. Учётные данные должны храниться в специальной системе, а инструмент вызывает только серверный код после проверки прав. Даже знание структуры системной инструкции не должно давать атакующему дополнительный доступ.
Это подтверждают актуальные исследования захвата ИИ-агентов. Анализ NIST 2026 года охватил более 250 000 попыток атак на 13 передовых моделей; для каждой целевой модели нашли хотя бы одну успешную атаку. Практический вывод не в том, что ИИ нельзя использовать, а в том, что устойчивость модели нельзя считать безопасностью всей системы.
Защищайте всю систему, а не только модель
1. Создайте модель угроз
Перечислите источники контента, данные, доступные модели, инструменты, которые она может вызвать, и худший реалистичный исход. Отдельно отметьте публичный, партнёрский, внутренний и системный контент. «Внутренний документ» не означает «доверенная инструкция» автоматически.
2. Отделите инструкции от данных
Маркируйте внешний контент как недоверенный и помещайте его в чётко ограниченное поле данных, а не соединяйте одной строкой с системными правилами. Укажите модели, что команды внутри документа выполнять нельзя. Эта мера снижает риск, но не заменяет ограничения прав и инструментов.
3. Соблюдайте принцип минимальных привилегий
Агент должен получать только данные и функции, необходимые для конкретной задачи. Для подготовки резюме писем ему не нужны права на отправку сообщений или открытие финансовой папки. Используйте отдельные, краткоживущие и узко ограниченные токены вместо полной сессии сотрудника.
Ещё безопаснее разделить агентов чтения и записи. Первый готовит структурированное предложение, второй получает только проверенную команду с конкретными параметрами.
4. Проверяйте вызовы инструментов вне модели
Модель может предложить действие, но авторизацию выполняет обычный код приложения. Сервер проверяет пользователя, разрешённую функцию, объект данных, адресата, сумму, домен и другие бизнес-правила. Вместо свободного текста применяйте строгую схему с разрешёнными значениями, ограничениями длины и безопасными настройками по умолчанию.
Сгенерированные ИИ SQL, команды, HTML, URL или фрагменты кода нельзя автоматически исполнять без подходящей контексту проверки и изоляции. Ответ модели — недоверенный ввод для следующего компонента.
5. Требуйте подтверждение для значимых действий
Экран подтверждения должен показывать конкретное действие, адресата, используемые данные и необратимые последствия. Общая кнопка «Продолжить» создаёт только иллюзию контроля. Платежи, удаление данных, изменение прав, отправка внешних сообщений и передача конфиденциальных файлов не должны выполняться автономно.
6. Ограничьте среду выполнения и вывод данных
Запускайте код и обработку файлов в изолированной среде с лимитами ресурсов, сети и файловой системы. Разрешайте соединения только с необходимыми доменами и блокируйте произвольные внешние URL. Даже если атака повлияла на модель, изоляция уменьшит возможность достичь чувствительных ресурсов или вывести данные наружу.
7. Проверяйте итоговый результат
До передачи ответа пользователю или другой системе проверяйте признаки утечки, неразрешённые ссылки, неправильный формат, персональные данные и отклонение от задачи. В структурированных процессах сравнивайте результат с источниками и бизнес-правилами. Классификация или резюме должны оставаться прослеживаемыми до использованных документов.
Журналы, мониторинг и реагирование
Без журналов компания может увидеть неправильный результат, но не понять, какой контент, модель, инструмент и доступ его вызвали. Регистрируйте идентификатор запроса, источники ввода, найденные документы, решения политик, вызовы инструментов, подтверждения, ошибки и итоговый статус. Чувствительные значения маскируйте, а доступ к журналам ограничивайте.
Оповещения могут выявлять необычные вызовы инструментов, повторные блокировки, доступ к неожиданным категориям данных, новые внешние домены и резкие изменения поведения. Компания должна уметь быстро отключить инструмент, отозвать полномочия агента, изолировать источник документов и сохранить доказательства.
План реагирования определяет, кто может приостановить функцию ИИ, кто оценивает возможную утечку, как информируются ответственные и как проводится повторная проверка после исправления.
Red-teaming и регрессионные тесты
Защита от prompt injection — не разовый аудит. Меняются модели, системные промпты, документы RAG, интеграции и методы атакующих. До запуска и после значимых изменений выполняйте сценарии атак, соответствующие реальным источникам данных и инструментам компании.
Набор тестов должен охватывать прямые попытки обойти правила, инструкции во внешних документах, ввод, разделённый на части, другие языки, некорректные параметры инструментов, запросы запрещённых данных и попытки вызвать внешнее действие без подтверждения. Оценивайте не только текст модели. Проверяйте, заблокирован ли инструмент, защищены ли данные, создан ли журнал и корректно ли уведомлён пользователь.
Сохраняйте неудачные атаки и успешно заблокированные случаи как регрессионные тесты. Смена модели или промпта не должна незаметно убрать работающую защиту.
Что спросить у поставщика ИИ-решения
Компании недостаточно информации о точности модели. Поставщик должен объяснить:
как разделяется системный, пользовательский и внешний контент;
какие права есть у аккаунта агента и можно ли ограничить их по функциям;
какие действия всегда требуют подтверждения;
как проверяются параметры инструментов и результаты модели;
какие журналы, оповещения и механизмы аварийного отключения доступны;
как проводятся тесты prompt injection и обновления безопасности;
как компания может расследовать инцидент и экспортировать доказательства.
Ответа «в модели есть фильтры безопасности» недостаточно, если система видит конфиденциальные данные или способна действовать.
Практическая последовательность внедрения
Начните с одного чётко ограниченного процесса в режиме чтения. Проведите инвентаризацию источников данных, обозначьте недоверенный контент и составьте матрицу прав. Затем внедрите серверные политики, структурированную проверку вызовов инструментов, журналы и тесты атак. Возможность записи и внешней коммуникации добавляйте только после появления подтверждений, изоляции и механизма экстренной остановки.
Полезен простой фильтр решения: если компания не умеет безопасно ограничить худшее действие, которое способен выполнить скомпрометированный агент, это действие пока должно оставаться под контролем человека.
Заключение
Prompt injection использует неспособность ИИ-систем всегда надёжно отделять инструкции от данных. Атака становится опасной, когда модель получает широкий контекст, чувствительные данные и право действовать, а окружающее приложение доверяет её результату без независимой проверки.
Цель безопасности — не обещать, что модель никогда не удастся обмануть. Нужно сделать так, чтобы обманутая модель не могла выйти за границы доступа, выполнить неразрешённое действие или незаметно вывести данные. Поэтому безопасная автоматизация бизнес-процессов начинается с прав, потоков данных, валидации и контрольных точек, а не только с выбора модели.