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