Blue41 помог европейскому цифровому банку Bunq (более 20 млн клиентов) защитить AI-ассистента от spearfishing. При тестировании нашли уязвимость косвенной инъекции промптов: всего один банковский перевод мог превратить ассистента в канал доставки убедительной фишинговой атаки. Проблема шире одного банка — это архитектурный вызов для всех финансовых организаций, которые внедряют AI-ассистентов, обрабатывающих транзакции, документы, сообщения и другие недоверенные данные.
Как это работает. Современные банковские приложения используют LLM, чтобы отвечать на вопросы пользователя на основе контекста из бэкенда: транзакций, документации, данных счёта. Когда пользователь просит «покажи последние операции», ассистент извлекает записи и передаёт их модели. Тут и кроется проблема: описание перевода — это данные от третьего лица. В контекстном окне LLM оно может быть интерпретировано не как данные, а как инструкция. Это и есть indirect prompt injection: вредоносные инструкции прячутся в данных, которые ассистент потом подгружает.
Сценарий атаки. Злоумышленнику не нужен доступ к устройству жертвы, вредоносное ПО или классическая социальная инженерия. Достаточно отправить перевод с вредоносным описанием — в PoC использовали €0,02. Когда жертва открывает банк и спрашивает «покажи мои последние транзакции», ассистент подтягивает эти данные, и LLM обрабатывает скрытые инструкции. В демонстрации Blue41 ассистент был вынужден запустить spearfishing-атаку, которая выдавалась за легитимный запрос ре-аутентификации от банка. Сообщение появляется прямо в приложении банка, ссылается на реальные транзакции — очень убедительно.
Почему это важно для финансового сектора. Поверхность инъекции огромна: описания транзакций, платежные референсы, метаданные мерчантов, сообщения поддержки, загруженные документы, CRM-заметки — всё это может оказаться в контексте ассистента. Механизм доставки дёшев и правдоподобен. Ассистент имеет привилегированный контекст: он знает реальные данные счёта, поэтому манипулированные ответы выглядят персональными и своевременными. Риск растёт с возможностями ассистента — если он может вызывать инструменты или совершать действия, ущерб будет больше.
Одними guardrails проблему не решить. У Bunq уже были фильтры и классификаторы инъекций, но злоумышленник не пишет «игнорируй предыдущие инструкции» — он маскирует payload под обычные данные. Угроза возникает не из текста изоляции, а из взаимодействия недоверенных данных, логики поиска, поведения модели и доступных действий ассистента. Нужен многослойный подход: минимизировать ненужный контекст, чётко разделять данные и инструкции, ограничивать чувствительные выходы (генерация ссылок, запрос учётных данных) и мониторить поведение ассистента в реальном времени.
Blue41 подчёркивает: предотвратить все возможные payloads нереально, но при компрометации поведение ассистента меняется (встраивает внешние URL, скрывает информацию, использует необычные паттерны). Мониторинг runtime-поведения и построение профилей нормальной работы дают visibility, необходимый для безопасности в production. Финансовым организациям не нужно отказываться от AI-ассистентов, но нужно воспринимать их как production-системы с новыми границами доверия, новыми сбоями и новыми требованиями к мониторингу.