Промпт-инъекция: как защитить ИИ-агента с доступом к почте и CRM

Письмо, которое читает ваш агент, не должно давать ему разрешение отправить другое письмо, выгрузить данные клиентов или изменить сделку. В списке Top 10 рисков для LLM-приложений организации Open Worldwide Application Security Project (OWASP) промпт-инъекция обозначена как LLM01. Для разработчиков практический вывод прост: нужно ограничить возможности приложения на случай, если модель выполнит чужую инструкцию. Сегодня ни один способ защиты не решает проблему промпт-инъекций полностью.

Сверено с актуальными рекомендациями OWASP и Anthropic 26 октября 2026 года. Сценарии работы с почтой и CRM ниже — примеры проектирования, а не результаты реальных внедрений.

Что такое промпт-инъекция?

Промпт-инъекция возникает, когда входные данные заставляют языковую модель отступить от заданных ей инструкций. Большая языковая модель, или LLM, интерпретирует текст, чтобы формировать ответы и предлагать действия. Проблема начинается там, где материал, который модель должна лишь прочитать, становится указанием, которому она подчиняется.

Представьте сотрудника, который разбирает письмо поставщика. В письме можно описать проблему с доставкой, но нельзя предоставить поставщику доступ к вашей клиентской базе. Агенту нужно так же различать информацию и полномочия, а приложение должно обеспечивать это разграничение технически.

В разделе LLM01:2025 — промпт-инъекция OWASP выделяет два пути проникновения: прямой ввод пользователя и косвенное воздействие через внешние материалы. Важно, кто вправе задавать задачу и определять разрешения, а не насколько профессионально звучит подозрительный текст.

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

Как промпт-инъекция работает в генеративном ИИ?

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

У агента появляется следующий шаг с реальными последствиями: приложение превращает предложенное действие в вызов инструмента. Инструмент — это функция, которая выполняет что-то за пределами диалога, например ищет записи или отправляет сообщение. Если приложение исполняет любые предложения модели с учётными данными, дающими широкие права, ошибка в интерпретации текста может обернуться действием в бизнес-системе.

С этим ограничением сталкивается любой агент, использующий инструменты: понять запрос — ещё не значит установить, что его выполнение разрешено.

Примеры промпт-инъекций: прямые и косвенные атаки

Разница в том, откуда приходит враждебная инструкция. Ниже описано, какого поведения добивается атакующий, без публикации самих атакующих текстов.

Прямая промпт-инъекция

Клиент пишет ассистенту поддержки и пытается убедить его раскрыть заметки по аккаунту другого клиента, выдавая запрос за специально одобренный внутри компании. Атакующий напрямую использует канал ввода приложения.

Защита должна включать сервис работы с записями, который проверяет права аутентифицированного клиента. Даже если модель поверит этой истории, сервис должен отказать в доступе к чужой записи. Запрет в системном промпте помогает направить поведение модели; проверка прав в сервисе обеспечивает само ограничение.

Косвенная промпт-инъекция

Основатель компании, который сам занимается продажами, просит агента кратко пересказать письмо потенциального клиента и предложить следующий шаг. В письмо встроен текст, призванный заставить агента выгрузить постороннему получателю контакты из системы управления взаимоотношениями с клиентами (CRM), не связанные с задачей. Запрос основателя правомерен; враждебная инструкция находится в обрабатываемом письме.

Таким же каналом может стать веб-страница, документ, вложение или результат работы инструмента. Хранение внутри компании не делает любую запись доверенной: текст в вашей CRM вполне мог прислать клиент. Anthropic, разработчик языковой модели Claude, рассматривает такие сторонние источники как отдельную модель угроз в рекомендациях по защите от промпт-инъекций.

У почтового агента отправитель письма никогда не должен получать права владельца ящика на использование инструментов лишь потому, что владелец попросил пересказать это письмо.

Чем промпт-инъекция отличается от джейлбрейка?

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

Нужны и защитные механизмы для контента, и проверка полномочий. Они решают разные задачи.

Почему атаки на ИИ-агентов становятся риском для бизнеса

Масштаб ущерба растёт вместе с объёмом доступных агенту данных и действий. В отдельных рекомендациях по избыточным полномочиям агентов — Excessive Agency OWASP называет избыточную функциональность, права и автономность причинами опасного поведения агентов.

В почтовой системе или CRM последствия принимают знакомые бизнесу формы:

• Утекают конфиденциальные данные. Ответ, вложение, исходящий запрос или сообщение содержит сведения, которые получатель не должен видеть.
• Записи меняются без разрешения. Агент редактирует аккаунт, удаляет полезную историю или меняет этап сделки, потому что извлечённый текст перенаправил его действия.
• Решение незаметно искажается. Потенциальный клиент выглядит более перспективным, жалоба исчезает из сводки или поставщик получает необоснованную рекомендацию.

