Финансовое приложение получает новый источник знаний: регламенты, инструкции поддержки, ответы партнёров и внутренние заметки. Сначала RAG выглядит безопасно, потому что модель только цитирует найденные фрагменты. Риск появляется позже, когда рядом с ответом подключают действия: создать заявку, проверить счёт, подготовить платёжное поручение или изменить статус клиента.
Отравленный источник в такой цепочке становится не просто плохой справкой. Он может подменить намерение операции, заставить модель выбрать неверный инструмент, запросить лишние данные или предложить действие, которое пользователь не ожидал. Защитнику важно отделить факт из документа от инструкции к выполнению.
Практическая задача — построить RAG так, чтобы недоверенный документ не мог расширить права. Источник может участвовать в ответе, но не должен управлять инструментами, платежами, профилями клиентов и доступом к чувствительным данным.
Эта статья рассматривает защитный порядок: как маркировать доверие источников, какие журналы собирать и какие тесты провести до включения действий в финансовом AI-сервисе.
Где появляется отравление
Опасный документ часто выглядит как обычная инструкция или справка. Он попадает в индекс через загрузку партнёра, пользовательский файл, тикет, базу знаний или архив почты. При поиске он оказывается релевантным и попадает в контекст модели рядом с рабочей задачей пользователя.
Если приложение не различает факты и команды, фрагмент может повлиять на выбор следующего действия. Поэтому каждый найденный кусок должен нести метаданные доверия: источник, владелец, подпись, время добавления и разрешённый способ использования.
- проверять путь документа в индекс;
- хранить владельца и подпись источника;
- отделять цитирование от выполнения действия;
- понижать доверие пользовательских файлов;
- запрещать недоверенным источникам менять правила;
- логировать фрагмент, повлиявший на действие;
- проверять свежие документы перед релизом.
Тестирование перед подключением инструментов
AppSec должен создать безопасные проверочные документы с запрещёнными инструкциями. Они не должны содержать вредных деталей, но должны имитировать попытку изменить роль, запросить секрет, вызвать инструмент или обойти согласование. Тест проходит только если приложение сохраняет фрагмент как данные и не выполняет инструкцию.
Для финансовых сценариев отдельно проверяются платежи, доступ к счёту, изменение реквизитов, просмотр клиентских данных и создание поручений. Любая попытка модели действовать по недоверенному документу должна попадать в журнал отказа.
- создать контрольный документ с ложной инструкцией;
- проверить поиск по базе журналы и выбранные фрагменты;
- запретить вызов инструмента из недоверенного источника;
- требовать подтверждение перед финансовым действием;
- сравнить права пользователя и права источника;
- запустить тест после обновления индекса;
- фиксировать отказ политики в SIEM.
Какие журналы нужны с первого дня
Команда должна заранее решить, какие события доказывают путь от входного сигнала до действия. Если журналы собираются только после инцидента, часть фактов уже потеряна: короткие токены истекли, временные файлы удалены, сессии закрыты, а владелец действия спорит с владельцем системы.
Для AI-сценариев полезен сквозной идентификатор операции. Он связывает пользователя, источник данных, модель, политику, действие, сетевое направление и результат. Тогда расследование не превращается в ручной поиск по разным консолям.
- идентификатор пользователя и рабочей роли;
- источник документа или внешнего события;
- версия модели и версия политики;
- целевой ресурс и тип действия;
- решение контроля и причина отказа;
- сетевое направление и объём данных;
- время действия и владелец исключения.
Контроли до режима блокировки
Начинать лучше с наблюдения. Команда собирает нормальные сценарии, проверяет шум, согласует владельцев и только затем переводит часть действий в запрет. Такой порядок особенно важен там, где модель работает рядом с бизнес-процессом и может остановить легитимную операцию.
Но режим наблюдения не должен быть вечным. Для опасных действий нужен срок: после анализа шума включается запрет по умолчанию, а исключения получают владельца и дату пересмотра.
- наблюдать перед блокировкой;
- запретить опасные действия по умолчанию;
- разделить данные, инструкции и выполнение;
- требовать подтверждение для необратимых операций;
- ограничить сеть и права среды;
- автоматически отзывать подозрительные токены;
- пересматривать исключения по расписанию.
Как SOC, AppSec и владельцы данных делят ответственность
SOC видит сигнал и собирает доказательства. AppSec проверяет границы приложения, код и доверие к источникам. Владелец данных решает, может ли конкретный пользователь видеть или изменять ресурс. Инфраструктура отвечает за сеть, секреты, журналирование и аварийный откат.
Если эта карта не описана заранее, AI-инцидент быстро превращается в организационный спор. Поэтому роли фиксируются вместе с архитектурой и проверяются на учениях.
- SOC формирует гипотезы и временную шкалу;
- AppSec проверяет поток данных и действия;
- владелец данных утверждает доступ;
- инфраструктура меняет ключи и сетевые политики;
- юридическая функция оценивает уведомления;
- руководитель риска принимает остаточные исключения.
Проверка эффективности
Контроль считается рабочим, если он сокращает время расследования и уменьшает число ручных догадок. Отчёт должен показывать не только срабатывания, но и полноту доказательств: видно ли, кто начал операцию, что повлияло на решение модели и какой ресурс был затронут.
Метрики должны быть понятны не только технической команде. Руководитель должен видеть риск, владелец продукта — влияние на процесс, а SOC — качество сигнала.
- время от сигнала до первичного разбора;
- доля событий с полным набором журналов;
- число заблокированных опасных действий;
- доля ложных срабатываний;
- число постоянных исключений;
- скорость отзыва токенов и сессий;
- результаты учений по восстановлению.
Дополнительный технический сценарий
Перед вводом контроля в работу команда проводит короткое учение. Берётся безопасный тестовый объект, имитируется подозрительное событие и проверяется, видят ли его SOC, AppSec и владелец данных. Цель не в красивом отчёте, а в доказательстве, что сигнал проходит через всю цепочку и приводит к понятному действию.
После учения фиксируются пробелы: где не хватило поля в журнале, где не было владельца, какой запрет оказался только документом, а не технической мерой. Эти пробелы переводятся в задачи с датами и ответственными.
- создать безопасный тестовый сценарий;
- проверить поступление события в SIEM;
- связать событие с пользователем и ресурсом;
- проверить блокировку или отказ политики;
- собрать временную шкалу без ручных догадок;
- оформить найденные пробелы как задачи;
- повторить проверку после исправлений.
