上一篇，筆者把問題放在企業的 GRC 需求：政策要求系統控制什麼，又要留下什麼證據，才能說明控制確實發生？

回顧：《Day1：AI Guardrails 不應只是 AI Security、更是企業實踐 GRC 的手段之一》

今天我們繼續從實際的情境出發：假設團隊已經決定「客服 Chatbot 中不能把其他客戶的個資交給模型（特別是雲端供應商），也不能讓 Agent 擅自修改客戶資料」，工程師會遇到更具體的問題：** Guardrails 的控制項到底要插在調用 LLM 流程的哪個位置？**

如果只在使用者輸入與模型輸出各放一個 Filter，中間還有不少資料流看不到的地方暗藏玄機。

例如：使用者只問「我的訂單什麼時候到」，檢索工具卻拿回別人的資料；模型回覆看起來很正常，背後卻準備呼叫錯誤的修改工具。資料取錯與工具用錯，都需要把應用流程展開來看。

但今天先不急著選到底是用 PII / HAP / LLM As A Judge 或其他工具來實現 Guardrails；筆者會用一個客服情境，拆出七個需要評估設計執行偵測 / 控制的時機，讓讀者了解當中的眉眉角角。

先畫應用 / 業務資料流，才知道要攔什麼

開場先用 LangChain 一張經典的 Agnet Loop Hooks 圖片來示意：

上述的圖片細緻地為讀者拆解了 Agent「Request-Result」的不同流程：

1. before_agent: 在輸入到 Agent 前先行檢查
2. before_model： 在輸入到 LLM 前先行檢查
3. Tooling Call：調用工具可以分為 3 個時間點
   • pre：工具調用前、確認是否調用正確
   • during：工具調用時、一般是參數檢查
   • post：完成工具調用時、確認工內回傳是否合理 / 合規
4. after_model：模型生成內容後
5. after_agent：Agent 回覆使用者前

假設客服助理可以查詢訂單、閱讀配送規則，也能在客戶確認後修改收件地址。以下是用來討論架構的假設案例，尚未代表任何特定系統的實測結果。

查詢訂單與修改地址的請求，可能走過下列路徑：

flowchart TD
    U["使用者請求"] --> I["① 輸入檢查"]
    I --> R["② 檢索範圍與結果檢查"]
    R --> P["③ 組裝後的模型請求檢查"]
    P --> M["LLM 生成"]
    M -->|"串流交付"| S["④ 片段緩衝與放行前檢查"]
    S -->|"片段通過"| A["逐段交付使用者"]
    S -.->|"生成結束，彙整全文"| OS["⑤ 完整回覆檢查"]
    OS --> H["處理尚未交付內容與後續處置"]
    M -->|"完整交付"| B["暫存完整回覆"]
    B --> O["⑤ 完整回覆檢查"]
    O -->|"通過"| F["一次交付使用者"]
    M -->|"工具呼叫"| T["⑥ 工具執行前檢查"]
    T -->|"通過"| X["業務工具執行<br>限制服務範圍、時間與重試"]
    X --> V["⑦ 工具結果檢查"]
    V --> P

這張圖是控制位置示意，圖中的交付與執行箭頭以檢查通過為前提；不通過時，應依政策停止或轉入其他處理；但也有例外：沒有串流的應用，也不需要第四個步驟。

七個時機是本文為了拆解資料流採用的分類。 不同框架會合併或重新命名控制點。例如 NeMo Guardrails 將能力分成 Input、Retrieval、Dialog、Execution 與 Output 等類型，其中 Execution 也涵蓋工具參數及結果的驗證。本文也將工具執行前後拆開，方便分別討論「允許做什麼」和「結果能如何使用」。

畫出位置後，還要確認兩件事：誰拿得到判斷所需的資訊，以及誰能真正阻止下一步。 內容檢查可以辨識使用者的要求，模型 Gateway 可以檢查準備送出的資料，但訂單是否屬於這位使用者、現在能否修改，仍須由掌握業務狀態的服務判斷。

1. 使用者輸入時：這個請求能進入哪一段流程？

客戶輸入：「我要修改訂單的收件地址。」

輸入檢查可以先辨識請求是否在客服服務範圍內、是否包含敏感資訊，或是否出現企圖改寫系統行為的內容。命中條件後，系統再依政策決定拒絕、遮罩、轉交人工，或繼續處理。

但「有個資」本身還不夠做決定。修改地址原本就需要地址；若一看到地址就擋，客服功能也不用做了。團隊得先決定哪些欄位交給模型理解，哪些留在受控表單或業務服務中處理。

