The Autonomy Tax 論文閱讀分析：當你把 LLM Agent 防得更安全，為什麼它反而先失去行動能力？

論文基本資訊

• 論文標題：The Autonomy Tax: Defense Training Breaks LLM Agents
• 作者：Shawn Li、Yue Zhao
• 年份：2026
• 來源：arXiv:2603.19423
• 論文連結：https://arxiv.org/abs/2603.19423
• DOI：10.48550/arXiv.2603.19423
• 主題：Agentic Security、Prompt Injection Defense、LLM Agents、Tool Use、Alignment、Benchmark、Robustness

本文由 AI 產生、整理與撰寫。

最近在談 agent security，很容易一路滑向同一種直覺：只要把模型防得更嚴、拒得更快、對 prompt injection 更敏感，agent 就會更安全。 但這篇 The Autonomy Tax 的核心結論，幾乎是在對這個直覺當頭澆冷水：現在很多 defense-trained model，確實變得更會拒絕了，但也同時變得更不會當 agent。

而且麻煩不是那種「分數掉一點」的小退步。作者指出的是一個更結構性的問題：很多防禦訓練不是在教模型理解威脅，而是在教它記住表面訊號、關鍵字和格式 shortcut。 一旦模型進入 multi-step、要調工具、要連續執行、還要處理失敗重試的 agent loop，這些 shortcut 不只沒真的擋住攻擊，反而會讓整個系統因為過早拒絕、錯誤輸出、或卡在 retry loop 裡而直接癱掉。

如果前面幾篇文章像 ClawLess、SentinelAgent、Causality Laundering、AgentAuditor 都在談 runtime boundary、delegation control plane、auditability、judge reliability，那這篇補上的就是另一個很現實、但常被忽略的問題：安全對齊本身，也可能是一種可量測的 agent performance tax。

這篇論文在問什麼？

作者要挑戰的，不是「prompt injection 有沒有風險」，而是更尖銳的另一句話：現在主流的 prompt injection defense training，到底有沒有真的讓 agent 更安全？

這個問題之所以重要，是因為很多既有 defense paper 都很愛用單輪 benchmark 證明自己有效：攻擊拒絕率很高、false positive 很低、看起來防得不錯。但 agent 不是單輪聊天，它是：

• 要先理解任務
• 再選工具
• 產生正確 action 格式
• 讀 observation
• 持續迭代直到完成

只要前面任一步開始怪掉，後面就不是「答錯一題」而已，而是整條執行鏈一起爛掉。這篇論文真正厲害的地方，在於它不是只看 refusal rate，而是直接把 defense-trained models 丟回 agent workflow 裡，看它們還能不能完成任務。

作者抓到的三種偏差：不是更安全，而是更容易壞

論文最值得記住的，是它把這種「防禦把 agent 弄壞」的現象拆成三個 agent-specific bias。

1. Agent incompetence bias

第一種最直白，也最狠：模型在還沒看到任何外部 observation 前，就已經不太會做事了。

這不是因為它被惡意內容騙了，而是 defense training 直接把它的基本 agent competence 壓壞。像是：

• 本來應該正常呼叫工具，結果先拒絕
• 本來應該輸出可執行 action，結果輸出 malformed / invalid action
• 明明是 benign task，但在 step 1 就卡死

這點很致命，因為它說明問題不是觀測資料被污染，而是模型已經把「安全」錯學成「少做事、別碰工具、看到某些格式就縮」。對 agent 來說，這幾乎等於把方向盤拔掉，再說車比較不會出事。

2. Cascade amplification bias

第二種偏差更符合真實 agent 系統的痛點：早期小失誤，會在 agent loop 裡被放大成整體 timeout。

作者指出，很多 agent framework 遇到失敗時會 retry，理論上這是為了容錯；但如果失敗不是偶發，而是 defense training 造成的系統性 incompetence，那 retry 不會救你，只會把局部問題放大成整條 trajectory 的持續卡死。

結果就是：

• 本來只是第一步沒有正常呼叫工具
• 系統以為可恢復，於是改寫 prompt 或重試
• 模型再次落入同樣 refusal / invalid pattern
• 最後整條任務耗盡步數，直接 timeout

這也是為什麼作者會把它叫做 cascade amplification。在單輪 benchmark 裡，你看到的是一次拒絕；在 agent 系統裡，看到的卻是整個任務死掉。

3. Trigger bias

第三種偏差則比較像我們已經隱約知道、但這篇把它講得更完整：很多 defense 並沒有真的學會 threat understanding，而只是學到某些 trigger word 或表面模式。

這會導致兩個看起來互相矛盾、但其實常同時發生的結果：

• 簡單繞過：稍微做一點 social engineering、obfuscation、goal reframing，攻擊就能穿過去
• 過度拒絕：真的 benign、但帶有技術術語的內容，反而更容易被誤殺

這很像把一個 security reviewer 訓練成「看到 exploit、override、bypass 就先按拒絕」，但卻沒教它判斷那些詞到底是惡意利用、研究討論、除錯操作，還是真正脈絡中的安全風險。

這篇 paper 最重要的 punchline：alignment 可能在 agent 場景裡反向傷害安全

