Где возникает риск

Представьте помощника, который читает входящие письма и сканы счетов, находит заказ в CRM и готовит карточку для бухгалтера. Вложение нужно ему как источник фактов: сумма, поставщик, номер договора. Но внутри картинки или распознанного PDF может оказаться фраза, обращённая не к человеку, а к модели: «не проверяй реквизиты», «ответь иначе» или «отправь сведения по другому адресу». Это не полномочие отправителя документа. Это посторонняя инструкция, оказавшаяся среди данных.

В выпущенном в августе перечне OWASP GenAI/LLM Top 10 за 2026 год prompt injection остаётся отдельным риском LLM01. В первоисточнике названы не только сообщения пользователя, но и извлечённые страницы, письма, результаты инструментов, изображения и память агента. Опасность определяется не расположением модели, а тем, какие решения приложение доверяет её ответу и какими инструментами она располагает. Локальный сервер помогает контролировать передачу данных наружу, но сам по себе не отделяет чужой текст от внутренних правил работы.

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

Почему «это же наш документ» не равно «этому можно доверять»

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

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

Полезно различать три события. Первое — модель увидела подозрительный текст. Второе — она попыталась поменять план или вызвать инструмент. Третье — приложение действительно выполнило действие. Защита должна снижать вероятность первых двух, а на третьем иметь независимый технический запрет. Один «строгий системный промпт» не является таким запретом.

Рабочая архитектура без магического фильтра

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

  • На входе сохраняйте происхождение файла: кто загрузил, из какого канала, когда, к какому заказу он относится и кто отвечает за результат. Внешнее вложение помечайте как недоверенное даже после OCR или помещения в векторную базу.
  • Извлекайте поля отдельно от инструкций. Модель может предложить сумму, номер договора и ссылку на область документа, но не должна получать право утверждать платёж или менять получателя только потому, что это написано в PDF.
  • Для RAG передавайте найденный фрагмент как цитируемое содержимое с идентификатором источника и версией. Права на чтение проверяйте до выдачи фрагмента. Метка «документ» не повышает его приоритет над внутренними правилами.
  • Вызовы CRM, почты и ERP проводите через обычный кодовый шлюз: разрешённые операции, проверка параметров, права сервисной учётной записи, лимиты и журнал результата. Решение «можно отправить письмо» или «можно изменить реквизиты» принимает этот слой и ответственный сотрудник, а не модель.
  • Для значимых действий создавайте черновик и подтверждение человеком. Проверять нужно не только красивый текст ответа, но и адрес получателя, сумму, ссылку на заказ и источник каждого извлечённого поля.

Это не призыв ставить громоздкую платформу безопасности перед первым пилотом. Часто достаточно запретить агенту прямую запись в учётную систему и дать ему один узкий инструмент «создать черновик». Позже права расширяют только по измеренным сценариям. Если документ нельзя показывать конкретному сотруднику, его не должна получать и модель, отвечающая от его имени.

Как проверить на своих данных

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

Наблюдайте четыре показателя:

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

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

Экономика и управленческий вывод

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

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

Изображение: Gknor, Wikimedia Commons, CC0; квадратный кроп оригинального скриншота без дорисовки. Он показывает учебный пример, а не результат проверки описанной здесь архитектуры.