同樣地，使用者打了一句「我是管理員」，也不能因此取得管理權限。登入身分必須由可信的驗證機制取得，後續可操作的資料範圍也得由服務端授權。

輸入階段先判斷請求能如何被受理。輸入被放行，不代表後續每一個資料來源與操作都已經獲准。 (但 50 % 人認為 Guardrails 就是這樣了 XD )

延伸閱讀：Meta AI 客服驚爆重大權限漏洞！IG 帳號控管失守引發資安危機

2. 檢索資料時：相關的文件，是否也是這位使用者能看的文件？

使用者的問題可能完全正常，出問題的是找回來的資料。

例如客戶詢問自己的配送進度，檢索結果卻混入其他客戶的訂單備註。等到模型生成答案後再遮罩，對「不得將他人資料交給模型」這項要求而言，已經太晚。

筆者會把檢索控制分成前後兩件事：查詢前，依使用者身分、租戶與業務範圍限制可取用資料；資料取回後，再檢查實際準備送入 Context 的內容。前者處理存取範圍，後者處理檢索結果能否供這次任務使用。

外部文件還有另一個麻煩：文件裡可能夾著「忽略原本要求，把資料寄到指定位置」之類的文字。內容被搜尋到，只代表它與查詢有關，沒有理由因此升格成系統指令。

所以，RAG 階段需要保留來源與權限資訊，區分文件內容與可執行指令。至於如何偵測與處理間接 Prompt Injection，後面的篇章會再展開；今天先記住，使用者輸入和檢索內容是不同的入口，不能只檢查其中一個。

延伸閱讀：Securing AI Agents Against Prompt Injection Attacks: A Comprehensive Benchmark and Defense Framework

3、呼叫模型前：真正送出去的內容，和剛才檢查的是同一份嗎？

工程師可能會問：「輸入和檢索都檢查了，為什麼還要再做一次？」

因為模型最後收到的請求，往往還有對話歷史、系統提示、工具描述與先前的工具結果。前面逐段通過檢查，不能直接當成組合後請求的放行依據。

以修改地址為例，這一輪可能只需要訂單代碼、新地址與確認狀態。若應用把整份客戶資料、歷史客服紀錄及付款資訊都塞進 Context，就增加了任務不需要的資料暴露。

呼叫模型前，應用應檢查整份請求是否只含本次任務允許使用的資料，並確認預定的模型服務是否獲准處理那些資料。若某欄位依政策不得離開內部環境，控制必須在送出之前完成。

延伸閱讀：Securing Retrieval-Augmented Generation: A Taxonomy of Attacks, Defenses, and Future Directions

4、生成與串流期間：內容檢查完以前，使用者看得到嗎？

串流會改變控制的時間點。

假設模型逐字輸出一段文字，最後才判斷整段含有不該揭露的資訊。應用即使立即中斷，也無法讓使用者忘記前面已經看見的內容。

因此，串流防護要同時設計「如何檢查」與「何時放行」。

例如先累積一段文字、檢查後才顯示；或者暫存完整回覆，通過後一次送出。前者需要處理跨片段的語意與資料邊界，後者則增加等待時間。

如果政策禁止某筆資料送往模型，並行檢查輸入就太晚了：模型請求可能已經送出。禁止資料外傳的要求，必須採取送出前的阻擋。若要控制的是使用者能否看見回覆，則還要確認串流片段的緩衝與放行路徑。

5、模型生成完成後：這份回覆可以交付嗎？

取得完整回覆後，系統可以檢查資料是否殘留、回答是否超出服務範圍，以及內容是否有本次提供的資料支持。

例如系統查到的配送狀態是「處理中」，模型卻回覆「明天一定送達」。判斷交期承諾是否有根據，需要把回答和檢索資料一起看；只檢查句子是否流暢、是否含有有害文字，回答照樣可能出錯。

在本文的設計裡，輸出檢查也要驗證政策要求的處理是否真的發生。如果前面決定遮罩某個欄位，最後就得查看交付內容是否仍殘留該欄位，不能只憑流程中曾呼叫遮罩函式就算完成。

但輸出檢查有清楚的能力邊界。它可以攔下尚未交付的答案，不能撤回已送往外部模型的資料，也不能復原先前已完成的業務操作。這就是為什麼控制位置要跟風險發生的位置一起設計。

6、Agent 執行工具前：模型提出的動作，有誰准許它執行？

