前面把授權從「這個 Agent 有沒有權限」往執行脈絡延伸之後，問題就不只剩下「怎麼判斷這一步合不合理」。
執行環境真的判斷出偏離之後，接下來要做什麼？
最直接的答案當然是擋下來。
但如果把 Agent 看成一個持續運作的迴圈，事情就沒有這麼簡單。
Agent 決定下一個動作 → Runtime 判斷 → 發現偏離 → DENY → 改變後續執行方式 → Agent 繼續決定下一步
這裡有一個容易被忽略的地方：
Runtime 的回應不是一個沒有副作用的判斷結果。
它可能中止執行、拒絕工具呼叫、要求人工確認，也可能把拒絕原因重新交給模型，讓 Agent 繼續規劃。
一旦回應會改變後面的執行狀態，它本身就成了 Agent 控制流程的一部分。
前面討論動態授權時，我們把授權看成 Agent 和工具之間的一道控制點。現在對這個控制點的後續進行觀察。
假設 Agent 原本擁有：
capability_t → read_customer / send_email / create_report
某次執行時，Runtime 發現目前的動作和任務脈絡不符。
這時候「拒絕」其實有很多種做法：
偏離 → DENY → 直接停止
偏離 → DENY → 拒絕原因交回模型 → 繼續執行
偏離 → DENY → 要求人工確認
偏離 → DENY → 縮減後續可用能力
這不是單純的概念分類，實際的 Agent Framework 已經存在這些不同的執行語義。
例如 OpenAI Agents SDK 的工具防護機制，就區分 allow、reject_content 和 raise_exception。其中 reject_content 會拒絕工具呼叫或輸出，但把訊息交回模型並繼續執行；raise_exception 則會直接中止執行。工具本身也可以設定需要人工核准，或設定工具執行的 timeout。
所以同樣是「安全檢查沒有通過」，最後產生的控制流可能完全不同。
Runtime Check
│
┌───────────┼───────────┐
↓ ↓ ↓
ALLOW REJECT HALT
│
↓
message → model
│
↓
replan
這裡才開始出現真正要處理的問題。
如果拒絕結果會重新進入 Agent 的控制迴圈，那麼攻擊者是不是也有可能利用這個回應？
這件事和「偵測器會不會判錯」已經不是同一個問題了。
傳統入侵偵測系統很早就已經注意到，偵測到攻擊之後並不是「擋掉就好」。
自動化回應可能本身帶來成本，例如中斷服務、修改系統狀態，或讓正常使用者受到影響。因此 Intrusion Response 的研究會把攻擊造成的損害、回應成本和系統運作成本一起納入考量。這個觀念放到 Agent 上，會變得更直接。
如果 Runtime 每次發現偏離就採取強烈反應：
偵測偏離 → 撤銷能力 → 重新規劃 → 再次檢查
那麼攻擊者只需要思考另一個問題：
我要怎麼讓這個回應一直發生？
這時候，攻擊目標不一定是讓 Runtime 放過惡意動作，也可以反過來讓 Runtime 過度防禦。
這種攻擊其實已經在一般 LLM 的安全防護機制中被實際研究過。
一篇針對 LLM Safeguard 的研究發現，攻擊者可以利用 False Positive，讓原本安全的請求被安全模型錯誤拒絕。研究中的白箱攻擊可以產生大約 30 個字元的對抗式內容，在 Llama Guard 3 的實驗中讓超過 97% 的正常使用者請求被錯誤阻擋。
它的攻擊流程很簡單：
攻擊者控制一小段輸入 → 讓 Safeguard 誤判 → 正常請求被拒絕 → 服務無法正常使用
這裡要把證據邊界說清楚。
這篇研究證明的是：
安全防護機制的 False Positive 可以被利用形成 DoS。
它並沒有證明：
Agent Runtime 的動態撤權一定可以用同樣方式攻擊。
前者是研究結果，後者是把相同攻擊邏輯放進 Agent Runtime 後，可以進一步驗證的方向。
不過，Agent 的情況又多了一層。因為 Agent 的安全控制不一定停在「拒絕這一次請求」。
它可能改變下一次模型呼叫、工具選擇，甚至整個後續執行流程。
這個問題現在已經不只是類比。
2026 年的一項研究 From Shield to Target: Denial-of-Service Attacks on LLM-Based Agent Guardrails，直接把 Agent Guardrail 當成攻擊目標。
研究發現，攻擊者可以把特製資料放進 Agent 會處理的內容裡，讓 Guardrail 自己陷入長時間的推理迴圈。
在獨立 Guardrail 測試中，攻擊造成約 13–63 倍的 Token Amplification；放進實際的 Web、Desktop、Code 和 Multi-Agent 系統後，延遲最高增加約 148 倍。研究還指出，一份被污染的文件就可能耗盡共享的 Guardrail 資源，進而影響其他 Agent。
攻擊者甚至不需要讓 Agent 做出錯誤答案。
真正被消耗的是：
Token
Latency
Shared Compute
所以攻擊流程變成：
惡意資料 → Agent → Guardrail → Guardrail 花費大量資源 → Runtime 變慢 → 其他正常 Agent 受到影響
這和傳統的「繞過防禦」不太一樣。
攻擊者不是想讓防禦失效，而是想讓防禦本身變得昂貴。
這讓「回應有成本」不再只是傳統 IDS 的抽象概念。在 Agent 裡，成本可以直接表現在 Token、延遲、工具呼叫次數，以及共享 Runtime 資源上。
前面討論參照機制時，問題是：
如果 Runtime 用來判斷「正常」的參照被污染，會發生什麼？
假設歷史行為被攻擊者污染，Runtime 可能逐漸把不正常的行為當成正常。
攻擊者 → 污染參照 → 偏離被隱藏 → Runtime 放行
這是參照本身被利用。
現在把視角反過來。
如果攻擊者不能讓 Runtime 放行，卻可以一直讓 Runtime 判定「這裡有問題」，就可能得到另一種結果：
攻擊者 → 製造偏離 → Runtime 判定異常 → 執行被阻擋 → 正常任務失敗
兩者的攻擊方向不同。
前者想讓攻擊看起來正常，後者想讓正常執行看起來像攻擊。
所以真正值得注意的不是單純把偵測器調得更嚴格或更寬鬆，而是：
同一個安全判斷一旦接上 Enforcement，就同時擁有了「放行風險」和「誤擋成本」。
AgentDojo 的實際評估也採用類似的雙面觀察方式。它不只記錄攻擊成功率，也同時量測正常任務的 Utility 與受到攻擊時的 Utility。公開結果中，tool_filter 在其中一組結果裡把 Targeted ASR 從 34.50% 降到 6.84%，但 Utility Under Attack 也從 57.71% 下降到 56.28%。
這不能證明某個防禦一定造成 DoS，卻說明了一件比較實際的事情：
Agent 防禦不能只看「擋住多少攻擊」，還要看正常任務付出了多少代價。
傳統的請求通常比較容易理解。
收到請求 → 判斷 → 拒絕 → 結束。
Agent 則不一定。
它原本就是：
決定 → 工具 → 取得結果 → 重新決定 → 工具 → 取得結果 → ...
所以當 Runtime 回傳拒絕結果時，真正重要的是：
這個拒絕會不會重新進入下一輪決策？
實際的 Agent Runtime 已經存在這種設計。例如 OpenAI Agents SDK 可以把某些工具錯誤回傳給模型，讓模型重新選擇其他可用工具或改變回答，而不是直接讓整個 Run 結束。工具防護機制中的 reject_content 也採取類似「拒絕這次操作，但繼續執行」的語義。
所以不能把：
DENY
直接等同於：
STOP
比較準確的描述應該是：
Runtime 判斷 → DENY → HALT
├──→ HUMAN APPROVAL
└──→ 回傳拒絕結果 → Model → Replan
一旦走到最後一條路，Runtime 的安全決策就重新進入 Agent 的控制迴圈。
這裡會出現兩種值得區分的風險。
第一種是繞行。
Agent 收到拒絕之後，可能改用另一個工具、換一組參數，或者重新安排執行順序。如果 Runtime 只是拒絕原本的動作，而沒有處理重新規劃後的整體路徑，Agent 可能繞到另一條沒有被預期的路徑。
這目前比較適合當成工程上的推論，而不是直接宣稱「所有 Agent 都會繞行」。實際會不會發生，取決於 Runtime 如何把拒絕結果交回模型，以及下一輪是否會重新套用相同的控制條件。
第二種是重複執行。
如果每次拒絕都會觸發重新規劃，而新的規劃又再次被拒絕，就可能出現：
Action → DENY → Replan → Action' → DENY → Replan → Action'' → ...
這裡也不能直接說「DENY 一定會造成震盪」。但 Agent 本身存在這種無限回饋路徑的問題，已經有獨立研究進行實際分析。
2026 年的 When Agents Do Not Stop 研究分析了 6,549 個 LLM Agent repositories，經人工確認後找到 47 個專案中的 68 個 Infinite Agentic Loop failures。研究指出，這些迴圈可以反覆觸發 Model Call、Tool Call、Workflow Transition 或 Agent Handoff，進一步造成成本耗盡、模型 DoS、Context 增長和重複的外部副作用。
因此目前可以很精確地分成兩件事：
Agent Loop 本身可以形成資源消耗問題，這已經有研究證據。
但：
「Runtime 的 DENY → REPLAN 正好造成這種 Loop」仍然需要針對具體 Runtime 做實驗。
這兩句不能混在一起。
而且真正需要注意的，不只是模型自己反覆思考。
Agent 和工具之間的來回呼叫，本身就是另一條回饋路徑。
一項針對 Agent Tool Calling Chain 的研究 Beyond Max Tokens，展示了一種更接近實際 Agent Runtime 的資源放大攻擊。
攻擊者控制的是一個符合 MCP 規格的惡意工具伺服器。它不需要改變工具的 Function Signature，也不需要讓最後的任務結果錯誤，而是利用工具回傳內容，把 Agent 引導進非常長的工具呼叫序列。
實驗中，部分 Trajectory 超過 60,000 Tokens，成本最高放大到約 658 倍；GPU KV Cache Occupancy 從低於 1% 上升到 35–74%，共同執行的 Throughput 最多下降約 50%。更麻煩的是，Agent 最後仍然可能產生正確的任務結果。
流程可以簡化成：
惡意 Tool Server → Tool Result → Agent → 下一次 Tool Call → Agent → 下一次 Tool Call → 大量 Runtime 成本
這個案例對今天有一個很重要的提醒：
Availability Attack 不一定長得像「系統報錯」。
如果最後答案還是對的，但完成這個答案原本只需要 10 次工具呼叫，攻擊後卻需要幾千次，那麼從服務成本的角度來看，系統一樣已經受到攻擊。
這也是為什麼 Agent 的安全控制不能只看最後輸出。
要看的還包括：
Tool Call Count
Retry Count
Replan Count
Token Usage
Latency
Execution Time
這些才是 Runtime 實際付出的成本。
這對回應的設計意味著什麼？
看到這裡，我不會直接得到「偵測到偏離就不要阻擋」這種結論。問題不是要不要回應，而是回應的強度和後續控制方式怎麼決定。
最簡單的做法，是把所有異常都當成同一種：
異常 → DENY → STOP
但這會讓一次誤判直接變成整個任務失敗。
另一個極端則是：
異常 → 記錄 → 繼續
這又可能讓真正的攻擊繼續執行。
因此比較合理的方向，是把「偵測到偏離」和「要採取多強的回應」拆開。
例如：
偏離 → 判斷證據強度 → 低信心 / 可恢復 → REJECT + CONTINUE / REVIEW
高信心 / 高風險 → HALT / REVOKE / HUMAN
一次拒絕的成本，和一次拒絕後還會發生什麼，是 Runtime 設計的一部分。
而且實際 Framework 已經提供了一些可以控制這種成本的機制，例如工具 Timeout、人工核准，以及限制 Agent Run 的執行範圍。另一個值得注意的訊號是重複事件。
如果同一個執行來源一直得到：
DENY → DENY → DENY → DENY
它不應該直接被當成「攻擊已經證明」。因為正常任務也可能需要多次調整。
但這至少可以成為 Runtime 的一個監控訊號：
Deny Count ↑
Retry Count ↑
Replan Count ↑
Execution Time ↑
當這些數字一起上升時，系統真正看到的已經不只是一次異常，而是一個可能正在持續消耗資源的執行模式。至於這些指標要如何組合成可靠的 DoS 偵測器，目前仍然需要實驗驗證，不能只靠概念推論。
感謝大家今日份的閱讀。
allow、reject_content、raise_exception 等實際執行語義。
iThome鐵人賽
看影片追技術