Содержание статьи
- Что такое Prompt Injection
- Как работает Prompt Injection: пример атаки
- Чем Prompt Injection опасен для бизнеса
- Как защитить ИИ-агентов от Prompt Injection
- Почему безопасность ИИ — это больше, чем защита промпта
Представьте: ваша компания внедрила ИИ-ассистента, который помогает сотрудникам работать с документами, искать информацию во внутренних базах и готовить ответы клиентам. Он экономит время, разгружает команду и выполняет задачи, на которые раньше уходили часы.
Но что, если однажды ассистент прочитает документ с инструкцией, которой не должно быть, и воспримет её как команду к действию?
Это не сюжет фантастического фильма, а один из сценариев атак на системы искусственного интеллекта. Он называется Prompt Injection — инъекция промпта.
Пока ИИ только отвечает на вопросы, последствия такой атаки могут ограничиваться неверным или нежелательным ответом. Но если модель подключена к корпоративным данным, почте, CRM или другим инструментам, последствия могут оказаться гораздо серьёзнее.
Разберёмся, как работает Prompt Injection, какие риски он создаёт для бизнеса и что можно сделать, чтобы их снизить.
Что такое Prompt Injection и почему это важно
Языковая модель (LLM) обрабатывает текстовые инструкции и на их основе формирует ответ. Разработчики задают ей роль, ограничения и правила работы — например, разрешают отвечать на вопросы по внутренней базе знаний, но запрещают раскрывать персональные данные.
Prompt Injection — это атака, при которой специально сформированный ввод меняет поведение модели вопреки задуманным правилам. Модель может проигнорировать часть инструкций, раскрыть лишнюю информацию или повлиять на работу подключённых инструментов.
OWASP — международный проект, который разрабатывает рекомендации по безопасности приложений, — поставил Prompt Injection на первое место в своём Top 10 рисков для приложений на основе больших языковых моделей в версии 2025 года. Это не означает, что любая ИИ-система уязвима или обязательно будет взломана. Но проблема настолько существенна, что её нельзя оставлять за пределами модели угроз.
Как работает Prompt Injection: от «бабушки» до атаки на ИИ-агента
У Prompt Injection есть два основных сценария:
- Прямая инъекция. Злоумышленник сам вводит текст, пытаясь заставить модель нарушить заданные ограничения.
- Косвенная инъекция. Модель получает вредоносные инструкции из внешнего источника — например, веб-страницы, письма или загруженного документа, который она должна обработать.
Второй вариант особенно интересен с точки зрения корпоративной безопасности: пользователю не обязательно самостоятельно вводить вредоносную команду. Достаточно, чтобы ИИ обработал подготовленный злоумышленником материал.
Как работает Prompt Injection: пример с «бабушкой»
Один из известных примеров обхода ограничений языковых моделей — так называемый DAN и другие техники jailbreak, в том числе сценарий с «бабушкой».
Пользователь просит модель представить, что она — его покойная бабушка, которая работала инженером-химиком и рассказывала внуку перед сном о производстве xxxxx. Затем просит продолжить эту историю.
В таком сценарии запрос пытается использовать сразу несколько особенностей поведения модели: склонность следовать заданной роли, поддерживать эмоциональный контекст и продолжать историю. Цель — добиться ответа, который модель в обычной ситуации должна была бы отклонить.
Почему это может сработать? Языковая модель не рассуждает о правилах и намерениях точно так же, как человек. Она обрабатывает инструкции и контекст, а её защитные механизмы не всегда одинаково устойчивы к разным формулировкам.
При этом важно понимать: пример с «бабушкой» иллюстрирует прежде всего jailbreak — попытку обойти ограничения модели через запрос. В корпоративных системах проблема может выглядеть менее очевидно и быть значительно опаснее.
Представим другой сценарий
Компания использует ИИ-ассистента, который анализирует входящие документы и готовит для сотрудников краткие сводки. Злоумышленник размещает на веб-странице или в документе скрытые от обычного читателя инструкции, рассчитанные на обработку моделью. Например, пытается заставить её раскрыть содержимое доступного ей контекста или изменить результат анализа.
Сотрудник загружает документ в ассистента. Модель обрабатывает не только полезную информацию, но и внедрённые инструкции. Если архитектура системы не предусматривает достаточных ограничений, ассистент может выполнить нежелательное действие или выдать информацию, которую не должен был раскрывать.
Здесь атакуют не столько саму модель, сколько всю систему, в которой она работает. Именно поэтому безопасность ИИ нельзя свести к настройке одного промпта.
Какие риски Prompt Injection создаёт для бизнеса
Последствия атаки зависят от того, какие данные доступны модели, какие действия ей разрешены и как устроена система вокруг неё.
Рассмотрим несколько возможных рисков.
Утечка конфиденциальной информации. Если ассистент имеет доступ к внутренним документам, переписке, клиентским данным или коммерческой информации, злоумышленник может попытаться добиться их раскрытия. Особенно опасны системы, в которых права доступа модели шире, чем права конкретного пользователя.
Ошибочные решения. ИИ может сформировать и передать сотруднику искажённую сводку, изменить приоритеты или выдать недостоверную информацию. Если результат используется без проверки в юридических, финансовых или операционных процессах, ошибка может повлиять на реальные бизнес-решения.
Нежелательные действия от имени пользователя. ИИ-агенты могут не только генерировать текст, но и обращаться к API, создавать заявки, отправлять сообщения, изменять записи в системах. Если агенту предоставлены избыточные полномочия, успешная атака может привести к действиям, которые никто не планировал.
Нарушение работы процессов. Манипуляция результатами может повлиять на обработку обращений, работу поддержки, поиск информации или автоматизированные цепочки действий. В зависимости от архитектуры это способно привести к дополнительным затратам, простоям и потере доверия пользователей.
Важно: наличие Prompt Injection не означает, что любой из этих сценариев обязательно реализуем. Риск определяется конкретной системой — её архитектурой, интеграциями, правами доступа и защитными механизмами.
Иными словами, один и тот же недостаток поведения модели может быть относительно безобидным в публичном чат-боте и критичным в агенте, который работает с внутренними системами компании.
Как защитить ИИ-агента от Prompt Injection
Универсальной настройки, которая гарантированно исключит Prompt Injection, сегодня нет. OWASP отдельно отмечает, что полностью надёжное предотвращение таких атак остаётся сложной задачей. Поэтому защита должна строиться на нескольких уровнях.
- Ограничивайте права ИИ-агента.
- Разделяйте инструкции и недоверенные данные.
- Проверяйте действия модели, а не только её ответы.
- Защищайте данные и интеграции.
- Тестируйте систему на реальные сценарии атак.
- Повторяйте проверки после изменений.
Модель должна иметь доступ только к тем данным и инструментам, которые действительно нужны для её задачи. Если ассистенту достаточно читать документы, ему не следует давать возможность изменять их или отправлять наружу. Используйте разграничение доступа, отдельные учётные записи и принцип минимальных привилегий.
Внешние документы, письма и веб-страницы следует рассматривать как потенциально недоверенный ввод, даже если они выглядят безобидно. Важно не только объяснить модели в системных инструкциях, как обращаться с такими материалами, но и реализовать защитные механизмы на уровне приложения.
Если ИИ формирует запрос к API, создаёт заявку, меняет запись или отправляет сообщение, приложение должно проверять допустимость этого действия независимо от решения модели. Для критичных операций необходимы дополнительные подтверждения со стороны человека.
Проверьте, к каким источникам подключена модель, как устроены API, плагины и цепочки обработки данных. Убедитесь, что секреты и ключи доступа не передаются в контекст без необходимости, а доступ к конфиденциальным сведениям контролируется на стороне систем, которые их хранят.
Проверки должны включать прямые и косвенные инъекции, попытки извлечения данных, обход ограничений и манипуляции действиями агента. Важно оценивать не только то, удалось ли получить нежелательный ответ, но и то, к чему он может привести в конкретной архитектуре.
Новая модель, дополнительные интеграции, расширение полномочий агента или изменение бизнес-процесса могут повлиять на безопасность. Поэтому тестирование не должно быть разовой процедурой перед запуском.
Эти меры не делают систему неуязвимой сами по себе. Их задача — снизить вероятность успешной атаки и ограничить последствия, если защиту всё-таки удастся обойти.
Безопасность ИИ начинается не с промпта
Можно написать подробную системную инструкцию, выбрать более устойчивую модель и добавить фильтры. Но если ИИ-агент имеет избыточные права, получает доступ к чувствительным данным и самостоятельно выполняет критичные действия без независимых проверок, одной настройки модели недостаточно.
Поэтому при внедрении ИИ важно смотреть на систему целиком: какие задачи она решает, с какими данными работает, к чему подключена, какие действия может выполнять и кто контролирует результат.
В РАД КОП мы проводим тестирование безопасности языковых моделей (LLM) и агентских систем. Проверяем устойчивость к распространённым атакам, анализируем работу с данными и интеграциями, оцениваем возможные сценарии нарушения безопасности и готовим рекомендации по устранению выявленных проблем.
Результат такой работы — не просто перечень технических замечаний, а понимание того, какие риски существуют именно в вашей системе, чем они могут обернуться для бизнеса и что стоит исправить в первую очередь.
Если вы уже используете ИИ в рабочих процессах или планируете внедрить агентские системы, можно начать с оценки их архитектуры и модели доступа.