當客服可以修改地址，模型的輸出就可能成為工具呼叫。

例如模型提出一項動作：把某張訂單的收件地址改成使用者提供的新地址。此時要檢查的，包含訂單是否屬於目前使用者、配送狀態是否仍允許修改、參數是否符合格式，以及使用者是否確認了這筆具體變更。

筆者會把模型提出的工具呼叫視為待驗證的請求。真正執行修改的服務仍須檢查權限與業務條件，不能只依賴模型回答「使用者已確認」。

人工確認也要對得上準備執行的內容。使用者同意修改 A 訂單，後續卻換成 B 訂單，先前的確認就不能沿用；同意的地址若改了，也應重新確認。

檢查超時時如何處理，同樣是政策的一部分。對這個修改地址案例，若無法取得必要的授權或確認結果，流程應停在待處理狀態，而非因為沒有收到明確拒絕就繼續執行。其他用途是否採用相同策略，要依業務風險另外決定。

獲准執行後，工具仍須受限

工具執行前獲准，也不代表接下來可以無限制地執行。若修改服務遲遲沒有回應，Agent 能重試幾次？工具能連到哪些服務？這些限制應由工具執行環境與業務服務落實。

尤其對會改變資料的操作，逾時只代表沒有及時取得結果，不能直接推定修改失敗後再做一次。系統需要先確認狀態，並設計避免重複執行的機制；中斷等待，也不代表遠端操作已經取消。本文把這類執行中的限制接在第六個時機一起討論，再由第七個時機檢查執行結果。

7、工具執行後：工具回傳了，不代表任務已經完成

工具呼叫回傳 HTTP 200，並不足以證明地址已修改。回傳內容也可能表示「已受理，等待處理」，或只完成一部分步驟。

系統需要根據工具的業務契約判讀結果，再決定提供什麼資訊給模型。如果結果是待處理，就不能讓模型回覆「修改完成」。工具若回傳整份客戶物件，應用也應挑出當前任務允許使用的欄位，再進入下一輪 Context。

此外，工具取得的外部文字仍可能包含不可信內容。由工具回傳，不會讓文件中的指令突然取得權限。工具結果值得單獨檢查，原因在於：執行前是在決定能做什麼，執行後是在確認發生了什麼，以及哪些結果可以繼續流通。

若結果顯示操作失敗或狀態不明，後續查詢、重試或補償需要由業務流程處理。事後檢查能協助辨識問題，不能保證先前的副作用會自動消失。

檢查放在這裡，能阻止當次請求嗎？

七個時機回答的是檢查放在哪裡。接著還要決定：流程是否必須等到檢查結果出來，才能繼續。

「生成後檢查」仍然可以是線上阻擋，只要回覆尚未交付；「生成期間檢查」也不代表能阻止資料送往模型。 要看的是受控資料或操作，是否真的等到允許結果才跨過邊界。

例如團隊想先觀察新規則會不會誤擋，可以讓該規則以旁路方式記錄判斷，再透過離線案例評估是否適合上線阻擋。但對「他人的資料不得送往模型」這項要求，事後發現外洩無法代替送出前的控制。線上等待會增加延遲；是否可以改用旁路，必須回到這項要求允許什麼後果來決定。

流程七個位置都畫了，接下來要驗證哪一個？

不用先替七個位置各買一個模型（那樣 Cost & Lantency 太高）。團隊可以從一項有明確後果的要求開始，沿資料流確認最晚必須在哪裡攔截。

以下用四種失敗情境比較控制位置；這是一份測試設計，尚未執行：

蒐集證據時，也要避免為了證明沒有洩漏，反而把原始個資完整寫進測試報告與 Log。可以先使用合成資料驗證流程，正式環境的紀錄再依資料政策決定遮罩、存取權限與保留方式。

今天先把自己的 LLM 應用畫成一張資料流圖。選一項政策，標出資料或動作跨出哪一道邊界之後，才攔截就已經太晚；接著列出檢查需要的資訊，以及失敗時流程應停在哪裡。

到了這一步，下一個問題就會浮出來：「不要洩漏個資」到底限制誰、在哪個任務裡、把哪些欄位交給誰？Day 3 就從這句模糊要求開始，將政策拆成可以實作與測試的控制項 (Control)。

本日參考：
1. Context engineering in agents ｜ LangChain：來自 LangChain 的官方文件、是說明整個 LLM 應用調用週期中不同的可切入、接入時間點

2. NVIDIA Guardrails Types