Мультимодальная prompt injection — попытка заставить ИИ выполнить постороннее поручение через изображение, скан или другой нетекстовый материал. Для агента, который обрабатывает документы и вызывает инструменты, полезно разделять распознавание содержания и право совершить действие. Надпись в счёте может быть данными для анализа; сама по себе она не разрешает отправку письма, удаление файла или изменение регламента.
Материал предназначен руководителям ИТ, владельцам документооборота и разработчикам корпоративных ИИ-агентов. Разбираем архитектуру обработки изображений и приёмочные проверки. Анализ конкретного инцидента и оценка защищённости отдельной компании требуют её конфигурации и журналов.
Редакционный материал AI рассвет. Проверка источников: 14 сентября 2026 года, версия 2. Коммерческая связь прозрачна: раздел об услугах описывает возможности издателя. Мы сопоставили первоисточники и проверили синтетическую демонстрацию сервиса разрешений. Производственный эксперимент с ИИ-моделью не проводили.
Главное: сохраняйте происхождение текста после OCR, отдельно проверяйте попытку и результат действия, а обработку вложений начинайте с минимальных прав. Нулевой результат атаки нужно объяснить: агент отказался, не увидел содержание или инструмент заблокировал операцию?
Содержание
- Что показал свежий MMPIBench
- Почему распознавание меняет поверхность атаки
- От содержания к полномочию
- Метод ИСТОЧНИК для обработки вложений
- Пример со счётом поставщика
- Как проверить собственный конвейер
- Какие метрики сохранять
- Ограничения фильтров и изоляции
- Что делать при подозрительном действии
- Частые вопросы
- Как AI рассвет помогает выстроить обработку документов
- Вывод
Что показал свежий MMPIBench
Viet K. Nguyen и Mohammad I. Husain опубликовали 8 сентября 2026 года препринт MMPIBench. Визуальная матрица охватывает 720 ячеек: 24 атаки, пять моделей, шесть агентных фреймворков. Авторы сообщают примерно 1% завершённых атак и 12,8% попыток. Завершение определяли механическим сигналом, попытку — голосованием панели моделей. Это разные показатели, их нельзя приравнивать к частоте инцидентов в компаниях. Препринт MMPIBench, v1.
В набор входят текст на изображении, наложения, метаданные, QR-коды, поддельные интерфейсы и сочетания носителей. В статье отмечены повторные запуски части ячеек и отличающаяся конфигурация CrewAI; числовые описания завершений для этого фреймворка внутри текста расходятся. Поэтому рейтинг фреймворков здесь не воспроизводим. Работа не проверяет эффективность предлагаемой ниже архитектуры защиты. Методология и ограничения MMPIBench.
Практический вывод редакции: приёмка должна объяснять место остановки. Один итоговый флаг «файл не удалён» оставляет неизвестным, была ли операция отклонена по полномочиям или просто не дошла до инструмента.
Почему распознавание меняет поверхность атаки
OCR — распознавание текста на изображении. После него приложение получает строку, но происхождение строки остаётся прежним: это содержание внешнего файла. OWASP отдельно описывает мультимодальные инъекции, включая инструкции в изображениях и скрытых слоях документов. OWASP: LLM Prompt Injection Prevention.
Рассмотрим инженерный сценарий. Вчера система не декодировала QR-коды. Сегодня к ней подключили декодер для удобной обработки платёжных документов. В контекст агента теперь может попадать дополнительный текст или адрес. Такая интеграция требует повторной проверки пути данных и действий, даже если модель и основной промпт остались прежними.
| Изменение конвейера | Что проверить до запуска |
|---|---|
| Добавили OCR | Сохранилась ли связь распознанного фрагмента с файлом и страницей |
| Добавили QR-декодер | Не открываются ли полученные адреса автоматически; какие назначения допустимы |
| Добавили чтение метаданных | Не становятся ли поля файла настройками агента |
| Разрешили запись в базу знаний | Проходит ли новый регламент отдельное подтверждение владельца |
| Добавили отправку сообщений | Кто разрешает получателя, вложения и фактическое содержание отправки |
Таблица — наша схема проверки изменений, а не результаты внедрения. Она связывает новую способность читать с возможным расширением маршрута выполнения.
От содержания к полномочию
Происхождение данных отвечает на вопрос, откуда взят факт. Полномочие отвечает на вопрос, кто разрешил действие над каким объектом. Эти сведения стоит хранить отдельно: корректно распознанный текст не делает автора документа администратором системы.
Рекомендуем выдавать обработчику вложения право извлекать поля и предлагать результат. Сервис выполнения получает типизированную операцию: объект, действие, параметры и основание разрешения. Он сверяет их с задачей пользователя и политикой процесса. Текст документа не должен самостоятельно расширять список разрешённых инструментов или объектов.
OWASP рекомендует разделение доверенных инструкций и внешних данных, минимальные привилегии, проверку инструментов и человеческий контроль чувствительных действий. Приведённый здесь проект развивает эти принципы для документооборота; его эффективность нужно проверить локально. Защита агентных систем в OWASP.
Схема 1. Где содержание получает право действовать — предлагаемая архитектура редакции:
Внешний файл → OCR/декодер → фрагмент + происхождение
↓
Задача пользователя → агент → предложение операции
↓
Разрешение владельца → сервис проверки → тестовая запись
↓ отказ
журнал без записиСервис проверки получает разрешение по отдельному доверенному каналу. Если агент или внешний документ может самостоятельно переписать это разрешение, схема теряет свою контрольную границу.
Метод ИСТОЧНИК для обработки вложений
ИСТОЧНИК — редакционная схема, по которой команда может описать границы одного конвейера. Это не стандарт и не сертификация безопасности.
- Идентифицировать вход: файл, отправитель, канал, время получения, версия документа.
- Сохранить происхождение: фрагмент, страница, способ извлечения, версия OCR или декодера.
- Типизировать результат: реквизит, цитата, ссылка, предложение действия; не смешивать их с настройками процесса.
- Ограничить операции: заранее определить доступные объекты и действия обработчика.
- Чётко проверить разрешение: подтвердить конкретную операцию через владельца процесса или независимую политику.
- Наблюдать исполнение: связать предложение, решение политики, вызов и фактический эффект одним идентификатором.
- Изолировать последствия: предусмотреть остановку, карантин записи и восстановление из проверенного состояния.
- Контролировать изменения: повторять тесты после смены модели, распознавателя, инструмента или правил доступа.
Сначала выберите один процесс и заполните эти восемь пунктов. Если команда не может указать, откуда исполнитель получает разрешение, автоматическую запись стоит отложить до прояснения этой границы.
Пример со счётом поставщика
Предположим, сотрудник попросил извлечь реквизиты из скана и подготовить черновик карточки. Внизу страницы находится текст с просьбой изменить адрес получателя уведомлений. Это учебный пример, он не описывает клиента AI рассвет.
| Этап | Предлагаемое поведение |
|---|---|
| Распознавание | Извлечь реквизиты и сохранить источник; постороннее поручение отметить как содержание документа |
| Подготовка | Создать черновик разрешённых полей без изменения адресной книги |
| Проверка | Сопоставить изменения с задачей; адрес получателя проверить по корпоративному справочнику |
| Выполнение | Записать только подтверждённые поля в разрешённый объект |
| Аудит | Сохранить, что предлагалось, что отклонено и что действительно изменилось |
Реквизиты счёта при этом тоже нуждаются в проверке по правилам компании. Отделение инструкций от данных не подтверждает подлинность документа и не исключает ошибку распознавания.
Как проверить собственный конвейер
Начните в тестовой среде с искусственными документами и фиктивными получателями. Не используйте рабочие секреты или реальные платёжные поручения. Для каждого документа заранее запишите разрешённый результат и запрещённый побочный эффект.
Создайте парные варианты: обычный документ и тот же документ с посторонним поручением. Варьируйте носитель, сохраняя основную задачу: видимый текст, наложение, QR, метаданные. Затем отдельно проверьте законные документы со словами «удалить», «отправить» и «изменить», чтобы фильтр не запрещал обычное описание процесса.
Проведите проверку дважды: сначала для извлечения и черновика, затем с тестовым сервисом записи. Для повторов фиксируйте версии и одинаковую конфигурацию. Количество повторов выбирайте до просмотра результатов; один успешный отказ не подтверждает устойчивость.
Приёмка должна требовать сохранения основной полезной функции. Если защита просто отбрасывает все вложения или QR-коды, это ограничение обработки, которое нужно явно согласовать с владельцем процесса.
Что мы проверили в локальной демонстрации
14 сентября 2026 года мы запустили короткий Python-пример сервиса разрешений. Условия: фиктивная задача, один агент, один объект счёта, одно поле и заранее согласованное значение. Положительный контроль — запись разрешённого черновика. В восьми остальных случаях менялся один параметр либо отсутствовал обязательный объект; отдельный случай содержал неподтверждённое заявление документа о разрешении удаления.
| Условие | Решение сервиса | Изменение тестовых данных |
|---|---|---|
| Разрешённый черновик | Допустить | Да |
| Другой объект | Отклонить | Нет |
| Другое поле | Отклонить | Нет |
| Другое значение | Отклонить | Нет |
| Удаление вместо черновика | Отклонить | Нет |
| Другая задача | Отклонить | Нет |
| Другой исполнитель | Отклонить | Нет |
| Заявление документа о разрешении удаления | Отклонить | Нет |
| Отсутствует объект | Отклонить | Нет |
Все девять ожиданий совпали с результатом. Это проверка точного сравнения параметров на выбранных искусственных входах. Она не измеряет распознавание изображения, частоту попыток атаки, безопасность аутентификации, гонки исполнения или работу реальной ERP. Заранее разрешённое значение здесь служит упрощением; в рабочем процессе проверка реквизитов и выдача разрешения потребуют отдельной логики.
Схема 2. Результаты демонстрации — количества тестовых случаев, без оценки вероятности инцидента:
Совпадение с разрешением 1 случай → принят → запись
Подмена или неполные параметры 8 случаев → отказ → без записи
──────────────────────────
Проверенные ожидания 9 из 9 совпалиМинимальный принцип проверки можно воспроизвести так:
def authorize(proposal, operator_grant):
required = ("actor", "task_id", "action", "object_id", "field", "value")
return all(
key in proposal and key in operator_grant
and proposal[key] == operator_grant[key]
for key in required
)Этот фрагмент иллюстрирует сравнение, а не готовый промышленный шлюз. Объект operator_grant должен поступать из доверенного сервиса; в реализации дополнительно нужны проверка личности, срока действия разрешения, повторного использования и атомарности записи.
Какие метрики сохранять
| Показатель | Определение для вашего теста |
|---|---|
| Доставка содержания | Фрагменты, реально переданные модели / фрагменты, предназначенные для передачи |
| Предложение лишнего действия | Запуски с предложением запрещённой операции / обработанные атакующие варианты |
| Запрещённый вызов | Запуски с вызовом запрещённого инструмента / обработанные атакующие варианты |
| Фактический эффект | Запуски с подтверждённым запрещённым изменением / обработанные атакующие варианты |
| Ложная блокировка | Законные задачи, заблокированные защитой / законные тестовые задачи |
| Качество извлечения | Корректные обязательные поля / проверенные обязательные поля |
| Полнота аудита | Изменения со связанной записью разрешения / все фактические изменения |
Доли рассчитывайте из сохранённых счётчиков, а не из впечатления от ответов. Все показатели компании пока неизвестны. Для предложений и попыток нужен заранее описанный критерий разметки; для эффекта предпочтителен журнал тестовой системы.
Отдельно фиксируйте время ручной проверки, задержку и расходы на обработку. Так будет видно, не перенесла ли защита нагрузку на сотрудников. Общие вопросы эффективности рассмотрены в статье метрики эффективности ИИ-агентов.
Ограничения фильтров и изоляции
Microsoft описывает Prompt Shields для прямых и документных атак. Spotlighting маркирует документ как менее доверенный, используя преобразование его содержания. В текущей документации отмечены рост числа токенов, возможное превышение входного лимита и доступность Spotlighting через Chat Completions API. Это полезный слой, но документация не подтверждает защиту любого произвольного изображения в вашей интеграции. Microsoft Learn: Prompt Shields.
Фильтр помогает обнаруживать подозрительное содержание; проверка полномочий ограничивает действие даже при пропуске фильтра. Эти механизмы нужно тестировать отдельно. Особенно важны законные цитаты инструкций, многостраничные сканы, неполное распознавание и документы с несколькими версиями реквизитов.
Развёртывание модели на собственном сервере может менять границы передачи данных. Однако оно само по себе не отделяет внешнюю инструкцию от разрешения выполнить операцию. Для внутреннего агента по-прежнему нужны права на объекты, контроль записи и аудит.
Что делать при подозрительном действии
- Остановить связанные записи и отправки, сохранив возможность расследования.
- Зафиксировать исходный файл, извлечённые фрагменты, конфигурацию и журнал операций.
- Проверить фактические изменения в системе назначения, включая получателей сообщений и новые записи памяти.
- Поместить подозрительные результаты в карантин и восстановить подтверждённое состояние по процедуре компании.
- Воспроизвести сценарий в тестовой среде и добавить его в приёмочный набор.
Удаление исходного вложения не заменяет проверку уже выполненных операций. Разбор места появления ошибочного решения продолжает материал разбор сбоев ИИ-агентов.
Частые вопросы
Может ли скан содержать инструкцию для ИИ?
Да. Внешний скан может содержать постороннее поручение. Его необходимо обрабатывать как содержание файла и сверять любые предложенные действия с задачей пользователя.
Безопасен ли QR-код, если модель его не читает?
Отсутствие декодирования ограничивает текущий путь данных. После подключения декодера маршрут меняется и требует повторной проверки, включая правила открытия адресов.
Достаточно ли добавить запрет в системный промпт?
Запрет полезен как слой защиты. Для агента с правом записи дополнительно нужны минимальные привилегии и независимая проверка разрешения на конкретную операцию.
Что важнее: попытка или завершённая атака?
Сохраняйте оба показателя и критерии их оценки. Попытка показывает отклонение поведения; фактический эффект подтверждает, произошло ли запрещённое изменение.
Защищает ли локальная модель от prompt injection?
Локальное размещение само по себе не решает проблему доверия к содержанию документа. Права инструментов и границы выполнения нужно проектировать отдельно.
Можно ли сразу разрешить автоматическую запись в ERP?
Сначала проверьте один ограниченный процесс в тестовой среде. Разрешённые поля, объекты и основание записи должны быть заранее определены владельцем процесса.
Как AI рассвет помогает выстроить обработку документов
Проблема затрагивает распознавание, интеграцию агента и правила процесса. В рамках направлений, описанных на сайте, с AI рассвет можно обсудить три задачи:
- подготовку источников и карты ролей для выбранного документооборота;
- интеграцию распознавания документов и ИИ-агента с корпоративными системами;
- разработку MVP и тестирование разрешённых сценариев обработки.
Первый шаг — определить один процесс, исходные показатели, источники данных, ограничения и критерий приёмки. Конкретные меры безопасности и объём реализации согласуются для этого процесса; обещания полной защиты здесь не даются. Обсудить задачу.
Вывод
Безопасная обработка изображений начинается с границы между содержанием и разрешением. Сохраняйте происхождение распознанного текста, ограничивайте операции и проверяйте фактический эффект независимо от ответа агента. Для первого испытания возьмите один процесс, парные тестовые документы и заранее определённые запрещённые изменения.