[Day 29] RAG Security 從 API 防護到 AI 應用安全

AI 能回答問題，不代表它能安全地回答問題

我們從 Reliability Engineering 的角度，建立 SLI、SLO、SLA 與 Error Budget 的概念

讓 RAG 系統不只成功上線，也能持續衡量服務品質

但當智慧助理開始處理企業文件、使用者資料與外部工具呼叫時，另一個問題也變得重要：

我們如何確保 AI 只存取有權限的資料，並且不會因為惡意輸入而洩漏機密或執行未授權操作

想像以下幾個情境：

• 使用者沒有權限查看某份人事文件，卻透過 RAG 問答取得其中的薪資資訊
• 惡意使用者在問題中加入 Prompt Injection，試圖要求模型忽略原本的安全規則
• API Key 被寫進 GitHub Repository，導致他人盜用 LLM API
• RAG 系統將文件內容直接交給 LLM，模型受到文件中的惡意指令影響
• AI Agent 可以呼叫資料庫或外部 API，卻沒有檢查使用者是否有執行該操作的權限

這些問題說明，RAG Security 不只是替 API 加上登入驗證，也不能只靠 Prompt 告訴模型「不要洩漏機密」

我們需要從 API、資料檢索、模型輸入輸出、工具呼叫與部署環境等層面建立多層防護

今天就從這些實際風險出發，建立一套 RAG 系統的安全設計思維

RAG 系統有哪些安全風險

先回顧 RAG 的基本流程

在這條 Pipeline 中，每個階段都可能存在不同的安全風險

安全設計的重點，是不能只假設使用者會善意操作，也不能假設模型永遠會遵守 Prompt

模型的回答可以協助完成任務，但真正的存取控制與安全決策，需由可信任的應用程式與基礎設施負責

API Authentication

API Security 是整個 RAG 系統的第一道防線

不過，Authentication 與 Authorization 是兩個不同的概念

Authentication：確認你是誰

Authentication (身分驗證) 用來確認使用者或服務的身份

常見方式包括：

• API Key：適合部分系統對系統的存取情境
• Bearer Token：透過 Token 傳遞經驗證的身分資訊
• OAuth / OpenID Connect：常見於第三方授權、企業登入與身份整合
• Session Cookie：常見於 Web 應用程式

例如，使用者呼叫 RAG API 時，可以在 HTTP Header 傳遞 Access Token

伺服器應驗證 Token 的簽章、有效期限等必要條件，而不是只要收到一串字串就視為登入成功

Authorization：確認你能做什麼

即使使用者已成功登入，也不代表他能存取所有資料

這類設計通常會使用 RBAC (Role Based Access Control)，也就是根據角色分配權限

如果權限取決於使用者、文件擁有者、部門或其他條件，也可以使用 ABAC (Attribute Based Access Control)，根據屬性與政策決定是否允許存取

RAG 最重要的安全問題：文件存取權限

對 RAG 而言，最容易被忽略的風險之一，就是文件檢索沒有落實使用者權限

如果所有文件都使用同一個 Vector Collection，且每次檢索都只根據語意相似度搜尋，就可能發生越權將資料洩漏

例如，員工詢問：

請整理公司各部門的薪資資訊

即使使用者沒有 HR 權限，Retriever 仍可能找到薪資文件，再交給 LLM 產生回答

此時，問題不是 LLM 回答得好不好，而是未授權的資料已經進入了生成流程

在 Retrieval 階段落實 Authorization

每份文件或 Chunk 可以附加權限 Metadata

當使用者提出問題時，系統先取得可信任的使用者權限，再依據權限過濾檢索結果

這段程式只展示依部門過濾的語法，不能直接視為完整的安全授權實作

因為 Engineering 不能由使用者自行傳入並決定

實際系統要從可信任的身份與授權服務取得部門資訊，並將授權條件套用到每一次檢索

此外，當文件具有多角色、多部門、使用者擁有者等複雜權限時，也要確認資料庫的過濾能力能正確表達授權政策

若需要更複雜的邏輯，應由可信任的授權層處理

為什麼不能先檢索，再讓 LLM 判斷是否能回答

因為這時未授權的文件已經進入模型上下文

即使 Prompt 寫著「禁止洩漏機密」，也無法保證模型不會引用這些內容

因此，正確順序應是：

先驗證權限，再檢索資料；不能把授權責任交給 LLM

同時，還要確認引用、快取、對話記憶、日誌與匯出功能不會再次洩漏未授權資料

Prompt Injection 與不可信任文件

Prompt Injection 是生成式 AI 應用程式的重要安全風險

攻擊者會試圖將惡意指令放進使用者輸入或模型讀取的內容中，影響模型原本的行為

這類攻擊直接針對使用者輸入與模型指令

而間接 Prompt Injection 更需要注意，因為惡意指令可能藏在模型讀取的文件裡

如果 RAG 將這份文件直接加入 LLM Context，模型就可能受到其中指令影響

這代表文件不一定只是單純的資料來源，也可能包含不可信任的內容

