n8n AI Agent HITL 安全指南：工具風險、最小權限與上線驗收

當 n8n AI Agent 不只負責整理文字，還需要透過工具寄送訊息、修改外部紀錄或執行其他高風險動作時，真正需要控制的通常不是「AI 說了什麼」，而是「它接下來要做什麼」。

n8n AI Agent 人工審核的核心做法，是把高風險工具設為需要核准：Agent 嘗試使用該工具時，工作流會暫停，等待人工審核者查看工具名稱與參數後決定核准或拒絕。核准後，工具才會依 Agent 指定的輸入執行；拒絕則取消這次動作，並把結果通知 Agent。這種做法特別適合寄送訊息、修改紀錄、刪除資料，以及涉及敏感資料寫入的動作。

不過，人工審核不是萬靈丹。它應和權限設計、輸入與輸出檢查、清楚的審核資訊，以及執行紀錄管理一起規劃，才能讓流程既可控，也不會把營運團隊困在大量低價值通知中。

本文定位：這篇聚焦 HITL 的安全治理、工具風險分級與上線驗收。若你要的是 Tools Panel、審核通道與核准／拒絕的實際設定，請看 n8n Human Review 設定教學；若你要先建立「AI 建議、規則驗證、人工決策」的整體流程架構，請看 n8n AI 自動化人工審核總體教學。

什麼情況該讓 n8n AI Agent 等待人工核准？

先用「動作後果」而非「是否使用 AI」判斷是否要加閘門。只要某個工具一旦執行，就可能對外造成承諾、改變正式資料，或難以回復，便值得納入人工審核範圍。

• 對外溝通：寄送客戶訊息、發送通知、回覆合作夥伴。
• 正式資料異動：建立、更新或修改外部系統中的既有紀錄。
• 破壞性操作：刪除資料或覆寫既有紀錄。
• 敏感資料寫入：將個人或商務敏感資訊寫入外部系統。
• 高影響決策：需要由主管、客服或法務確認措辭與處理方向的動作。

n8n 的官方文件指出，人工審核可套用到 AI Agent 的所有工具，也可只套用到選定工具。實務上，較好的起點通常是只攔截高風險的寫入型工具；查詢、草稿生成或內部摘要等低風險步驟，則可先不造成簽核負擔。

先分清楚：看 AI 輸出，還是攔截工具動作？

人工審核常被做成「Agent 產生一段文字後，請人讀一次」。這在內容品質檢查上有用，但若真正風險是訊息被送出或外部紀錄被改寫，應把核准點放在工具呼叫前。

若 AI Agent 要寄送訊息或修改外部紀錄，優先採用工具呼叫前的 HITL。因為 Agent 即使已產生看似合理的文字，只要收件者、紀錄識別值、欄位值或寫入範圍有誤，仍可能造成不希望的異動。

範例架構：從需求到核准後執行

以下用「客服需求進來後，Agent 擬定回覆並修改外部紀錄」作為設計範例。這是一個架構思考，而非把所有節點都串成單一路徑：

1. 接收需求：取得使用者訊息、工單內容或其他觸發資料。
2. 前置檢查：在資料送入 AI model 前，依需求使用 Guardrails node 驗證使用者輸入。
3. AI Agent 規劃：由 Agent 產生可執行的下一步，並選擇可用工具。
4. 高風險工具人工審核：將寄送訊息、修改外部紀錄或其他寫入工具設為需核准。
5. 核准後執行：只有審核者核准時，工具才依 Agent 提出的輸入執行。
6. 拒絕後處理：該動作取消，Agent 收到拒絕資訊；再依預先規劃的指示回應、改寫或交由人工處理。
7. 輸出使用前檢查：若工作流將使用模型輸出，可在使用前以 Guardrails node 檢查輸出，並視需要要求結構化欄位。
8. 檢視與稽核：依組織可用的功能與權限，規劃誰能查看執行資料與審核內容。

實作一：為寄送訊息、修改外部紀錄與寫入工具加上 HITL

n8n 的 HITL 機制針對的是 AI Agent 的工具呼叫。設定時，先盤點 Agent 可用工具，再為需要人工確認的工具啟用審核。官方列舉的典型高風險情境包含寄送訊息、修改紀錄與刪除資料。

建議先建立「工具風險清單」

不要一開始就讓所有工具都要求核准。請和實際業務負責人定義工具分級，將規則寫成可維護的清單。

表中的「建議」是工作流設計原則，不代表所有情境都能用同一套設定。尤其資料敏感度、憑證權限與外部系統的操作模型，仍要依你的組織規範逐項審視。

把審核規則寫進 Agent 的 system prompt

只在工具設定上開啟審核還不夠。官方建議在 AI Agent 的 system prompt 清楚交代：哪些工具需要人工審核、工具被拒絕後會發生什麼事，以及 Agent 應如何回應。

