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