核心結論
不應該。安全設計會要求使用者以自己的身分連接資料來源，只檢索他在原始系統中有權查看的文件。若工具把全公司文件放進共享索引，卻沒有在每次查詢前依身分篩選，就需要先補上權限控制再擴大使用。
執行摘要
核心觀察：企業 AI 搜尋把分散文件變成直接答案，也會放大原本過寬、過期或沒有同步的權限。一項 2026 年同儕審查研究把身分、角色、資源、動作與條件納入 RAG 存取控制，在合成企業資料集上得到 95.84% 的授權判斷準確率；這仍是模擬結果，不代表正式環境已安全。[1] 行動建議：保留來源系統權限，先授權再檢索，授權服務或文件標籤失效時預設拒絕，並用允許與拒絕案例一起驗收。
統一搜尋，也會統一放大權限
企業 AI 搜尋的價值，在於把郵件、對話、雲端文件與知識庫整理成一個答案。Anthropic 的企業搜尋文件也顯示，這類工具會跨多個已連接來源彙整內容。[4] 但搜尋面愈廣，原本散落在各系統的過寬分享、過期專案權限與外部帳號，也可能一起被帶進答案。
問題不一定是駭客繞過系統，也可能是員工依然保有早已不需要的合法權限。Microsoft 的遙測顯示，超過 90% 的身分使用不到已授予權限的 5%，而超過 50% 的權限屬高風險。[5] 這是 Microsoft 環境的遙測，不等於每家企業的實際比例，但足以提醒公司在接入 AI 前先清理權限。
模型看到前，權限就要生效
最重要的架構原則是先授權、再檢索。Microsoft Research 指出，提示清理、輸出過濾與系統隔離仍屬機率性防線，無法取代細粒度、決定式的存取控制。[2] 如果敏感片段已被放進模型上下文，再要求模型不要透露，資料實際上已跨過第一道邊界。
9 月 13 日發表的權限感知 RAG 研究，先用身分、角色、資源、動作與條件規則驗證查詢，再從已授權候選中進行相似度排序；在合成企業資料集上得到 95.84% 授權判斷準確率。[1] 這是研究模擬，不是任何正式產品的保證，但方法清楚指出授權順序。
權限要跟著人與文件變動
中小企業常把部門、專案與客戶資料放在同一套雲端工具。最低可行控制是保留原始文件擁有者、部門、專案、敏感等級與允許群組，文件進索引前缺少必要標籤就隔離；員工轉組、離職或專案結束時，權限異動也要同步到搜尋與快取。
AWS 的參考架構把 API 呼叫與文件檢索分成兩層獨立授權，授權服務不可用時預設拒絕，政策變更可在下次請求生效。[3] 但 AWS 也明確說明，單一知識庫的中繼資料篩選只是邏輯隔離；若不同客戶間需要合規邊界，仍應使用獨立知識庫與 IAM 資源邊界。[3]
驗收要同時證明可見與不可見
只用主管帳號測試 AI 搜尋，很容易得到看似完整的成果，卻無法證明一般員工或外部夥伴不會看到不該看的內容。驗收應建立成對案例：相同問題由有權與無權帳號提出，前者要找到正確來源，後者應回傳空結果、權限說明或安全替代資訊。
NIST 零信任架構不因帳號位於公司網路或裝置屬於企業就給予隱含信任，而是在建立資源工作階段前完成驗證與授權。[6] 穹境建議 Lead Measure 追蹤具權限標籤文件比例、職務異動同步時間、拒絕測試覆蓋率與預設拒絕率；Lag Measure 追蹤越權曝光事件、錯誤拒絕率、人工解權時間與每次政策變更造成的回歸缺陷。
關鍵要點
沿用來源權限：AI 搜尋不應建立比雲端硬碟、郵件或文件系統更寬鬆的第二套可見範圍。
先授權再檢索：未授權內容應在送進模型前排除，不能期待提示詞或輸出過濾把秘密藏回去。
預設拒絕：授權服務失效、文件缺少分類或身分資訊不完整時，回傳空結果或轉人工，不可放寬搜尋。
同步職務異動：員工轉組、專案結束、外部夥伴離場後，來源權限、搜尋索引與快取都要一起更新。
成對驗收：同一問題要用有權與無權帳號分別測試，確認允許者找得到、拒絕者看不到。
參考來源
Privacy-provisioned-permission-aware RAG in cloud using identity and access management, trust and large-language models
Scientific Reports 原始研究 · 2026-09-13
https://www.nature.com/articles/s41598-026-71936-xEnterprise AI Must Enforce Participant-Aware Access Control
Microsoft Research 原始研究 · 2025-09
https://www.microsoft.com/en-us/research/publication/enterprise-ai-must-enforce-participant-aware-access-control/Secure multi-tenant RAG with Amazon Bedrock and Verified Permissions
Amazon Web Services · 2026-06-22
https://aws.amazon.com/blogs/architecture/secure-multi-tenant-rag-with-amazon-bedrock-and-verified-permissions/Use enterprise search
Anthropic Claude Help Center · 2026-08-06
https://support.claude.com/en/articles/12489464-use-enterprise-searchSecure Generative AI with Microsoft Entra
Microsoft Learn · 2025-06-20
https://learn.microsoft.com/en-us/entra/architecture/secure-generative-aiZero Trust Architecture
National Institute of Standards and Technology · 2020-08
https://csrc.nist.gov/pubs/sp/800/207/final常見問題
Q：企業 AI 搜尋會看到所有公司文件嗎？
A：不應該。安全設計會要求使用者以自己的身分連接資料來源，只檢索他在原始系統中有權查看的文件。若工具把全公司文件放進共享索引，卻沒有在每次查詢前依身分篩選，就需要先補上權限控制再擴大使用。
Q：文件進入向量資料庫後，原本權限還有效嗎？
A：只有系統把來源權限與文件片段一起保存並在檢索前執行，原權限才算真正延續。若只複製文字與向量、沒有同步擁有者、群組及到期資訊，向量資料庫可能成為比來源系統更寬鬆的第二套資料庫。
Q：用提示詞要求 AI 不要洩密，能取代權限控制嗎？
A：不能。提示詞與輸出過濾屬機率性防線，敏感內容若已進入模型上下文，就已跨過關鍵邊界。正確順序是先驗證身分與政策，只把已授權片段送給模型，再對輸出做第二層檢查。
Q：中小企業怎麼驗收 AI 搜尋權限？
A：先挑薪資、報價、客戶合約與一般制度四類文件，建立主管、一般員工、跨部門與外部夥伴帳號。用同一組問題成對測試允許與拒絕結果，再測轉組、離職、權限到期及授權服務失效時是否立即停止檢索。
Q：同一個知識庫可以安全服務不同客戶嗎？
A：要看隔離要求。部門間可用文件標籤與每次請求授權做邏輯隔離；不同客戶若涉及合約或法規邊界，不應只依賴中繼資料篩選，應採獨立知識庫、帳號或 IAM 資源邊界，避免單一篩選失效造成跨客戶曝光。
由穹境科技 AI 情報系統生成 · 2026-09-17 · 資料來源見上方參考列表