RouteGuard 論文閱讀分析：很多 skill 供應鏈真正缺的，不是再多掃幾個關鍵字，而是看出 agent 是不是已經被帶走

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

論文基本資訊

• 論文標題：RouteGuard: Internal-Signal Detection of Skill Poisoning in LLM Agents
• 作者：Wenjie Xiao、Xuehai Tang、Biyu Zhou、Songlin Hu、Jizhong Han
• 年份：2026
• 來源：arXiv:2604.22888
• 論文連結：https://arxiv.org/abs/2604.22888
• DOI：10.48550/arXiv.2604.22888
• 主題：Agentic Security、Skill Poisoning、Prompt Injection、AI Supply Chain、Runtime Detection、Mechanistic Signals

如果前面幾篇 sectools.tw 已經一路把 agent skill 供應鏈、indirect prompt injection、tool governance、runtime control 這幾條線慢慢接起來，那這篇 RouteGuard 值得補上的位置很清楚：很多 skill 供應鏈真正缺的，可能不是再多掃幾個可疑字串，而是先看出 agent 的內部控制權是不是已經被那份 skill 偷偷帶走。

當惡意內容不是躲在網頁、log 或檔案裡，而是躲在一份本來就長得像「正當操作指南」的 skill 描述裡，光靠表面文字過濾通常會太慢，也太瞎。

這篇 paper 要打的，不是一般的 prompt injection，而是更貼近 agent 生態的 skill poisoning：攻擊者把惡意指令藏進 skill 的說明、description、frontmatter 或使用範例裡，讓 agent 在安裝或引用 skill 時，把惡意內容當成合法能力說明的一部分，最後被重新導向。

這篇在解什麼問題？

作者一開始就抓到 skill poisoning 和一般 indirect prompt injection 的差別：skill 本身就是 instruction-like carrier。

這差別很關鍵。一般 indirect prompt injection 的惡意內容常常混在比較像資料的東西裡，例如：

• 網頁內容
• email
• log
• RAG 文件

但 skill 不一樣。skill 本來就會寫：

• 這個能力什麼時候用
• 應該怎麼用
• 哪些步驟要優先
• 遇到什麼情況要做什麼判斷

也就是說，良性 skill 和惡意 skill 天生就共享「會指揮 agent」這個語氣與功能。 這讓 keyword scanner、pattern matcher，甚至只看表面語義的分類器，很容易在最重要的地方失手：它們看得出「這是一段指令」，但看不出「這段指令已經在偷改控制權」。

作者的核心觀察：skill poisoning 會留下 attention hijacking 的內部痕跡

這篇最有意思的地方，是它沒有停在「再做一個更聰明的文字分類器」，而是先問：當 agent 真的被 poisoned skill 帶偏時，模型內部到底發生了什麼事？

作者的答案是：attention hijacking。

他們發現，當 skill 裡藏有惡意指令，而且這些指令真的成功影響 agent 後續回應或決策時，模型在生成回應時，注意力會更明顯地從 trusted context 轉移到那個惡意 skill span。這個現象還有幾個特性：

• 越早注入，越容易搶到控制權
• 藏在 description channel 時更難被表面方法抓到，但內部偏移更明顯
• attention shift 越大，越常伴隨 harmful output

這個 framing 很重要，因為它把 skill poisoning 從「文字有沒有長得像攻擊」改寫成「模型的控制路由有沒有被惡意內容接管」。

RouteGuard 怎麼做？不是只看字，而是看 route

RouteGuard 的設計邏輯很乾脆：既然問題是控制權競爭，那檢測器就不該只看表面文本，而要看回應生成時，模型的內部 routing 與表示是不是正在偏向不可信 skill 區塊。

整個方法大概有四層：

1. 先把 skill 切成可觀測的 chunk

作者不是把整份 skill 當單一長字串處理，而是用 hierarchical chunking：frontmatter、Markdown 標題、段落窗格都拆開。這樣做的原因很實際：如果你只看整份文件，很難知道模型到底被哪一塊帶走；切 chunk 後，才看得到哪個 window 正在變成控制中心。

2. 用多種 agentic probes 去逼出「它打算怎麼用這個 skill」

RouteGuard 不只問模型一個 generic prompt，而是用多個 probe 去看 skill 在不同情境下會怎麼影響回應，包括：

• 一般回答
• skill invocation decision
• safe-use planning
• execution-boundary reasoning

這一步很像是在問：這份 skill 不只是看起來怎樣，而是在 agent 真要拿它做事時，會怎麼改變推理路徑。

3. 兩個 expert：一個看 attention，一個看 hidden-state alignment

RouteGuard 的核心不是單一訊號，而是兩個 internal experts：

