TraceSafe 論文閱讀分析：當 AI Agent 的風險不在最後一句，而是藏在整條工具呼叫軌跡裡

論文基本資訊

• 論文標題：TraceSafe: A Systematic Assessment of LLM Guardrails on Multi-Step Tool-Calling Trajectories
• 系統名稱：TraceSafe / TraceSafe-Bench
• 作者：Yen-Shan Chen、Sian-Yao Huang、Cheng-Lin Yang、Yun-Nung Chen
• 年份：2026
• 來源：arXiv:2604.07223
• 論文連結：https://arxiv.org/abs/2604.07223
• DOI：10.48550/arXiv.2604.07223
• 主題：Agentic Security、Guardrails、Tool-Calling Agents、Trajectory Safety、Benchmark、Runtime Risk Detection

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

如果說前面一整串 agent security 論文，已經把大家的注意力從 prompt、memory、skills、MCP 一路往 execution surface 推，那 TraceSafe 這篇最值得補上的問題就是：當風險不出現在最後一句回答，而是藏在中途的多步工具呼叫軌跡裡，你今天那些 guardrail 到底有沒有真的看懂？

這個問題很關鍵。因為不少 safety / security guardrail 到現在還是在「輸入一句話、輸出一句話」的世界裡被測試：看模型會不會回危險內容、會不會被 jailbreak、會不會講出不該講的東西。但 agent 真正麻煩的地方，從來都不是它最後回了什麼，而是它在過程中讀了什麼、選了什麼 tool、把什麼資料帶進下一步、又在什麼情境下繼續做錯事。

TraceSafe 的核心貢獻，不只是再做一個 benchmark，而是把「mid-trajectory safety」正式拉成一個獨立問題。 換句話說，作者不是在問「模型最後有沒有說錯話」，而是在問：整條 tool-calling trajectory 裡，guardrail 能不能在事情還沒做完之前，就辨識出這條執行鏈已經開始歪掉？

這篇論文想補哪個洞？

作者的出發點非常直接：LLM 變成 agent 之後，主要攻擊面會從 final response 轉向 intermediate execution trace。也就是說，安全風險不再只表現在最後輸出的自然語言，而會表現在一連串中間行為：

• tool description 或 tool output 被注入後，模型開始偏離原始任務；
• 敏感資料在某一步被讀進 context，接著在後面幾步被合理化地帶出去；
• 模型在多步流程中產生 hallucination、介面誤解、參數錯配，但表面上還像是在正常工作；
• 真正危險的 signal 不是最後一句，而是前面幾步逐漸累積出來的 execution pattern。

問題是，現在很多 guardrail 還是針對單輪對話、單次輸出、或明顯 jailbreak 訊號在設計。這就造成一個很尷尬的落差：你以為自己在保護 agent，實際上你保護得最完整的，可能只是它最後那句自然語言包裝。

TraceSafe 要處理的，正是這個評測真空。作者提出 TraceSafe-Bench，把 agent 的安全檢查從「一句回答」拉進「整段軌跡」，專門測 guard models 與 guardrails 在多步工具呼叫過程中能不能辨識中途風險。

TraceSafe-Bench 在測什麼？

這個 benchmark 的定位很清楚：它不是一般 chatbot safety benchmark，而是專門對準 multi-step tool-calling trajectories。論文整理了 12 類風險、超過 1,000 個 execution instances，範圍從明確的安全問題一路涵蓋到 operational failure：

• security threats：像是 prompt injection、privacy leakage 這種大家已經熟悉的風險；
• operational failures：像 hallucination、tool interface inconsistency、流程中途理解錯誤這類更像 execution reliability 的問題。

這個設計我覺得很對。因為 agent 世界裡，安全失敗和執行失敗其實常常不是兩個問題，而是同一條軌跡不同階段的表現。 一個模型如果看不懂 tool schema、讀不清 JSON、搞錯前一步回傳值，最後很可能不只是 task failure，還會把原本可以攔下的風險一路放大成真正的資料外洩、越權操作或錯誤決策。

換句話說，TraceSafe 其實在提醒一件很多人還沒完全接受的事：agent safety 並不只取決於價值對齊或拒答能力，它也取決於模型有沒有足夠的「結構理解能力」去讀懂這條執行軌跡到底發生了什麼。

它評了哪些 guardrail？

作者在 benchmark 上評估了 13 個 LLM-as-a-guard 模型 與 7 個專門 guardrails。這點很重要，因為它不是只拿一兩個安全模型來做 demo，而是真的把「通用 LLM 當 judge」和「號稱專門做防護的 guardrail」放到同一個軌跡分析場景裡對照。

而這組對照，剛好把目前 agent security 很多產品與研究都不太想面對的事揭露出來：在多步工具軌跡裡，guardrail 的成敗，未必主要取決於它有多懂安全，而是它有多懂這條軌跡的結構。

第一個核心發現：真正卡住 guardrail 的，常常不是安全對齊，而是結構理解

TraceSafe 最有殺傷力的一個結論，是作者所說的 Structural Bottleneck。論文發現，guardrail 在這類軌跡分析任務中的表現，和 structured-to-text 類能力高度相關，相關係數達到 ρ = 0.79；反過來看，和大家常拿來談安全性的 jailbreak robustness 幾乎沒有明顯相關。

