Права доступа в RAG: фильтровать до поиска, а не после ответа

Откуда берётся утечка

Документы приезжают из SharePoint, Google Drive, CRM, файловых папок и внутренних API. При индексации команды часто сохраняют текст и название, но теряют исходные ACL. В результате vector store становится единой копией знаний без прежних границ.

Вторая ошибка — использовать один технический аккаунт для всех запросов. Источник отвечает: «этому сервису можно», но это ничего не говорит о правах конкретного сотрудника.

Третья — проверять доступ только при открытии ссылки. Пользователь не откроет файл, но уже увидит его содержание в ответе.

Как должен идти запрос

1. Приложение получает подтверждённую идентичность пользователя.
2. Определяет его роли, группы и контекст организации.
3. Формирует фильтр допустимых ресурсов.
4. Retrieval ищет только внутри разрешённого множества.
5. Модель получает только разрешённые фрагменты.
6. Цитата ведёт на источник, который пользователь тоже может открыть.

AWS описывает такой контроль через identity propagation и metadata filtering; Microsoft поддерживает document-level access control в поисковом индексе. Реализация зависит от платформы, но принцип одинаков: решение о доступе предшествует выдаче текста модели.

Что хранить рядом с фрагментом

Минимальные метаданные:

• стабильный ID исходного документа;
• версия и дата действия;
• владелец источника;
• tenant или организация;
• допустимые пользователи, группы или policy reference;
• класс чувствительности;
• статус: активен, отозван, архивирован;
• ссылка на оригинал.

Не обязательно размножать огромный список пользователей в каждом chunk. Можно хранить ссылку на policy и разрешать её на этапе запроса. Важно, чтобы переиндексация текста и обновление прав были согласованы.

ACL меняются независимо от текста

Сотрудник перешёл в другой отдел, папку закрыли, документ рассекретили — содержимое могло остаться прежним. Значит, pipeline должен уметь обновлять права без полного переобучения или ожидания ночной индексации.

Нужны события или регулярная сверка ACL, дата последней синхронизации и политика поведения при сбое. Безопасный default — не показывать документ, если актуальность разрешения подтвердить нельзя.

Кеш тоже участвует в модели доступа

Опасно кешировать ответ только по тексту вопроса. Два сотрудника спрашивают одно и то же, но имеют разные права. Ключ кеша должен учитывать пользователя или эффективную policy, tenant, версию индекса и другие параметры, влияющие на разрешённый контекст.

То же относится к semantic cache и истории диалога. Ответ, когда-то построенный из закрытого документа, не должен всплыть у другого пользователя через память разговора.

Цитата не является контролем доступа

Цитата помогает проверить grounding. Она не доказывает, что источник разрешён. Более того, название файла вроде Сокращения_2027_финал.xlsx уже может раскрыть чувствительную информацию.

Перед показом нужно проверять и содержимое фрагмента, и метаданные цитаты, и возможность открыть оригинал. Если прямой URL не поддерживает авторизацию, лучше показать безопасный идентификатор и открыть документ через контролируемый gateway.

Permission eval должен быть отдельным

Возьмите одинаковый вопрос и прогоните его от нескольких ролей:

• сотрудник отдела;
• сотрудник другого отдела;
• руководитель;
• внешний пользователь;
• пользователь после отзыва права.

Проверяйте не только финальный ответ, но и retrieved chunks, citations, кеш, логи и телеметрию. Добавьте документы-приманки с уникальными маркерами: если маркер появился не у той роли, тест однозначно провален.

Критическая утечка не должна растворяться в среднем RAG score. Это отдельный release blocker.

Что делать с вопросом по нескольким областям доступа

Иногда для полного ответа нужны три документа, а пользователю доступны два. Система не должна угадывать содержание третьего. Она может ответить по разрешённым источникам и явно сказать, что результат неполный, либо передать запрос владельцу процесса.

Такой отказ лучше уверенного ответа, собранного из того, что случайно оказалось в индексе.

Минимальный checklist

• Идентичность пользователя доходит до retrieval.
• ACL исходного источника не теряются при индексации.
• Фильтрация выполняется до передачи контекста модели.
• Изменение прав синхронизируется независимо от текста.
• Кеш учитывает effective permissions и версию индекса.
• История разговора не является самостоятельным источником фактов.
• Пользователь может открыть показанную цитату.
• Permission tests входят в обязательную регрессию.

RAG без модели доступа — это не корпоративный поиск. Это общая копия документов с удобным разговорным интерфейсом.