ToolHijacker 論文閱讀分析：真正危險的，不是惡意工具做了什麼，而是它為什麼那麼容易先被 Agent 選上

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

論文基本資訊

• 論文標題：Prompt Injection Attack to Tool Selection in LLM Agents
• 作者：Jiawen Shi、Zenghui Yuan、Guiyao Tie、Pan Zhou、Neil Zhenqiang Gong、Lichao Sun
• 年份：2026
• 來源：NDSS 2026 / arXiv:2504.19793
• 論文連結：https://arxiv.org/abs/2504.19793
• DOI：10.48550/arXiv.2504.19793
• 主題：Agentic Security、Tool Selection、Prompt Injection、Tool Poisoning、MCP、Runtime Security

最近一整串 agent security 論文，很多都在談 tool poisoning、indirect prompt injection、approval fatigue，或 client 怎麼在執行邊界前補防線。但這篇 Prompt Injection Attack to Tool Selection in LLM Agents 切得更前面，也更致命：它不是等 agent 已經選到壞工具才談後果，而是直接問一個很多人其實還沒真的防住的問題：

如果攻擊者能把惡意工具放進工具庫，那他能不能連「被選上」這一步都一起劫持？

我會把這篇的核心濃縮成一句話：

真正危險的，不只是惡意工具執行了什麼，而是 agent 在做 tool discovery 與 tool selection 時，就已經被那份看起來像正常文件的 tool document 重新帶了方向。

這篇最值得記住的訊號有四個：

• 作者提出 ToolHijacker，專門攻擊 retrieval + selection 兩階段工具選擇流程，而不是只對最後 prompt 塞一句惡意指令。
• 它假設的是更接近現實的 no-box scenario：看不到目標 task 描述、看不到 target retriever、看不到 target LLM，甚至不知道 top-k 細節。
• 在這麼苛刻的條件下，作者仍做到很高的成功率；例如以 Llama-3.3-70B 當 shadow LLM、GPT-4o 當 target LLM 時，在 MetaTool 上仍可達到 96.7% attack success rate，retrieval hit rate 甚至到 100%。
• 作者測了 StruQ、SecAlign、known-answer detection、DataSentinel、PPL 與 PPL-W 等防線，結果都擋不太住，代表這不是那種加一層 wrapper 就結案的問題。

這篇論文到底在打哪個點？

很多人講 agent prompt injection，腦中第一個畫面還是：

• 惡意網頁
• 有毒文件
• tool output 被夾帶指令

但這篇提醒的是另一個更早、也更基礎的節點：tool selection。

現在很多 agent 選工具的流程，大致都長這樣：

1. 使用者給任務描述
2. retriever 從工具庫撈出 top-k 候選工具文件
3. LLM 再從這些候選裡挑一個最適合的工具
4. 系統直接執行

問題在於，這條鏈裡的 tool document 往往同時扮演兩個角色：

• 它是 retriever 用來算語意相似度的索引材料
• 它也是 LLM 在 selection 階段閱讀與判斷的依據

這代表只要攻擊者能精準操控 tool document，他就不是只在某個單點下毒，而是在同時操控：

• retrieval relevance
• selection preference

也就是說，攻擊真正瞄準的不是「工具執行時刻」，而是 agent 在決定相信哪個工具之前的整個判斷過程。

Threat model 為什麼值得注意？

這篇很強的一點，是它沒有偷吃步。作者假設的不是白箱，也不是能不斷 query 目標系統的灰箱，而是更硬的 no-box 條件：

• 不知道真正的 target task descriptions
• 不知道 target retriever 與 target LLM 參數
• 拿不到工具庫內容
• 不知道 top-k retrieval 設定
• 不能直接查 target retriever / LLM 的反應

攻擊者真正擁有的，只是很現實也很常見的能力：

• 知道自己想劫持哪一類任務
• 可以自己建一個惡意工具
• 可以把工具丟到開放平台或工具中心裡
• 可以在本地做 shadow simulation 來最佳化工具文件

