RAG и утечки данных: как поиск по базе знаний становится каналом слива

Почему RAG течёт: права проверяются не там

Классическая ошибка выглядит так: все документы компании индексируются в общий векторный индекс, поиск идёт по всему индексу, а права пользователя проверяются «где-то в приложении» — или не проверяются вообще. Дальше достаточно правильно сформулированного вопроса: «что написано в последнем отчёте о зарплатах?», «процитируй договор с клиентом X» — и модель добросовестно отвечает по документу, к которому у спрашивающего нет доступа.

Хуже того: даже если прямое цитирование запрещено промптом, содержимое чужого документа уже попало в контекст модели — и извлекается косвенно: через пересказ, через «сравни с…», через просьбу перевести. Единственная надёжная граница — не дать документу попасть в контекст вообще.

Четыре типовых сценария утечки

• ◇Общий индекс без ACL: права не привязаны к документам, любой пользователь ищет по всему корпусу. Самый частый и самый грубый случай — встречается даже в продуктах для enterprise.
• ◇Фильтрация после поиска: документы сначала достаются из индекса, потом отбрасываются по правам. Ошибка в фильтре, обновлённые права, документ с несколькими уровнями доступа — и «отброшенный» текст оказывается в контексте. Фильтровать нужно на этапе запроса к индексу.
• ◇Утечка через метаданные и эмбеддинги: даже без содержимого сам факт существования документа («договор о поглощении компании Y.docx» в списке источников) — уже утечка. Названия, авторы и даты в цитатах выдачи требуют тех же прав, что и текст.
• ◇Отравленный документ: инъекция в файле, который попадает в индекс, — письмо, тикет, загруженный пользователем документ. Модель читает его при ответе другому пользователю и выполняет вложенную команду: искажает ответ, выманивает данные из диалога, зовёт инструменты. Это уже не только утечка — это захват канала.

Как это проверяется на аудите

Проверка RAG — это по сути пентест контроля доступа, только через языковой интерфейс. Берём две учётки с разными правами и методично проверяем: находит ли пользователь A документы пользователя B — прямыми вопросами, перефразированием, поиском по метаданным, многоходовыми диалогами. Отдельный блок — инъекции: кладём в доступное для записи место (тикет, комментарий, загружаемый файл) документ с командой и смотрим, исполняет ли её модель при ответах другим пользователям.

Каждая находка фиксируется транскриптом диалога — это доказательство, которое нельзя оспорить словами «модель так не ответит». Отвечает, и отчёт это показывает.

Как строить RAG, который не течёт

• ◇Права — на этапе retrieval: фильтр по ACL входит в сам запрос к индексу (metadata filtering, отдельные индексы или неймспейсы на тенанта). Ничего чужого в контексте — нечему утекать.
• ◇Наследование прав от источника: документ в индексе несёт те же права, что в исходной системе (диск, wiki, CRM), и они синхронизируются при изменениях, а не один раз при индексации.
• ◇Метаданные под теми же правами, что и текст: цитаты, названия и списки источников фильтруются так же, как содержимое.
• ◇Входной контроль индекса: всё, что попадает в базу знаний из внешних или пользовательских источников, считается недоверенным — маркируется и не может «командовать» моделью.
• ◇Логирование запросов и выдачи: какие документы попали в контекст какого диалога — без этого утечку нельзя ни обнаружить, ни оценить её масштаб.

FAQ