Сотрудник просит AI-помощника подготовить краткое резюме страницы клиента. Через интеграцию помощник читает внешний сайт, извлекает содержание и формирует сообщение во внутреннем чате. Если на странице была скрытая инструкция, корпоративный канал может получить уже не справку, а убедительную фишинговую рекомендацию от доверенного инструмента.
Проблема не в одном продукте, а в архитектуре: внешние данные проходят через AI-компонент и попадают в среду, где пользователи ожидают доверия. Внутренний чат, CRM и почта становятся частью одной цепочки, а граница между «прочитать» и «действовать» стирается.
Защитная задача — сделать внешние данные недоверенными до конца цепочки. Даже если модель обработала страницу, результат не должен автоматически превращаться в сообщение, ссылку, задачу или приглашение без проверки политики и владельца действия.
Для AppSec это хороший тест зрелости AI-интеграций: умеет ли система отличать контент от команды, ограничивает ли межсистемные действия и видит ли команда происхождение каждого фрагмента ответа.
Какие события нужно связать
Один лог AI-запроса не покажет всей картины. Нужно связать загрузку внешнего источника, извлечение текста, решение модели, создание сообщения в чате и действия пользователя после него. Только такая цепочка позволяет доказать, что фишинг пришёл не напрямую снаружи, а через доверенную AI-интеграцию.
Особенно важны идентификаторы источника. Если в сообщении нет следа, откуда взят контент, пользователь и аналитик видят только красивый внутренний текст без происхождения.
- URL внешнего источника и время чтения;
- идентификатор AI-сессии;
- тип действия после обработки;
- канал назначения и получатели;
- наличие ссылки или вложения;
- пользователь, подтвердивший отправку;
- политика, разрешившая действие.
Контроли для интеграций
Первый контроль — запрет автоматической отправки во внутренние каналы, если входом были внешние данные. Второй — обязательная маркировка происхождения. Третий — отдельная политика для ссылок, вложений и задач, созданных по результатам AI-обработки.
Нельзя полагаться на системную подсказку как единственный барьер. Проверка должна выполняться вне модели: в шлюзе, слое политики или сервисе интеграции.
- помечать внешний контент как недоверенный;
- запрещать автоматическую отправку без подтверждения;
- показывать пользователю источник и риск;
- блокировать опасные ссылки из AI-ответов;
- вести журнал межсистемных действий;
- ограничить список разрешённых каналов;
- тестировать интеграцию на внедрение инструкций.
Журналы, без которых расследование слепнет
Контроль бесполезен, если после срабатывания команда не может доказать, какие данные были обработаны, какое правило применилось и кто подтвердил действие. Поэтому журналирование нужно проектировать до запуска AI-функции, а не после первого инцидента.
Для чувствительного контекста лучше сохранять не полный текст, а безопасные признаки: класс данных, источник, хеш, идентификатор политики, итоговое действие и причину решения. Это уменьшает риск повторной утечки через сами журналы.
- user_id и роль пользователя;
- device_id и доверенность устройства;
- source_system и тип источника;
- model_version и версия политики;
- политика_id и причина решения;
- resource_id и класс данных;
- action_type и итог операции;
- risk_score и главные признаки риска.
Как включать контроль постепенно
Сначала правило работает в режиме наблюдения и собирает статистику. Затем команда проверяет ложные срабатывания, корректирует исключения и только после этого включает блокировку для критичных действий. Такой порядок снижает риск остановить рабочий процесс из-за неудачного правила.
Исключения должны иметь срок жизни и владельца. Постоянное исключение без объяснения почти всегда превращается в скрытый обход политики.
- запустить правило в режиме наблюдения;
- собрать примеры нормальных и подозрительных событий;
- разделить предупреждение и остановку;
- назначить владельца каждого исключения;
- проверить правило на старых инцидентах;
- описать процедуру аварийного отката;
- пересматривать шумные правила каждую неделю.
Метрики качества защиты
После внедрения важно измерять не число созданных правил, а то, стала ли система управляемее. Хорошая метрика показывает, быстрее ли команда замечает риск, меньше ли ручных исключений и достаточно ли доказательств для аудита.
Для AI-сценариев полезно считать связку из нескольких сигналов. Один запрос к модели может быть нормальным, но запрос вместе с доступом к секрету, внешним доменом и новым токеном уже требует реакции.
- среднее время от сигнала до triage;
- доля событий с полным набором журналов;
- число подтверждённых инцидентов после корреляции;
- количество постоянных исключений;
- скорость отзыва ключей и токенов;
- доля тестов, прошедших без ручной доработки.
Карта ответственности
У каждой меры должен быть владелец: SOC расследует события, AppSec проверяет приложение и зависимости, владелец данных оценивает чувствительность, инфраструктурная команда управляет сетью и ключами, руководитель риска утверждает исключения.
Если роли не прописаны заранее, инцидент превращается в переписку между командами. Карта ответственности должна храниться рядом с описанием системы и обновляться после каждого изменения.
- SOC отвечает за корреляцию и приоритет;
- AppSec проверяет код и настройки;
- владелец данных определяет допустимый контекст;
- инфраструктура отзывает ключи и меняет сеть;
- юридическая функция оценивает уведомления;
- руководитель риска утверждает остаточный риск.
Проверка на учебных сценариях
Перед включением блокировки команда должна провести учебную проверку. Один сценарий описывает нормальную работу, второй — подозрительное поведение, третий — попытку обойти правило через косвенный источник. Такой набор показывает, где контроль действительно видит риск, а где просто реагирует на отдельное слово.
Результаты проверки сохраняются как доказательства: входные условия, ожидаемое решение, фактическое решение, журналы и ответственный владелец. Это помогает не спорить о качестве контроля после первого реального срабатывания.
- проверить нормальный рабочий запрос;
- проверить внешний недоверенный источник;
- проверить попытку передачи чувствительных данных;
- проверить блокировку опасного действия;
- проверить понятность алерта для аналитика;
- сохранить журналы и итоговое решение.