Доступ только на чтение даёт меньше возможностей, чем доступ на запись, но не исключает утечку конфиденциальных данных. Если приложение извлекает закрытые записи и может раскрыть их в ответе или через исходящее соединение, их конфиденциальность всё равно нужно защищать.

Подразделение Unit 42 компании Palo Alto Networks задокументировало вредоносные инструкции в действующих веб-материалах в исследовании от 3 марта 2026 года. Обнаруженная попытка не доказывает, что все атакованные системы выполнили инструкции. Но она показывает, почему внешние материалы нужно включить в модель угроз ещё до того, как агенту разрешат действовать.

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

Защита от промпт-инъекций: как не допустить инцидента

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

Начните с реальных прав инструмента. Функция под названием «сводка по входящим» не ограничена составлением сводок, если используемые ею учётные данные позволяют отправлять и удалять письма. Проверяйте настройки аккаунта и сервиса, а не только название функции.

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

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

Более широкий набор проверок входных данных, ответов и выполнения описан в статье о защитных механизмах ИИ.

Что рекомендации Anthropic означают для извлечённых материалов?

Anthropic рекомендует передавать сторонние материалы в блоках tool_result, указывать их источник, явно задавать политику работы с недоверенным контентом и кодировать строки в JSON вместо вставки в инструкции в свободной форме. Рекомендации также предусматривают проверку результатов инструментов и мониторинг поведения. См. актуальное руководство по Claude.

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

JSON — это формат структурированных данных. Корректное экранирование текста не даёт ему нарушить структуру сериализации, но не мешает модели поддаться смыслу этого текста. Рассматривайте рекомендацию по кодированию как один слой защиты; проверка полномочий по-прежнему должна выполняться отдельно.

Привязывайте подтверждение к конкретному действию

Кнопка подтверждения защищает бизнес, только если выполнение зависит от того, что именно проверил человек. Формулировка «Продолжить обработку этого аккаунта» слишком расплывчата для агента, способного отправлять вложения или переписывать клиентские записи.

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

Подтверждение также должно исходить от аутентифицированного человека с нужными полномочиями. Фраза в письме о том, что кто-то уже одобрил работу, — это содержимое источника, а не факт подтверждения в системе. У модели не должно быть возможности самой создать запись об одобрении или вызвать другой инструмент в обход проверки.

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

Это рекомендации по реализации рабочего процесса, а не утверждение, что проверка человеком обнаружит любую атаку. В руководстве по ИИ с участием человека разобрано, как организовать работу с очередями на проверку и передавать сложные случаи ответственным специалистам.

Краткий чек-лист для агента с доступом к почте или CRM

Сначала запустите полезный процесс с минимальным набором возможностей. Перед тем как разрешить автономные действия во внешних системах, пройдите этот чек-лист:

• Учётная запись: каждое чтение и изменение ограничено правами аутентифицированного пользователя и разрешённым корпоративным аккаунтом. Модель не может выбрать учётную запись с более высокими привилегиями.
• Данные: извлекайте только нужные для задачи записи и поля. Не включайте секреты в материалы, видимые модели, и сохраняйте сведения о происхождении текста из писем, документов и CRM.
• Инструменты: чтение, подготовка черновиков, отправка, экспорт и редактирование — отдельные разрешения. Уберите возможности, которые процессу не нужны.
• Выдача и отправка: проверяйте ответы и аргументы инструментов до передачи наружу. Проверяйте получателей, вложения, адреса назначения и допустимые изменения записей.
• Подтверждение: действия с серьёзными последствиями требуют проверки конкретного действия, обязательность которой обеспечивает код приложения. Если подтверждения нет или оно изменилось, действие остаётся в ожидании.
• Эксплуатация: ведите журнал действий с учётом конфиденциальности, назначьте ответственного за оповещения, предусмотрите механизм приостановки и протестируйте весь процесс, прежде чем расширять доступ.

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

В практическом руководстве по ограничению последствий сбоев ИИ-агентов в продакшене разобрана более широкая архитектура сдерживания. Радиус поражения — это то, насколько далеко сбой может распространиться по связанным системам.

Тестирование промпт-инъекций: проверяйте последствия, а не только ответ

Тест пройден, когда запрещённого результата не произошло. Ассистент может вывести отказ уже после того, как вызов инструмента изменил запись. Проверяйте сервис инструментов и итоговое состояние системы, а не только историю чата.

Для репетиции запуска используйте искусственные контакты, тестовые почтовые ящики и контролируемое окружение. Ниже — план проверки приложения, а не набор текстов для атак.