這個 threat model 很關鍵，因為它直接對應到今天 MCP server、tool hub、第三方 skill / plugin 生態最常見的供應鏈風險：攻擊者未必要進你的主機，他只要能進你的工具市場就夠了。

ToolHijacker 怎麼做？

作者把整件事 formalize 成一個 optimization problem：目標是在未知目標系統內部細節的前提下，生成一份惡意 tool document，讓它能穩定通過 retrieval，並在 selection 階段被選為最終工具。

難點在於，這件事同時牽涉兩套不同機制：

• retriever 的 embedding / similarity 空間
• LLM 的語言理解與決策偏好

所以作者沒有用單一 payload 一把打穿，而是把惡意 tool description 拆成兩段：

• R：負責最大化 retrieval relevance
• S：負責操控 selection outcome

最後再把兩段拼成完整的 tool description：R ⊕ S。

這個拆法很重要，因為它點出一件很多防禦論文容易模糊帶過的事：

tool selection 不是單一步驟，而是至少由「先被看見」與「再被選上」兩個不同 decision surfaces 組成。

如果只防其中一段，另一段還是可能把整條鏈拖走。

作者怎麼在看不到目標系統的情況下最佳化攻擊？

作者的做法是建立一個 shadow tool-selection pipeline。裡面包含：

• shadow task descriptions
• shadow tool library
• shadow retriever
• shadow LLM

然後在 shadow 環境中優化惡意 tool description，期待它能 transfer 到真正的 target system。

這種設計背後的假設也很現實：不同 retriever 與 LLM 雖然不完全相同，但在「哪些語意模式看起來像同一類任務」「哪些描述更像值得選的工具」這件事上，通常仍存在相當程度的共享結構。所以只要能在 shadow pipeline 中找到有效模式，就可能在 target system 上轉移成功。

Retrieval phase：怎麼讓惡意工具先擠進 top-k？

針對 retrieval objective，作者的想法很直接：讓惡意工具文件看起來盡可能語意上貼近目標任務。為了做到這件事，他們用了兩種方法：

• gradient-free：用 LLM 從 shadow task descriptions 中濃縮出高度對齊的功能描述
• gradient-based：利用 shadow retriever 的梯度資訊，進一步把描述推向更高相似度

這一步的本質不是「寫一句很像攻擊的話」，而是把惡意工具包裝成一個在語意空間裡非常像正解的候選。

這也是我覺得這篇很值得看的地方：它把 prompt injection 從「instruction override」往前推成「relevance hijacking」。

Selection phase：就算進了候選集，怎麼保證最後被選上？

只進 top-k 還不夠，因為真正危險的是要讓 LLM 在幾個候選工具之中穩定偏向惡意工具。這就是 S 段處理的事。

作者一樣提出兩條路：

• gradient-free：透過迭代生成、評估、剪枝，逐步演化出更能誘導選擇的描述
• gradient-based：直接在 shadow LLM 上做最佳化，推進 selection objective

如果前面的 R 比較像讓惡意工具「被看到」，那 S 就是在讓它「看起來像唯一合理答案」。

這裡最麻煩的地方在於，這類操控往往不需要赤裸裸寫出 ignore previous instructions 這種太明顯的字樣。攻擊者真正要做的，是把惡意工具描述寫得既像功能說明，又足以 subtly 影響模型偏好。這也正是為什麼很多規則式偵測會失效。

實驗結果：不是能不能打中，而是打得有多誇張

作者在兩個 benchmark dataset、8 個 LLM、4 個 retriever 上測試 ToolHijacker。幾個數字特別值得記：

• 在不少設定下，retrieval hit rate 可以到 100%，代表惡意工具幾乎穩定能進入候選集。
• 在 Llama-3.3-70B → GPT-4o 的 transfer 設定裡，gradient-free 方法在 MetaTool 上仍達到 96.7% ASR。
• 作者明確指出，ToolHijacker 顯著優於既有 manual-based 與 automated prompt injection baseline。

這裡最關鍵的不是某一個極端數字，而是它證明了：

