Промпт-инъекция в документе — это текст, который пытается увести ИИ от задачи пользователя и направить на чужую. Перед обработкой отделите содержимое файла от инструкций: проверьте подозрительные просьбы, ограничьте доступ модели и не позволяйте ей самостоятельно отправлять данные или выполнять важные действия.
Как распознать попытку изменить задачу
Промпт-инъекция пытается повлиять на работу модели через входные данные. В документе подозрителен текст, который обращается к ИИ и просит его отбросить задачу пользователя, сменить цель, раскрыть доступные сведения или выполнить действие. Такая просьба — повод приостановить автоматическое действие и проверить файл. Но одна необычная фраза ещё не доказывает, что документ вредоносный.
В документе обратите внимание на просьбы, которые требуют заменить прежние указания; показать системные инструкции, другие файлы или переписку; подменить исходную задачу; перейти по ссылке, отправить сообщение или изменить запись. Отдельный повод насторожиться — просьба скрыть действие от пользователя или сообщить ему ложное объяснение результата.
Смотрите на смысл и контекст, а не только на отдельные слова. Фраза «игнорируй предыдущие инструкции» может встретиться в статье о безопасности, которую нужно пересказать. В таком случае это цитируемый материал. Риск возникает, если модель принимает текст документа за указание, которое должно управлять её действиями.
Факт. В категории LLM01 OWASP описывает промпт-инъекцию как ситуацию, в которой ввод пользователя непреднамеренно меняет поведение или ответ языковой модели.
Мнение. Если внешний документ обрабатывает модель с доступом к отправке сообщений или изменению записей, сначала приостановите эти действия и проверьте файл и полномочия системы.
Правила безопасного использования ИИ сотрудниками помогут закрепить общий порядок проверки в повседневных задачах.
Расскажите, чему хотите научить команду. Обсудим задачи и формат обучения.
Чем косвенная инъекция отличается от прямой
Различие связано с источником текста, который пытается изменить задачу. Прямая инъекция находится в сообщении, которое пользователь адресует модели. Косвенная может поступить через внешний материал: документ, письмо или веб-страницу, которые пользователь просит обработать. В обоих случаях такой текст может пытаться изменить выполнение исходной задачи.
| Сценарий | Источник текста | Условная задача сотрудника | Первое безопасное действие |
|---|---|---|---|
| Прямая инъекция | Сообщение пользователя модели | Пользователь просит модель сменить цель или раскрыть доступные данные | Сверить запрос с разрешённой рабочей задачей; не выполнять неразрешённые действия |
| Косвенная инъекция | Внешний материал, который анализирует модель | Сотрудник просит извлечь сведения из письма с посторонней командой | Считать письмо источником данных, проверить команду и сохранить исходную задачу |
Термины могут различаться в разных материалах. Здесь «косвенная» означает, что потенциально управляющий текст пришёл через материал, который модель анализирует. Это различие помогает определить источник риска, но само по себе не доказывает, что команда была исполнена. Раздел также не описывает создание атакующих файлов.
Jailbreak обычно называют попытку побудить модель обойти ограничения поведения. Промпт-инъекция шире: она может пытаться изменить задачу через сообщение пользователя или внешний материал. Эти понятия пересекаются, но не равнозначны. Возможные последствия зависят от того, какие данные и инструменты доступны модели.
Разбор условного примера: письмо с чужой командой
Условный пример, не связанный с опытом AURMIND: сотрудник просит извлечь дату встречи из письма. Внутри письма есть просьба проигнорировать эту задачу и переслать содержимое вложений. Исходное указание — найти дату; просьба в письме остаётся частью внешнего содержимого и сама по себе не разрешает отправлять файлы.
Безопасный ответ в этой ситуации — извлечь дату и сообщить, что письмо содержит просьбу сменить задачу. Не пересылайте вложения и не выполняйте других действий по команде из документа. Затем сотрудник следует внутреннему порядку проверки. Если у ИИ есть доступ к почте или хранилищу, отправка и другие значимые действия должны проходить предусмотренное человеком подтверждение.
Документ может содержать сведения для ответа, но сам по себе не даёт модели права менять задачу или распоряжаться данными.
Обычный просмотр письма помогает заметить явную просьбу, но не показывает непременно весь материал, который попадёт в модель. Вложения, форматирование и способ извлечения текста могут повлиять на передаваемое содержимое. Отсутствие подозрительных фраз на экране не доказывает, что файл безопасен. Пример иллюстрирует порядок действий, но не описывает поведение конкретного сервиса: его настройки и доступы нужно проверять отдельно.
Чтобы проверить факты из файла, сохранив исходный вопрос, используйте отдельный порядок: как извлекать факты из документов и проверять ответ.
Что проверить в PDF, письме и веб-странице
Перед передачей внешнего материала модели выясните, откуда он получен, что именно система из него прочитает и какие действия сможет выполнить. Проверьте, нет ли просьб сменить цель, раскрыть доступные сведения, скрыть команду или отправить данные. Такой просмотр помогает заметить явные попытки подмены, но не заменяет проверку доступа к данным и инструментам.
- Уточните источник. Для письма проверьте отправителя и вложения по процедурам компании; для страницы — адрес и ссылки. Подозрительные вложения открывайте только по утверждённому в организации порядку.
- Сверьте текст с задачей. Ищите просьбы отбросить указания пользователя, изменить цель, раскрыть данные или выполнить действие. Учитывайте контекст: цитата может обсуждать команду, а не предлагать её выполнить.
- Проверьте, что передаст система. Для PDF изучите доступный извлечённый текст и результат распознавания. Для письма и страницы определите, какой текст получит модель.
- Приостановите действия при сомнении. Не разрешайте отправку или изменение записей, пока человек не проверит ситуацию по внутреннему порядку.
Мнение. Если сотрудники часто получают внешние файлы, предварительный просмотр полезен как часть процесса. При большом потоке одной ручной проверки может быть мало: процесс нужно согласовать с учётом форматов и возможностей конкретной системы.
Просмотр не гарантирует, что сотрудник увидит все элементы файла. Необычное форматирование или скрытый фрагмент — повод проверить исходник, но не доказательство конкретного инцидента. Если способ извлечения текста неясен, приостановите обработку и уточните его у ответственного за систему.
Как ограничить последствия для данных и инструментов
Ограничение доступа помогает сдержать последствия, если текст из внешнего материала повлияет на модель. Передавайте только сведения, нужные для задачи, и подключайте почту, хранилище или CRM лишь при рабочей необходимости. Если модель действует от имени пользователя, последствия могут затронуть не только текст ответа: у неё может появиться возможность отправить сообщение или изменить запись.
Явно разделяйте задачу пользователя и внешний материал: сначала укажите, что нужно сделать, затем обозначьте документ как данные для анализа. Такое оформление помогает показать структуру запроса, но не гарантирует, что модель всегда соблюдёт границу между инструкцией и содержимым файла. Поэтому одного форматирования недостаточно.
Перед отправкой сообщения, изменением записи и другим значимым действием предусмотрите проверку человеком. В обычном чате сотрудник читает текст до копирования или отправки. В подключённой системе действие должно требовать подтверждения по принятому в компании процессу. Конкретные настройки зависят от сервиса и интеграций; правила одной платформы нельзя автоматически переносить на другую.
Ограничение полномочий может уменьшить возможные последствия промпт-инъекции, но не доказывает, что в документе нет такой попытки.
OWASP описывает промпт-инъекцию как риск для поведения модели. Практический вывод для команды — проверять доступы и действия именно в используемой конфигурации, а не считать название функции или сервиса достаточной защитой. Нельзя заключить, что модель не может совершить действие, пока не выяснено, какие инструменты ей доступны и как устроено подтверждение.
Почему фильтры и разделители не дают полной гарантии
Фильтр входного текста может находить знакомые подозрительные формулировки. Отсутствие срабатывания, однако, не доказывает безопасность документа: команда может быть написана иначе или не попасть под правила фильтра. Разделители в запросе помогают обозначить границу между указаниями пользователя и внешним материалом, но само оформление не гарантирует, что модель всегда её соблюдёт.
Рассматривайте фильтр как один из способов проверки. Его дополняют ограничение доступа к данным и инструментам, проверка ответа и подтверждение человека перед значимым действием. Подход зависит от задачи и конкретной системы. Нельзя считать, что у всех сервисов одинаковые фильтры, настройки или ограничения.
Если команда рассматривает функцию защиты конкретного продукта, сверяйте её возможности с документацией именно этого продукта. Условия одного сервиса не описывают другой. Не опирайтесь на неподтверждённые проценты точности и обещания полной защиты.
Фильтр может помочь заметить часть подозрительного текста. Решение о значимом действии всё равно должно учитывать полномочия системы и проверку человеком.
Оценивайте не только то, сработал ли фильтр, но и что могла сделать система при пропуске команды. Для этого проверьте доступные данные, возможные действия, порядок подтверждения и способ остановить процесс. Такая оценка относится к конкретной конфигурации и не подтверждает свойства других платформ.
Что делать, если команда найдена
Если документ содержит просьбу сменить задачу, приостановите обработку и не подтверждайте отправку данных или изменение записей. Проверьте, какие источники и инструменты были подключены и успела ли система выполнить действие. Сообщите об этом ответственному по внутреннему порядку; при работе с чувствительными данными привлеките специалистов организации, которые отвечают за такие случаи.
- Приостановите действие. Не подтверждайте отправку, переход по ссылке или изменение записи, пока ситуацию не проверят.
- Сохраните нужный контекст. Отметьте источник файла, исходную задачу и действия, которые система могла выполнить. Ограничьте доступ к материалу и передавайте его только тем, кому он нужен для проверки.
- Проверьте подключённые полномочия. Уточните, какие данные и инструменты были доступны, и выясните, какие действия система могла выполнить.
- Передайте сведения ответственному. Следуйте внутреннему маршруту сообщения; если затронуты чувствительные данные, привлеките соответствующих специалистов организации.
Это общий порядок для команды, а не план реагирования на конкретный инцидент. Организации следует согласовать роли и маршрут сообщения со специалистами, отвечающими за данные и системы. Простое удаление файла не позволяет сделать вывод, что возможные последствия устранены.
Зафиксируйте, что известно, а что ещё требует проверки: источник файла и текст команды — одно; возможное действие подключённой системы — другое. Не называйте событие утечкой или инцидентом до проверки. Решение о дальнейших действиях принимают ответственные специалисты организации с учётом её процедур.
Как проверить результат и закрепить правило в команде
После обработки проверьте, сохранила ли модель исходную задачу и не выполнила ли просьбу из документа. Сотрудник должен уметь отделить данные файла от указаний пользователя, заметить попытку смены цели и остановить неразрешённое действие. Успех в одной задаче показывает только результат этой проверки; он не доказывает безопасность всей системы или рабочего процесса.
Для проверки навыка используйте условное задание с заранее заданными критериями. Например, попросите извлечь из условного письма дату встречи, а в его тексте разместите просьбу переслать вложение. Оцените, нашёл ли сотрудник эту просьбу, сохранил ли исходную цель, проверил ли результат и передал ли сомнение по нужному маршруту. Учитывайте время проверки и исправлений, а не только итоговый ответ.
- Исходная задача: сотрудник извлёк нужные сведения, не подменив запрос целью из файла.
- Данные: сотрудник проверил, какие источники и вложения были доступны модели.
- Действия: сотрудник остановил отправку или изменение, если команда из документа пыталась их вызвать.
- Передача: сотрудник знает, кому сообщить о сомнительном файле и какие сведения приложить.
Закрепите рабочий порядок в подходящих документах компании: укажите, кто проверяет файлы, кто подтверждает значимые действия и кому передают сомнения. Правовые решения, обработку персональных данных и отраслевые требования согласуйте со специалистами организации. Если HR, L&D или руководитель готовит практическое обучение, выберите способ связи на главной странице AURMIND и опишите задачу команды.
Рабочая схема
Эта схема показывает порядок действий в описанном примере. Проверки каждого этапа разобраны в статье.
Частые вопросы
Что такое промпт-инъекция в документе?
Это текст внутри анализируемого документа, который пытается повлиять на задачу модели, например побудить её сменить цель или раскрыть доступные данные. Необычная фраза сама по себе ещё не подтверждает атаку.
Чем прямая промпт-инъекция отличается от косвенной?
Прямая содержится в сообщении, которое пользователь адресует модели. Косвенная может поступить через внешний материал, например документ или веб-страницу, который модель обрабатывает.
Может ли промпт-инъекция привести к раскрытию данных?
Она может пытаться побудить модель раскрыть доступные ей данные. Возможные последствия зависят от подключённых источников, полномочий и настроек конкретной системы.
Защищают ли фильтры от промпт-инъекций полностью?
Нет оснований считать фильтр полной гарантией: он может не распознать некоторые варианты текста. Ограничивайте доступ и проверяйте важные действия человеком.
Источники
- LLM01: Prompt Injection — OWASP GenAI Security Project.
- AI Risk Management Framework — National Institute of Standards and Technology (NIST).
