RAG 的安全幻覺：為何權限控制必須下沉，而非事後過濾
RAG 系統的權限管理，常被誤認為是應用層的事後補救。但這種「後置過濾」不僅導致檢索品質低落，更潛藏嚴重的資安風險。本文將深入探討，為何真正的安全、品質與治理，必須從源頭做起，將權限模型深度整合至資料庫與查詢層，實現「權限感知檢索」，而非將安全視為事後過濾的措施。
許多 RAG 系統習慣在檢索後才過濾權限，將安全視為應用層的最後一道防線。然而，這種「後置過濾」不僅效率低落，更潛藏嚴重的資訊外洩與品質問題。我認為，真正的 RAG 安全、品質與治理，來自於將權限模型深度整合至資料庫與查詢層，實現「權限感知檢索」。這意味著從源頭確保系統安全，並提供使用者真正有權存取的、高品質答案，而非將安全視為事後補救。
「後置過濾」的雙重陷阱：為何它既不安全也沒效率？
目前許多 RAG 應用的典型作法是「先檢索，再過濾」（retrieve-then-filter）。系統根據語意相似度，從向量資料庫中找出最相關的 top-k 個文件區塊（chunks），然後在應用程式的業務邏輯層，逐一檢查當前使用者是否有權限讀取這些文件，最後才將過濾後的文件送給大型語言模型（LLM）生成答案。這個看似合理的流程，卻存在兩個根本性的缺陷。
首先是檢索品質的耗損。試想一個情境：系統設定 k=10，也就是一次取回 10 份最相關的文件。但如果這 10 份文件恰好都屬於使用者無權存取的專案機密，經過應用層過濾後，送進 LLM 的上下文（context）將是空的。系統要麼回傳「無法回答」，要麼被迫在次佳、甚至不相關的資訊上生成答案，導致回答品質大幅下降。這種作法浪費了寶貴的檢索與運算資源，卻換來一個無用或錯誤的結果。
更嚴重的是潛在的資安風險。將權限檢查的重擔完全交給應用層，意味著安全防護的成敗繫於每一行程式碼的嚴謹度。只要工程師在某個 API 端點忘了呼叫權限檢查函式，或是在複雜的邏輯判斷中出現漏洞，就可能造成災難性的資訊外洩。根據近期的研究，資料外洩是 RAG 系統面臨的主要威脅之一。後置過濾模型增加了攻擊面，讓本應在資料庫層就該被阻擋的存取請求，一路流竄到應用層，徒增風險。
後置過濾的根本缺陷，在於它將安全視為一個「清理」環節，而不是資訊存取的「先決條件」。這種思維模式本身就是一個漏洞。
什麼是權限感知檢索（Permission-Aware Retrieval）？
要解決上述問題，我們需要轉向「權限感知檢索」（Permission-Aware Retrieval）的架構。核心精神很簡單：讓資料庫在執行向量檢索的「同時」，就根據使用者的權限進行過濾。查詢本身就包含了權限的約束，因此資料庫回傳的結果，必然是使用者有權查看的內容。
這兩種方法的差異，可以透過一個簡單的比較來理解：
| 比較面向 | 後置過濾 (Post-filtering) | 權限感知檢索 (Permission-aware) |
|---|---|---|
| 權限檢查點 | 應用程式層 | 資料庫／查詢層 |
| 查詢邏輯 | 1. 檢索最相關的 k 筆資料 2. 在應用層過濾 k 筆資料 |
在單一查詢中，檢索最相關且使用者可存取的 k 筆資料 |
| 風險 | 資訊外洩、結果空白、效能低落 | 從源頭過濾，風險極低 |
| 資料治理 | 權限邏輯散落各處，難以稽核 | 權限與資料儲存耦合，單一事實來源 |
這種架構上的轉變，將安全從一個脆弱的應用層邏輯，轉變為一個穩固的資料層原則。它確保了無論上層應用如何變化，底層的資料存取始終受到一致的保護。這不僅是安全性的提升，更是系統品質與治理能力的躍進。
如何將權限模型下沉到資料層？
實現權限感知檢索並非遙不可及，許多現代資料庫與向量儲存方案都提供了實現此目標的工具。關鍵在於兩個層面的設計：資料模型與查詢建構。
首先，在資料模型設計上，我們必須將存取控制資訊（Access Control Lists, ACLs）與文件向量一併儲存。這意味著每一筆資料的元數據（metadata）中，都應該明確標示哪些使用者、角色或群組可以存取它。例如，一筆文件的元數據可能包含 {"allowed_users": ["user-a"], "allowed_groups": ["group-x"]} 這樣的欄位。
其次，在查詢建構上，應用程式需要根據當前登入使用者的身份，動態地產生包含權限過濾條件的查詢。許多現代向量資料庫都支援「元數據過濾」（metadata filtering）。例如，Pinecone 或 Weaviate 等服務都允許在向量搜尋的同時，加入對元數據的篩選條件。
一個更進階的整合範例來自於支援原生向量型別的 SQL 資料庫。例如，有開發者利用 TiDB Cloud 的向量檢索功能，實現了權限感知的 RAG。自從 TiDB v7.4.0 引入 VECTOR 型別後，使用者可以在同一個 SQL 查詢中，同時執行向量相似度計算與傳統的 WHERE 條件過濾。查詢語句可能如下：
SELECT content, VECTOR_COSINE_SIMILARITY(embedding, ?) AS similarity
FROM documents
WHERE JSON_CONTAINS(permissions, ?)
ORDER BY similarity DESC
LIMIT 10;在這個查詢中，資料庫會先用 WHERE 子句篩選出當前使用者有權限的文件，然後才在這些合規的文件中，找出語意最相關的前 10 名。整個過程在資料庫內部以原子操作完成，兼具了安全與效率。
將權限模型下沉至資料層，其意義超越了單純的技術選型。這是將資料治理的核心原則，嵌入到 AI 系統的基礎架構中。當存取控制成為資料本身的一部分，我們就為建立可信賴、可稽核的 AI 應用奠定了基石，這也符合NIST AI 風險管理框架中所強調的治理與透明度要求。最終，安全、品質與治理不再是三個獨立的議題，而是一個統一架構決策下的必然成果。
延伸閱讀
- Glean Engineering: How Glean handles enterprise search security and permissions
- Security Threats in Retrieval-Augmented Large Language Models (RAG-LLMs)
- TiDB Documentation: Vector Search
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。