完成「Observability：一次流程跨 Agent、Tool、DB 要怎麼追」後，下一個問題是「Prompt Injection 到 Tool Abuse：企業 Agent 的真正攻擊面」能否重跑、否定並留下失敗原因。這就是今天的範圍。
以惡意 instruction、越權請求、工具參數操控測試系統，驗證 policy／RBAC／schema 是否真的擋住。
可以把系統拆成 Conversation／UI、Agent／Orchestrator、Tool layer、Policy layer、State store、Human Approval、Audit。模型可以決定下一個「提議動作」，但真正執行前仍需經 schema、policy 與權限檢查。
這樣的架構也方便觀測：一次 run 可以追到模型輸入、tool call、policy decision、database transaction 與人工核准，而不是只留下最後一句自然語言。
測試要包含越權要求、要求忽略 policy、操控 tool parameter、重複執行與惡意外部內容。預期結果不是「模型每次都拒絕」，而是即使模型判斷錯，RBAC、schema、policy 與 transaction 還能把副作用限制在安全範圍。
這個案例用「把惡意文字放進 raw request，嘗試越權呼叫 tool」檢查執行前後狀態、副作用與 audit event，再決定流程是否通過。
case = {
"action": '把惡意文字放進 raw request，嘗試越權呼叫 tool',
"expected_metrics": ('denials', 'policy reason', 'side effects', 'audit'),
}
before = load_state()
result = execute_case(case)
after = load_state()
assert result.final_state in {"SUCCEEDED", "REJECTED", "ESCALATED"}
assert side_effects_match_policy(before, after, result)
assert audit_matches(before, after, result.events)
驗證可從「把惡意文字放進 raw request，嘗試越權呼叫 tool」開始。每個案例都要固定 actor、權限、初始 state、輸入與 policy 版本，再檢查 decision、tool call、資料庫結果與 audit event。只檢查模型最後說了什麼並不足夠，因為流程可能回覆成功，實際上卻沒有提交；也可能回覆失敗，外部副作用早已發生。
這篇優先比較：denials、policy reason、side effects、audit。正常案例、拒絕案例與故障案例都要納入；符合規則的拒絕本身就是成功結果。遇到 timeout、重試或人工核准時，還要檢查流程能否從明確 checkpoint 繼續，且不會重複執行已完成的副作用。
所有可改變外部狀態的工具都應具備窄介面、輸入驗證、授權、冪等與稽核。高影響且不可逆的動作必須保留明確確認點。發生不確定狀態時，流程應停止並交由人工處理，不能依靠模型猜測先前是否已成功提交。
判讀順序應從最終 state 與外部副作用開始，再回頭閱讀模型訊息與 trace。若文字回覆看似合理，但權限檢查、資料庫狀態或 audit event 不一致，應直接判定流程失敗。相反地，policy 正確拒絕危險要求，即使任務沒有完成，也屬於控制機制成功。
單次流程通過後，還要重播相同 request、製造並行請求並在關鍵步驟中斷。這三類測試能分別檢查冪等、一致性與復原能力，也是 Agent 從展示走向正式流程前最容易被忽略的部分。
判讀不只看最大或最漂亮的數字。這一天真正要回答的是：prompt injection 不能跨越 typed、RBAC 與 policy gates。
如果核心指標改善，但錯誤率、尾端延遲、資源成本或恢復能力變差，這代表取捨，而不是無條件進步。相反地，沒有改善也不是無效結果；至少能排除一條看似合理、實際上不值得增加複雜度的路。
今天的工程判斷是：prompt injection 不能跨越 typed、RBAC 與 policy gates。無論結果支持或否定原本假設，都必須保留完整條件，才能和下一天的實驗串在一起。
下一篇將處理：Memory 與 Context：什麼該記，什麼不該塞進 Prompt。
iThome鐵人賽
看影片追技術