為什麼只靠 System Prompt 不夠

這些指示有助於引導模型行為，但不能當作完整的安全防線

原因是模型可能無法在所有情境下正確區分指令與資料，也可能因為上下文衝突而產生不安全的輸出

因此，Prompt Injection 防護需要結合：

• 將檢索文件明確視為不可信任的資料
• 不把文件內容直接當成系統指令執行
• 限制模型可呼叫的工具與操作範圍
• 在工具執行前進行伺服器端授權
• 對敏感輸出與高風險操作進行額外檢查
• 對 Prompt Injection 建立專門的安全測試案例

結構化有助於區分不同來源的內容，但 XML 標籤或文字分隔本身並不是安全邊界，也不能保證模型一定不受 Injection 影響

若文件可能包含惡意指令，仍然必須搭配工具權限限制、資料存取控制與安全評估

另外，實際使用時，應依 LLM SDK 的訊息格式分別傳遞 System、User 與 Context，而不是把所有內容都當成同等可信任的字串

LLM 與 Agent 的工具呼叫安全

當 RAG 系統進一步成為 Agentic AI，模型可能不只回答問題，還能呼叫工具

例如：

• 查詢訂單
• 讀取資料庫
• 寄送 Email
• 建立工單
• 更新使用者資料
• 呼叫內部 API

此時，風險會從「回答錯誤」擴大到「執行未授權操作」

假設模型可以直接產生 SQL

這樣的設計存在明顯風險

如果使用者要求刪除資料，或模型因 Prompt Injection 產生了不合理的 SQL，應用程式可能直接執行危險操作

應限制模型只能呼叫預先定義的工具，並由應用程式檢查參數與權限

需要有白名單與權限檢查的概念

正式環境還需要：

• 驗證工具參數與資料型別
• 檢查使用者是否有權存取指定資源
• 限制每次請求的工具呼叫次數
• 設定 Timeout 與錯誤處理
• 對寫入、刪除、付款或寄信等高風險操作加入確認機制
• 將工具執行記錄納入 Audit Log
• 避免讓模型直接取得資料庫管理員權限

LLM 可以提出工具呼叫建議，但是否允許執行，必須由應用程式根據可信任的政策決定

Secrets Management 與 API Key 保護

RAG 系統通常需要多種憑證：

• LLM API Key
• Vector Database 帳密
• Redis 密碼
• JWT 簽章金鑰
• 雲端服務存取憑證

可能因為 Git Push、日誌輸出或映像檔打包而外洩

輸入驗證、Rate Limiting 與防止濫用

即使 API 已經完成身份驗證，仍可能受到大量請求、超長輸入或異常請求影響

例如：

• 使用者一次提交數十萬字的問題
• 同一個帳號在短時間內發送大量請求
• 大量請求觸發昂貴的 LLM Generation
• 攻擊者利用重試機制放大外部 API 流量

因此，API 還需要基本的濫用防護

把 Security 納入 CI/CD

這個流程的重點，是把安全性從「上線前人工檢查」轉變為持續驗證的工程流程

• 驗證授權函式與工具白名單
• 驗證不同角色只能取得授權文件
• 確保既有安全案例沒有退步
• 偵測可能誤提交的憑證
• 檢查第三方套件漏洞
• 檢查映像檔中的已知漏洞

真正成熟的 CI/CD，不只確認程式可以運作，也要確認程式沒有破壞既有的安全邊界

今天學到什麼

今天從 API、RAG Retrieval、Prompt Injection、Agent 工具呼叫與部署流程等角度，建立了 RAG Security 的基本觀念。

1. Authentication 與 Authorization 分開設計 確認使用者，不代表使用者能讀取所有文件
2. 資料權限必須在模型生成之前落實 不能把未授權資料交給 LLM，再期待它自行保護機密
3. Prompt Injection 需要多層防護 Prompt 可以協助模型理解規則，但真正的安全邊界應由應用程式、權限系統與工具執行環境負責
4. Agent 的工具呼叫必須受到限制 模型提出的操作不應直接被視為可信任指令
5. 安全性應納入整個開發生命週期 從程式測試、RAG Evaluation、CI/CD 到 Production Monitoring，都應持續驗證安全邊界

我們逐步將 RAG 從一個能夠回答問題的應用程式，發展成具備品質評估、效能監控、成本管理、自動化部署、可靠性管理與安全防護的智慧助理

真正的 AI 工程，不只是讓模型產生好的答案，而是確保整個系統能在正確的權限、資料與安全條件下運作

[Day 30] RAG 打造真正能上線的智慧助理

經過 29 天的實作與架構整理，我們已經涵蓋 RAG 的核心流程、回答品質、效能優化、部署、自動化、可靠性與安全性

最後一天，將把這些技術整合，從系統架構、RAG 品質、效能、成本、監控、部署、安全性與維運流程等面向，檢視一套智慧助理是否已經具備真正上線的條件

讓這 30 天不只是一系列技術文章，而是一套可以持續延伸、實際應用於專案的 AI 工程實踐