可調整的指示範例：
當需要使用「寄送客戶訊息」或「更新外部紀錄」工具時，請先提出完整且可審核的工具輸入。若該工具被拒絕，請不要嘗試以其他工具繞過這次動作；請根據拒絕資訊改為請求人工處理，或提出可供重新審核的替代方案。

這段文字不是安全保證，而是讓 Agent 在被拒絕時有一致行為。實際可用工具名稱、可接受的替代處理，以及是否允許重新送審，都應配合你的流程調整。

實作二：讓審核者看得懂工具名稱與參數

審核通知若只有「AI 要執行動作，請核准」，幾乎沒有判斷價值。n8n 的人類審核訊息可使用 $tool.name 與 $tool.parameters，呈現 Agent 擬呼叫的工具與其參數。這正是讓人工核准落在具體行動上的關鍵。

一則可用的審核訊息，應包含哪些資訊？

除了工具名稱與參數，建議把能協助判斷的資訊整理成固定版型。下列項目是資訊設計建議；實際可帶入哪些欄位，必須依你的工作流資料與個資規範決定。

• 原始需求摘要：這個動作要解決什麼問題？
• Agent 的行動說明：為什麼需要寄送、更新或寫入？
• 工具名稱：以 $tool.name 呈現。
• 實際工具參數：以 $tool.parameters 呈現，供核對收件者、紀錄目標與欄位值。
• 影響摘要：用人可快速理解的語句說明預計改變什麼。
• 風險旗標：例如對外寄送、敏感欄位、批次影響或不可逆操作等內部定義標籤。

審核訊息版型示意：
請審核 AI Agent 的工具呼叫。
工具：{{$tool.name}}
參數：{{$tool.parameters}}
請確認目標、內容與影響範圍是否符合本次需求，再決定是否核准。

若參數過長，審核者往往難以從原始 JSON 找出關鍵差異。可在送審前另外產生一段人類可讀摘要，但不要只給摘要、不給可核對的實際參數；兩者並列，才較容易發現收件者、紀錄識別值或欄位內容是否不合理。

實作三：核准、拒絕、未回覆與重新送審怎麼設計？

官方定義的 HITL 行為很明確：核准後，工具以 AI 指定的輸入執行；拒絕後，該動作取消，並通知 AI Agent。真正影響營運品質的，是你如何把這兩個結果接進後續作業規則。

核准：只執行已被審核的那次動作

核准代表審核者同意當前工具名稱與參數所描述的動作。因此，送審內容要足夠具體，避免把「核准某個大方向」誤當成「核准任意後續修改」。如果 Agent 需要改變收件者、更新不同紀錄，或大幅更動寫入參數，應將其視為新的待審核動作。

拒絕：讓 Agent 停止、說明或交接，而不是自行繞路

拒絕會取消工具動作並通知 Agent。請在 system prompt 事先定義拒絕後的行為，例如：

• 回覆內部人員：「此動作未獲核准，請人工接手。」
• 要求 Agent 根據拒絕原因提出新的草稿，供再次審核。
• 停止本次處理，不對外傳送任何內容。
• 把案件交給具決策權的人員處理。

關鍵是避免把拒絕視為技術錯誤，然後讓 Agent 改用未受審核的替代工具完成同一件事。能否使用替代工具，以及何時可重新送審，應由流程規則明確限制。

未回覆：先訂作業政策，再決定處理方式

不同審核通道與節點的可用選項不應一概而論。若你的流程需要提醒、多層核准或補件，應先把它們寫成作業政策：多久未回覆視為未處理、由誰接手、是否停止外部動作，以及何時才可重新送審。

對於 Gmail，官方文件中的 Send and Wait for Approval 會在收件者核准前暫停工作流，適合較簡單的簽核情境；若需要較複雜的簽核流程，官方建議使用 Wait node。這是一般工作流的簽核操作，不應把它延伸為所有通道都具有相同按鈕、未回覆處理或簽核能力。

降低風險：HITL 之外還要補哪些控制？

HITL 的作用是讓人確認受設定保護的工具呼叫，不是所有安全問題的替代方案。以下控制可讓人工審核更有效率，也縮小單一核准失誤造成的影響。

1. 限制工具參數與憑證權限

人工審核看得到參數，不代表參數本身一定安全。應盡量讓高風險工具只接受完成任務所需的欄位與範圍，並讓所使用的憑證僅具備必要權限。對外寄送、外部紀錄更新與其他寫入動作尤其要避免給予超出工作目的的操作能力。

若某些值應由工作流固定，例如允許的寄件身分、特定資料範圍或內部欄位，可將它們從 Agent 可自由決定的內容中分離。對於要交給 Agent 產生的值，則在審核通知中清楚呈現，讓人員能檢查其實際影響。

2. 用 Guardrails node 檢查輸入與模型輸出