就算攻擊者拿不到真實系統細節，仍然可以透過 shadow optimization，把工具選擇流程做成高度可轉移的操控面。

換句話說，工具市場愈開放、工具文件愈自由、retrieval 與 selection 愈依賴自然語言，這種風險就愈不是理論問題。

防禦表現為什麼讓人不太放心？

作者測了兩類防禦：

• prevention-based：StruQ、SecAlign
• detection-based：known-answer detection、DataSentinel、PPL、PPL-W

結果相當不樂觀。

例如在 StruQ 下，gradient-free ToolHijacker 仍能達到 99.6% success rate。而 detection 類方法也只抓到一部分；像 PPL 在維持低誤報時，仍會漏掉大多數惡意工具文件。

這代表兩件事：

• 第一，很多現有 prompt-injection defense 其實更像是在防 generation stage，而不是 tool-selection stage。
• 第二，一旦攻擊 payload 被包成高語意相似、像正常功能描述的文件，單純靠 perplexity 或已知 pattern 偵測，往往很難穩定抓出來。

這也是這篇最大的警訊：你不能因為有 wrapper、有 guard prompt、有 anomaly detector，就假設工具發現與選擇這一層已經安全。

我怎麼看這篇：它把風險從工具執行，往工具治理前移了一整段

這篇論文真正有價值的，不只是它做出一個新 attack，而是它把整個 agentic security 討論重新往前推：

• 不是「壞工具執行後怎麼收拾」
• 而是「為什麼它能在那之前就被看見、被相信、被選上」

如果你把它放回最近 MCP / tool poisoning / client security 這條主線，它其實剛好補了一個很重要的空白：

• Tool poisoning 講的是工具描述本身可以帶毒
• MCP threat modeling 講的是 client 把 metadata 當半可信控制面有多危險
• ToolHijacker 則把這件事進一步操作化：不只 metadata 能帶毒，它還能精準劫持 selection policy

也就是說，真正該治理的不是單一 prompt，而是從：

• tool publication
• tool registry ingestion
• retrieval ranking
• selection prompting
• execution approval

這整條鏈上的 trust boundary。

對實務團隊的真正提醒

如果今天你在做 MCP client、agent runtime、tool hub 或 enterprise agent platform，這篇 paper 其實是在提醒三件很具體的事：

1. 不要把 tool document 當純文件：它同時是 ranking signal，也是 decision input，本質上屬於控制面資料。
2. 不要只掃 execution output：真正的污染可能在 tool 還沒被執行前就完成了。
3. 不要假設 open marketplace 可以只靠上架審核：因為這類攻擊可被系統化最佳化，而且能跨模型、跨 retriever 轉移。

比較合理的防禦方向，恐怕得走向：

• tool metadata provenance
• registry-level trust scoring
• retrieval-time anomaly / policy filtering
• selection-stage isolation 或 structured constraints
• 高風險工具的 post-selection approval 與 secondary verification

也就是說，防線不能只設在執行點，而要回推到 discovery 與 selection pipeline 本身。

總結

Prompt Injection Attack to Tool Selection in LLM Agents 值得看的原因，不只是它又證明一次 prompt injection 很危險，而是它把很多團隊原本默認安全的那一層直接拆開來看：

• 惡意工具不一定要先執行，光是被檢索、被閱讀、被比較，就已經能開始影響 agent。
• tool selection 不是單一判斷，而是 retrieval + selection 的組合攻擊面。
• shadow optimization 代表這種攻擊不需要白箱，也不需要持續互動式 probing。
• 現有 wrapper 與檢測器，對這種高度語意化的工具文件操控，仍遠遠不夠。

如果只留一句 takeaway，我會寫成這樣：

Agent 真正開始失守的時間點，往往不是它按下 tool call 的那一刻，而是它在工具庫裡第一次把攻擊者的文件看成「這個選項很合理」的那一刻。

免責聲明

本文由 AI 產生、整理與撰寫，內容主要依據公開論文、技術文件與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。