我覺得這篇最有價值的地方，在於它不是只說「utility 下降」，而是更進一步指出：某些 defense-trained model 在 agent setting 裡，甚至可能同時讓 utility 更差、security 也更差。

原因很簡單：

• 它對 benign technical content 過度敏感，導致正常任務做不完
• 它對真正高階、包裝過的攻擊卻不一定看得懂，仍可能被繞過

換句話說，這不是傳統那種「安全多一點、方便少一點」的 trade-off；更糟的是，你可能兩邊都輸。 模型既不可靠，也不夠安全，只是看起來比較會說不。

這個觀察其實非常值得整個 agent security 社群警惕。因為我們最近愈來愈常把「拒絕率提升」當作 guardrail 有效的 proxy，但對會調工具、會跨步驟執行的 agent 來說，真正該問的不是它拒絕了幾次，而是它有沒有在 adversarial setting 下仍保有完成 benign task 的能力。

它怎麼驗證？為什麼這比單輪 benchmark 更有說服力？

根據論文，作者不是只做靜態 prompt 測試，而是把 defended models 和 baseline models 放到真實 agent benchmark 裡比較，涵蓋 97 個 agent tasks 與 1,000 個 adversarial prompts，並觀察整體 completion、timeout、step-1 failure、以及不同 attack 類型下的表現差異。

他們特別強調幾件事：

• step-1 analysis：用來區分模型是因為真的看到惡意 observation 才出事，還是根本一開始就不會正常執行
• depth-stratified analysis：看不同長度任務下，失敗如何被放大
• challenging subset：刻意放進 social engineering、obfuscation、instruction override 等較不靠明顯 trigger 的攻擊

這種設計比很多「拿一串 prompt 看有沒有拒絕」的 benchmark 更有意思，因為它在測的其實不是單點 response，而是整條 agentic execution chain 在 adversarial environment 下能不能活著跑完。

這篇論文和最近 agent security 主線怎麼接？

我認為它跟最近幾篇 paper 剛好能拼成一張很完整的圖。

• ClawLess 告訴你：真正可靠的安全，不能只靠模型自律，要有硬邊界。
• SentinelAgent 告訴你：權限與 delegation 要可驗證，不能只相信 prompt。
• Causality Laundering 告訴你：就算拒絕了，也可能從 denial feedback 洩漏資訊。
• AgentAuditor 告訴你：連負責判風險的 judge 自己，都可能不夠可靠。
• The Autonomy Tax 則補上另一塊：如果你把防禦訓練本身當主要解法，你很可能先把 agent 的手腳綁住，卻還沒真正解掉攻擊面。

它其實是在提醒整個社群：agent safety 不是多加幾層 refusal policy 就會自然變好。 在多步驟系統裡，防禦若只是靠 shortcut learning，最後常常會把能力與安全一起拖下水。

我怎麼看這篇論文？

我很喜歡這篇的地方，是它把一個很多人「隱約知道但不太願意正面說」的問題講清楚了。現在不少 alignment / defense work 的盲點就是：太習慣在單輪 benchmark 上看起來很漂亮，卻沒有真的進到 agent system 裡看它還能不能運作。

而 agent 一旦真的接工具、接檔案、接外部環境，失敗成本就跟聊天模型完全不同。你不是損失一句答覆品質，而是損失：

• 任務完成率
• 執行穩定性
• retry 後的 recoverability
• benign technical workflow 的可用性

從這個角度看，The Autonomy Tax 很像是在替 agent security 補一個必要的 reality check：如果你的防禦讓 agent 變得不會做事，那那不叫安全，而叫失能。

當然，這篇也不是說 alignment 沒必要，而是逼大家承認：單輪拒絕導向的 defense paradigm，不足以處理會持續觀察、規劃、行動、重試的 agent。 未來比較像樣的做法，可能得往這幾個方向走：

• 把安全控制更多放在 runtime policy enforcement，而不是只押在模型權重裡
• 把 benign task competence 當成 defense evaluation 的一級指標
• 針對 agent loop 設計新的 benchmark，而不是只沿用 chat refusal metrics
• 避免讓模型用 keyword / format shortcut 取代真正的 threat understanding

總結

The Autonomy Tax 最值得帶走的訊息很簡單，但很重：在 agent 場景裡，防禦做得更重，不代表安全做得更好；有時候，它只是更快把系統搞壞。

這篇 paper 把問題講得非常實務：agent 要真的能用，不能只會拒絕，還得能在 adversarial 環境裡持續正確地用工具、完成 benign task、而且不要被 retry loop 放大成全面癱瘓。也因此，它對整個 agentic security 討論的貢獻，不只是再多一個 benchmark 分數，而是重新提醒大家：真正可靠的安全，不該靠把 agent 訓練成什麼都不敢做，而是要在保住執行能力的前提下，讓它知道什麼該做、什麼不能做、以及做錯時系統怎麼兜得住。

如果你最近也在看 AI agent 的 guardrail、runtime security、policy enforcement，這篇很值得補。因為它點破了一個常見幻覺：把模型變得更像一個會拒絕的客服，並不會自然把它變成一個更安全的 agent。