Guardrails node 可在資料送進 AI model 前驗證使用者輸入，也可在工作流使用模型輸出前檢查輸出。其 Check Text for Violations 操作會把違規項目送往 Fail 分支；Sanitize Text 則會以預留字元取代偵測到的違規內容。

這類檢查適合用來建立明確的處理路徑：通過才繼續、違規則停止、轉人工或走其他內部流程。它不應被泛化為任何 Agent 架構都有固定的「前後插入」方式；請依你實際資料進入模型與使用模型輸出的節點位置配置。

3. 用 JSON Schema 約束要使用的輸出欄位

如果後續節點需要固定欄位，例如 action、recipient、recordId、reason 或 riskFlag，可考慮使用 Structured Output Parser，依 JSON Schema 定義輸出結構與驗證設定。

這能讓審核訊息與後續處理建立在較一致的欄位上，也能減少「一段自由文字直接被當成工具參數」的設計。欄位結構仍須配合工具可接受的輸入與你的業務規則審查，不能只因格式正確就直接視為內容正確。

4. 把高風險動作拆成可審核的子流程

當一個 Agent 同時負責判讀需求、產生草稿、選擇操作目標與寫入外部系統時，審核者很難快速確認所有責任。可考慮把工作拆成較清楚的階段：先取得與整理資料、再形成待執行方案、最後才送交具體工具動作審核。

拆分的目標不是增加節點數量，而是讓每一個核准點都有明確的輸入、影響與責任人。

稽核與隱私：Execution data redaction 能做什麼，不能做什麼？

人工審核會增加可供檢視的工具參數與工作流資料，因此執行紀錄的可見性必須納入設計。n8n 的 Execution data redaction 用於控制使用者檢視 execution 資料時可看到的內容。

但這項功能有重要邊界：它不限制節點之間的資料流、不會改寫外送請求，也不會加密或改寫資料庫中的 execution 資料。因此，資料遮蔽不能被視為資料不會送到下游服務的保證。若工作流本身不應傳送某項資料，必須在資料映射、工具參數與外送設計處理，而不是只依賴執行紀錄遮蔽。

官方文件目前說明，Execution data redaction 適用於 Enterprise Cloud 與 Enterprise self-hosted；每工作流遮蔽自 n8n 2.16.0 起可用，instance-level enforcement 自 n8n 2.26.0 起可用。由於其他治理、稽核與可觀測性功能的適用方案可能不同，導入前應逐項核對現行官方文件與你的部署條件。

避免通知疲勞：把人力留給真正需要判斷的案件

如果每一筆查詢、每一次草稿生成都要求核准，審核者很快就會習慣性點選同意，反而失去閘門意義。要讓 n8n AI Agent 人工審核可長期運作，可採用以下原則：

• 按風險攔截：優先審核對外、寫入、刪除與敏感資料相關工具。
• 提供差異資訊：讓審核者快速辨識目標、內容、寫入欄位與影響範圍。
• 定義例外規則：哪些案件必須升級、哪些案件只能停下等待人工處理。
• 限制重複送審：避免 Agent 因相同拒絕原因反覆產生近似請求。
• 定期回看拒絕原因：將常見拒絕轉化為更明確的 system prompt、欄位規則或工具限制。

n8n AI Agent 人工審核上線前驗收清單

請不要只測試「核准後能成功執行」。至少應以測試資料走過下列情境：

• 受審核工具被呼叫時，工作流是否確實等待人工決定？
• 審核通知是否同時呈現工具名稱、參數與足以判斷影響的摘要？
• 核准後，是否只執行已送審的工具動作？
• 拒絕後，是否確實取消動作，且 Agent 的後續回應符合既定規則？
• 審核者沒有回覆時，團隊是否知道何時停止、提醒或交由誰接手？
• 重送或重複事件是否會造成重複寄送、重複寫入或重複通知？
• 含有惡意指示、無關要求或不完整欄位的輸入，是否會走到預期的檢查與人工處理路徑？
• 審核訊息與 execution 資料中，是否出現不必要的客戶個資、密鑰或敏感內容？
• 工作流、憑證或節點設定調整後，是否重新測試核准與拒絕路徑？

結論：把「能不能執行」交給明確的工具閘門

n8n 的 AI Agent 人工審核最適合用在高風險工具呼叫前：Agent 提出工具與參數，工作流暫停，審核者確認後才決定是否讓動作執行。相較於只在最後閱讀 AI 回覆，這更貼近寄送訊息、修改外部紀錄與刪除資料等實際風險點。

要讓這套流程可用，請把重點放在四件事：只攔截真正高風險的工具、讓審核者看懂實際參數、事先定義拒絕與未回覆時的作業規則，以及以 Guardrails、結構化輸出、最小權限與資料可見性管理補足邊界。人工核准是重要控制點，但仍需要與整體工作流設計一起驗收與維護。