這個結果很值得記住。它等於在說：很多 guardrail 不是因為不夠「安全」，而是因為它根本沒把 execution trace 看懂。

這件事一旦放進 agent 場景，含義非常現實：

• 如果 guardrail 看不懂多層 JSON、tool call arguments、return values、前後步驟依賴，
• 那它就算在一般 jailbreak benchmark 上表現很好，
• 到了真實 agent workflow 裡，還是可能連風險在哪一步開始發生都抓不到。

這其實也呼應最近幾篇 runtime / tool-calling paper 的共同訊號：agent security 的瓶頸，正在從內容審查轉向 execution literacy。 你不只要知道什麼叫危險內容，還得知道眼前這條工具互動鏈現在是不是已經開始形成危險狀態。

第二個核心發現：架構比模型大小更重要

論文第二個很有意思的結論是 Architecture over Scale：在 trajectory risk detection 上，模型架構的重要性高於單純參數規模，而且不少 general-purpose LLMs 的表現還優於專門設計的 safety guardrails。

這個結果有點刺耳，但也很合理。因為多步 tool trajectory 本身就是一種混合任務：它同時需要讀結構、做關聯、維持跨步驟記憶、判斷上下文是否漂移、辨識哪一步只是 harmless noise、哪一步已經造成 policy-relevant change。這不只是「看到危險字眼就擋」那麼簡單。

換句話說，如果 guardrail 的整體架構不適合處理長軌跡、多格式、跨步驟依賴，即使它名字叫 safety model，也不代表它真的比較會守 agent。

這篇 paper 其實間接挑戰了一種很流行的想像：只要再疊一層 safety wrapper，agent 就會比較安全。TraceSafe 的答案比較像是：未必。若那層 wrapper 自己不具備讀懂 execution trace 的能力，它可能只是多了一層看起來很安心的裝飾。

第三個核心發現：步驟變長，不一定比較糟

一般直覺會覺得，trajectory 愈長，guardrail 愈容易失準。但 TraceSafe 的第三個發現反而更有意思：在較長的 execution trajectories 中，risk detection accuracy 沒有明顯崩掉，甚至在某些情況下還會提升。

作者把這點概括成 Temporal Stability：隨著步驟增加，模型有機會從一開始只盯 static tool definitions，慢慢轉向觀察 dynamic execution behaviors，因此在後段反而更容易辨識出風險模式。

我覺得這個結論很有意思，因為它打破了一種常見假設：長軌跡一定只是 context burden。TraceSafe 提醒我們，長軌跡同時也是證據累積。 如果 guardrail 架構夠好，它不只能承受更長的軌跡，還可能因為看到了更多 execution evidence，而更準確地判斷事情是否正在失控。

當然，這不代表長鏈一定安全，而是代表另一件更重要的事：真正該優化的，也許不是一味縮短 agent workflow，而是提升 guardrail 對長軌跡證據的讀取與聚合能力。

我怎麼看這篇論文？

我認為 TraceSafe 最有價值的地方，在於它把一個很容易被忽略、但其實已經愈來愈核心的問題講清楚了：agent 的安全，不只發生在 output layer，而是發生在 trajectory layer。

這篇 paper 最值得記住的，不只是它提出了一個 benchmark，而是它把三件事釘得很牢：

• 第一，mid-trajectory risk 是獨立且必要的評測面向。 只看最終回答，會漏掉大量已經在中途發生的風險累積。
• 第二，guardrail 的核心能力之一其實是結構閱讀與執行理解。 沒有這個能力，談再多安全 alignment 都可能只是表面防護。
• 第三，agent defense 不能只靠單步、單訊號、單層攔截。 真正要守的是整段 execution trace 中風險如何生成、擴散與被合理化。

它也有清楚的限制。TraceSafe 主要仍是 benchmark 與 assessment work，不是完整的 production runtime defense system；它告訴你現在的 guardrails 哪裡不夠，但沒有直接把整條工程落地路徑都補完。另外，benchmark 裡的風險類型雖然已經比單輪對話真實很多，但距離企業裡那種跨 SaaS、跨身份、跨長期記憶、跨 session 的 agent workflow，顯然還有進一步擴展空間。

但這不太影響它的價值。因為它至少把方向掰正了：如果你今天還在用傳統 chatbot safety 的眼鏡看 agent guardrails，你很可能會高估自己已經守住的東西。

總結

TraceSafe 這篇論文最重要的提醒是：在 tool-calling agent 世界裡，風險常常不是一句危險回答，而是一條逐步成形的危險軌跡。 因此，guardrail 若只會看最終輸出、只會抓表面 jailbreak、或只會辨識明顯惡意字樣，很可能剛好錯過 agent security 最值得攔的那一段。

TraceSafe-Bench 把這件事量化了，而且結論相當明確：真正限制 guardrail 的，不只是 safety alignment，而是它有沒有能力讀懂結構、追蹤步驟、理解 execution context，並在軌跡中途就看見風險正在形成。

如果說最近那串 paper 已經把大家從 prompt security 帶向 runtime security，那 TraceSafe 更像是在往前推一步：runtime security 不能只看 action 有沒有被執行，還得看整條 trajectory 裡的風險是怎麼一步一步長出來的。