當客服能直接建立申請、修改訂單或執行退款，Guardrails 就需要回答：這個 Agent 在這次任務中，被允許把流程推進到哪裡？
一段回覆可以沒有髒話、沒有洩漏個資，每句也都有來源支持，背後卻已經替顧客做了他沒有要求的變更。檢查文字內容，無法單獨判斷這次行動是否獲准。
前一篇談文件中的指令不能替服務授權。到了 Agent，這個區分要落在每一次工具執行，也要貫穿整段工作流程。模型可以提出下一步；哪些步驟能執行、何時能執行，必須由服務的權限與業務狀態約束。
假設一個退貨客服可以查訂單、查退貨資格、建立退貨申請，並在符合條件時交由退款服務處理。顧客問：
幫我看看這筆訂單能不能退貨。
這次任務是確認資格。即使查到符合條件，Agent 也不能因此自行建立申請，再把款項退回去。「可以退」是查詢結果，「要退」則是另一個決定。
若模型把這項需求理解成「幫顧客把退貨辦完」，生成的計畫可能很完整：查訂單、確認資格、建立申請、退款、告知完成。每一步都有對應工具，最後的回覆也很有禮貌，整段流程卻已經擴大了原本的委託。
這不必先有攻擊者。模型對模糊需求的解讀、過度積極的任務規劃，都可能造成這種結果。OWASP 的 LLM06:2025 Excessive Agency將過多功能、過大權限與過高自主性列為風險根因，也把非惡意提示下的模型錯誤納入考量。
因此，工具允許清單只能回答一部分問題。它可以限制 Agent 是否能呼叫退款工具，還需要確認目前任務是否包含退款、退款對象是誰，以及業務條件是否已經成立。
最小權限（Least Privilege）應跟著任務收斂。只提供資格查詢的服務，不需要建立申請與退款能力；支援完整退貨的服務，也需要限制這次任務能使用哪些能力。
把本例的規則再說清楚：資格查詢可以直接回答；顧客決定申請退貨後，才建立申請；商品驗收與退款條件由後端業務系統確認，客服不能因為申請成立，就宣布退款完成。這是本文的假設流程，實際服務需要依自己的規定設計。
這樣的預期工作流程（Expected Workflow），需要記住現在處於哪個階段，以及下一步的前提。
在資格查詢階段，即使模型已排出「建立申請」這個動作，執行端仍應把它停在待確認。如果顧客接著說「好，那就申請退貨」，流程可以開始準備申請；但這個授權仍然不能順便涵蓋更改退款帳戶，或跳過商品驗收。
狀態也要有可信來源。模型在摘要裡寫「顧客已確認」，不能直接變成後端的確認紀錄；工具回傳「申請已受理」，只能推進到已受理的階段，不能被改解讀為商品已驗收。若讓 Agent 同時產生前提、宣告前提成立，再決定自己可以執行，檢查就失去了獨立依據。
OWASP 的 Transaction Authorization 指引要求由應用控制允許的狀態轉換，避免交易授權步驟被跳過或打亂。延伸到這個 Agent 場景，設計重點是讓必要條件保持有效，而不是規定模型只能照著唯一一條工具順序走。
例如，查詢失敗後可以換一個已核准的資料來源，顧客也可以中途取消。這些都是流程內的合理分支。但建立退貨申請被拒絕後，Agent 若改用通用訂單修改工具，直接把訂單狀態改成「退貨中」，仍然是在完成同一個尚未獲准的變更。
需要限制的是業務動作及其前提。 若只封鎖某個工具名稱，另一個能造成相同結果的入口，就可能繞過原本的控制。
執行前驗證（Pre-action Validation）應把模型提出的工具呼叫，對回目前的使用者、任務、對象與流程狀態。身分來自登入與授權機制；訂單歸屬、可退項目與處理狀態來自業務服務。模型生成的參數仍需要驗證，不能因為格式正確就取得操作權限。
NVIDIA NeMo Guardrails 的 Execution Rails涵蓋工具呼叫、參數與結果的驗證。這提供了執行邊界上的控制方式，但退貨資格、帳戶權限與允許的流程轉換，仍需由應用及後端服務提供。
對需要人工確認的動作，還有一個容易被忽略的問題：確認的內容，能否一直對得上實際執行的內容？
假設顧客確認退回 A 商品，Agent 後續重新規劃，改成整張訂單一起退；即使對話裡留著一句「同意」，也不能沿用。執行端要核對這份確認屬於哪位使用者、哪個動作與哪些具體項目，而不是只相信工具參數中的 user_confirmed=true。
OWASP 的 AI Agent Security 指引也要求，授權在 Agent 上下文之外的執行元件驗證，並綁定實際動作、參數與有效期限。這讓確認紀錄有明確用途，也避免模型把一次同意擴張成後續所有動作都可執行。
確認之後，資料仍可能變動。例如同一筆申請已由另一個管道處理，再照先前狀態送一次，可能造成重複作業。業務服務應讓最後的條件檢查與實際狀態變更保持一致，例如使用交易或等效的原子控制，避免兩個請求同時通過後各自執行。對只能使用一次的批准，也要防止並行請求重複使用。
多問一次模型「這樣安全嗎」，無法替代這些執行系統的檢查。
回到一開始的資格查詢。如果 Agent 最後正確回答「符合退貨條件」，但在回答前先建立了申請，不能只看答案就判定它完成得很好。
NVIDIA SkillEvaluator 的評估面向把答案正確性、是否達成目標並遵循預期工作流程，以及是否避免不安全操作與未授權存取分開看。這個區分適合用來檢視本例：答對資格、照授權做事、避免越權，是需要分別確認的結果。
實際檢視時，需要把任務範圍、工具參數、當時的流程狀態、授權依據及業務結果接起來。若某一步被拒絕，還要往後看：Agent 是停在可處理的階段、向顧客澄清，還是換個工具完成了同一個被拒絕的動作？同一個任務裡的後續呼叫也要接起來看，才知道「退款工具已阻擋」之後，限制是否仍然有效。
同樣需要保留正常工作的能力。顧客只問資格，不必被要求批准整個退貨流程；已經確認申請且條件成立，就應能建立申請，而不是每一步都重新問同一句話。確認應放在新增承諾或改變操作範圍的地方，服務已知的條件則由系統核對。
從 Content 走到 Action，Guardrails 要保護的也包含系統中被查詢、修改或傳送的資料。對這個退貨客服，顧客需要的協助可能只是查明資格，也可能是完成一筆申請；判斷服務是否做好，應從這次委託開始。
Agent 可以安排合理的查詢與準備步驟，跨越業務階段時，則必須對得上有效的授權與流程狀態。把這條界線落在執行端，才不會讓「幫我看看能不能退貨」，在顧客還沒決定時，就變成一筆已送出的退貨申請。
iThome鐵人賽
看影片追技術