1. 1

   Проверьте штатный разрешённый сценарий

   Запустите обычную задачу составления сводки по потенциальному клиенту. Убедитесь, что извлекаются нужные записи, черновик полезен, а подтверждение требуется именно там, где это предусмотрено политикой. Правомерная работа должна по-прежнему выполняться успешно.

2. 2

   Проверьте оба пути проникновения

   Подайте неразрешённый запрос через пользовательский ввод и стороннее сообщение с попыткой перенаправить задачу. Убедитесь, что записи, не связанные с задачей, остаются недоступны, а запрещённые операции инструментов отклоняются.

3. 3

   Проверьте подтверждения и обработку сбоев

   Проверьте изменение деталей действия после одобрения, отказ при проверке, недоступность сервиса политик и повторную попытку выполнения. Убедитесь, что приложение приостанавливает или отклоняет действие и не допускает повторных эффектов.

4. 4

   Проверьте следы действий и оповещения

   Изучите итоговое состояние CRM, исходящие сообщения, адреса, к которым приложение пыталось обратиться, запись о подтверждении и журнал решений по политикам. Убедитесь, что оператор может установить источник и остановить процесс, не полагаясь на объяснение модели.

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

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

Какие обещания преувеличены и что ещё не решено?

Ни модель, ни промпт, ни фильтр, ни продукт для защиты ИИ нельзя считать исчерпывающим решением. OWASP прямо указывает, что ни RAG, ни дообучение не защищают от промпт-инъекций полностью. RAG — генерация с опорой на найденные документы — снабжает модель материалами для ответа, но не даёт этим материалам права менять задачу.

Более строгий системный промпт может улучшить поведение модели. Но он не сузит широкие права учётных данных. Классификатор может отметить подозрительный контент. Но он не решит, вправе ли конкретный сотрудник раскрыть конкретное вложение. Проверка первой модели второй добавляет ещё один контроль, но независимая политика приложения всё равно необходима.

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

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

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

Частые вопросы

Как защититься от промпт-инъекций?

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

Как выглядит обычный промпт?

«Кратко перескажи письмо этого потенциального клиента и подготовь черновик ответа для проверки» — пример обычного промпта. Письмо клиента — материал задачи, а не разрешение изменить запрос.

Используются ли SQL-инъекции до сих пор?

Да. SQL-инъекции остаются актуальны для приложений, которые небезопасно формируют запросы к базе данных. Помимо защиты от промпт-инъекций им нужны специальные меры для баз данных; см. рекомендации OWASP по защите от инъекций.

Что означает инъекция в программировании?

В информационной безопасности инъекцией называют ситуацию, когда недоверенные входные данные меняют то, что выполняет или обрабатывает интерпретатор. Промпт-инъекция воздействует на поведение модели; другие инъекции — на запросы к базе данных, команды или код в браузере.

Что такое инъекция простыми словами?

Это ситуация, когда входные данные пересекают границу доверия и начинают восприниматься как инструкция, давать которую у их источника не было полномочий.

Какие бывают виды инъекций кода?

Например, SQL-инъекции, инъекции команд операционной системы и инъекции скриптов. Способ защиты зависит от интерпретатора. Промпт-инъекция связана с ними общей проблемой границ доверия, но не является синонимом всех инъекций кода.

Какие бывают виды промпт-инъекций?

Основное различие по способу доставки — прямые и косвенные атаки: инструкция приходит через пользовательский ввод или через материалы, которые извлекает приложение. Текст на изображениях и в других медиа тоже может содержать инструкции; путь доставки и формат материала — разные характеристики.

Какие выделяют 7 основных типов хакеров?

Классификация хакеров не даёт полезной политики разрешений для агента. Выстраивайте защиту исходя из того, кто прошёл аутентификацию, кто может влиять на контент и к чему приложение вправе обращаться или что менять.

Что такое DDoS и SQL-инъекция?

DDoS — это распределённая атака типа «отказ в обслуживании»: она направлена на доступность системы и использует распределённые источники. SQL-инъекция изменяет запросы к базе данных. Это отдельные от промпт-инъекции проблемы; меры защиты доступности описаны в рекомендациях OWASP по предотвращению отказа в обслуживании.

С чего начать в понедельник

Выберите действующий процесс с почтой или CRM и составьте список доступных ему данных, инструментов и внешних адресов назначения. Уберите ненужный доступ, поставьте действия с существенными последствиями на ожидание подтверждения конкретного действия и покажите, что отклонённое предложение не вызывает никаких внешних изменений. Расширяйте автономность лишь после того, как проверите и полезную работу, и сценарии отказа.

Получайте практические руководства по созданию рабочих процессов с ИИ в рассылке.