• Attention expert：看回應 token 的注意力是不是異常集中到某個不可信 skill chunk，並觀察最強 chunk、top-window margin、entropy 等特徵。
• Hidden expert：看回應表示是不是在語義空間裡更靠近某個 untrusted window，而不是 trusted instruction。

白話講就是：

• 一個在看模型「眼睛往哪裡飄」
• 另一個在看模型「腦袋最後靠向誰」

這兩者合起來，比單看字面內容更接近真正的控制權轉移。

4. reliability-gated late fusion：不要假設永遠只有一種訊號最準

作者沒有硬把兩種 expert 等權平均，而是用 reliability-gated fusion，把 validation reliability、sample-wise confidence、probe consistency 與 internal intensity 一起納入。

這個決定其實很合理。因為 skill poisoning 不一定永遠是同一種樣子：

• 有的 payload 比較像 routing hijack
• 有的 payload 比較像語義滲透
• 有的 chunk 很刺眼
• 有的 chunk 表面超正常，卻在 representation space 裡很危險

所以最好的 detector 不該迷信某一種訊號，而該根據樣本本身調整權重。

實驗結果最值得看哪裡？

這篇 paper 的亮點，不只是 global average，而是它在最難那一刀上的表現。

作者用了多個 benchmark 與真實惡意 skill 語料來測，整體結論是：RouteGuard 是少數能在不同 skill benchmark 上都維持穩定強勢的 detector，而不是只在某一種資料風格上好看。

幾個我覺得最值得記的數字：

• 在最關鍵的 Skill-Inject channel slice 上，RouteGuard 的 F1 達到 0.8834
• 它能補回 90.51% 被 lexical screening 漏掉的 description-channel 攻擊
• 在真實惡意技能語料 MaliciousAgentSkillsBench 上，RouteGuard 的 F1 為 0.7867，明顯高於傳統 IPI 偵測器基線
• 在回測到一般 indirect prompt injection benchmark BIPIA 時，RouteGuard 仍能維持可用 transfer，而不是只對 skill 場景過擬合

其中最值得重看的其實不是 0.8834 這個數字本身，而是它出現在 description channel。因為這正是最像真實 skill 生態的地方：惡意內容不是大剌剌寫成「請忽略之前所有規則」，而是混在那種看起來像 best practice、usage hint、safety note 的段落裡。

如果 detector 在 description channel 還能站得住，才比較像真的有碰到 skill poisoning 的核心難題。

這篇最值得 sectools.tw 讀者記住的，不是分數，而是 threat model 被重新畫對了

我覺得這篇 paper 真正厲害的地方，是它逼大家承認一件事：

skill poisoning 不是「比較特殊的 prompt injection 文本分類問題」，而是「惡意指令在 instruction-like carrier 裡競爭控制權」的問題。

一旦你接受這個 framing，很多防線思路就會跟著變：

• 你不能只靠 regex 或 keyword blacklist
• 你不能只看 skill 表面語義是否「有點奇怪」
• 你要開始在 agent 真正做決策前，看它的內部控制流是否已經被某段 untrusted 指令重新路由

這和前面幾篇在講 lifecycle security、semantic privilege separation、tool governance、goal integrity 的文章，其實是同一條主線的更細部延伸：真正該防的，往往不是某一段壞文字，而是那段文字什麼時候開始接手系統下一步的決定權。

這篇也有邊界，別把它看成萬靈丹

當然，RouteGuard 也不是沒有代價。

作者自己就承認，這是一個 pre-execution detection 研究，不是完整 live-agent prevention system。它還有幾個現實邊界：

• 需要看模型內部訊號，不是所有封閉 API 都拿得到
• 多 probe + 多 chunk 代表成本會比純文字掃描高
• 不同 backbone 的 internal signal 穩定度，之後還要更大範圍驗證
• 它解的是「裝之前 / 用之前先攔」，不是整個 runtime 永久免疫

所以比較合理的定位不是「從此 skill poisoning 解決了」，而是：如果你的 agent 生態真的有 reusable skills、marketplace plugins、shared tool bundles，那 text-only screening 大概已經不夠，而 internal-signal detection 是很值得補上的新層。

結語

RouteGuard 這篇論文最值得記住的，不是它又多做了一個 AI detector，而是它把 skill 安全這件事講得更精準了：當惡意內容躲在一份本來就該指揮 agent 的 skill 文件裡，問題就不再只是「這段字可不可疑」，而是「這段字有沒有開始接手 agent 的控制路由」。

而作者給出的答案也很資安：不要只盯著表面內容，要去看系統內部的權力轉移痕跡。

很多 skill 供應鏈真正缺的，不是再多一層關鍵字掃描，而是先看出 agent 的眼睛和腦袋是不是都已經被那份 skill 帶走。