RAG 文件權限設計：身分、檢索條件與來源 ACL

RAG 會把來源文件轉成可檢索的切片。設計文件級權限時，要沿著這條資料路徑確認：誰提出請求、哪些切片可用，以及來源權限改變後，系統何時停止使用舊資料。匯入成功與答案正確，都不能單獨證明存取控制有效。

先建立可信的身分與權限判斷

後端應從已驗證的工作階段取得使用者與租戶身分，再由可信的授權服務解析可用群組或資源。訪客送來的部門名稱、群組 ID 或模型推斷的角色，不能直接成為授權依據。每個受保護入口都要檢查，包含搜尋、讀取原文與下載；缺少可用的授權判斷時，拒絕該次存取。OWASP 授權指南

Azure AI Search 的 security filter 是明確的例子：它比對查詢條件中的識別字串，本身不會替這段字串完成使用者認證。應用程式仍須可信地建立條件，並避免用戶繞過受保護的查詢入口。Microsoft security filter 說明

分開選擇隔離方式與查詢條件

索引隔離、檢索過濾與來源授權查詢可以組合。先畫出資料與請求路徑，再決定每一層負責什麼。

過濾發生的時間也會影響結果品質。Azure AI Search 區分向量查詢的 prefilter 與 postfilter：先選候選再過濾，可能遺漏原本符合條件的結果；先過濾則可能增加查詢工作。這些是特定實作的取捨，應以實際索引、條件選擇性與查詢集合比較，不宜把某個模式當成跨資料庫的效能保證。Microsoft 向量過濾說明

把來源權限更新列為獨立工作

切片需要可追溯到原文件的識別與適用權限；檢索時也要依目前有效的授權做判斷。不要假設切片工具自動保留 ACL，也不要讓 prompt 決定哪些機密可以透露。引用標題、摘要及共用答案快取同樣可能帶出受限內容。OWASP RAG 安全指南

「查詢時確認權限」仍不能直接保證撤權立即生效。索引、副本、身分 token、群組解析與快取各有更新條件。以 2026 年 10 月 12 日查閱的 SharePoint indexer 預覽文件為例，ACL 增量更新依 API 版本而異，父層權限變更也有額外刷新要求。導入前應逐項核對自己使用的版本與來源功能。Microsoft SharePoint ACL 限制

用可以重跑的證據交付

把身分來源、授權服務、索引範圍、更新事件與失敗處理畫在同一張路徑圖上。每個接點指定負責人，留下版本與測試紀錄；在改用連接器、資料庫或查詢模式時重新檢查。

接著使用 RAG 權限驗收清單 測試撤權、快取和引用。若要討論實際來源與整合範圍，可從 RAG 知識系統服務 開始。