論文 發布於 AIA: 2026年4月25日

惡意 LLM API 路由器：agent 工具呼叫被改寫的供應鏈風險

第三方 LLM API 路由器表面上只是幫 agent 轉接不同模型，但它其實站在 agent 和上游模型中間。提示詞、工具定義、API key 和工具呼叫的 JSON 內容，都會先經過這一層。

所以如果路由器本身是惡意的，或後來遭到入侵，攻擊者不一定要破解模型；他可以直接在中途改掉工具參數，讓 agent 執行不同指令，也可以偷走傳輸中的 secrets。因此，路由器選擇、路由政策、工具執行前檢查和請求記錄，都應該一起納入 agent 供應鏈治理。

Credential TheftTool Argument TamperingTool AuthorizationAgentic AIAPI Routers
8 項對應的 AIDEFEND 防禦手法
來源: Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain 
作者 Hanzhi Liu, Chaofan Shou, Hongbo Wen, Yanju Chen, Ryan Jingyang Fang, Yu Feng · 原文發布: 2026年4月9日

威脅分析

  • 路由器站在應用層中間。 用戶端會主動把模型 API 位址（base URL）指到路由器，所以 TLS 只能保護用戶端到路由器這一段，不能證明最後收到的工具呼叫，真的就是上游模型原本產生的內容。
  • 攻擊發生在模型回應送回 agent 的路上。 模型原本可能產生一個正常的 Bash 工具呼叫，但惡意路由器可以在中途把其中一個參數換掉，例如改成攻擊者控制的安裝程式或套件名稱。整個工具呼叫看起來仍然是合法 JSON，也符合原本的參數格式，所以 agent 可能照樣執行。
  • 路由器也可以只偷看，不一定要改內容。 agent 傳給模型的資料會先經過路由器，裡面可能包含 API key、雲端憑證、系統提示詞（system prompt）、工具定義、檔案內容和環境變數。這些資料在路由器那一層通常是明文，所以惡意路由器就算不改任何工具呼叫，也可能把這些敏感資訊偷偷記下來。
  • 這不是單純的理論風險。 作者在付費和免費路由器裡都觀察到惡意行為：包括 AWS canary 憑證被拿去嘗試使用、以太幣（ETH）被轉走、依條件挑選目標下手，以及弱路由器誘捕環境中 440 個可被命令注入的 Codex 工作階段。
  • 用戶端還是可以先做一些防護，但它沒辦法百分之百證明「這個工具呼叫真的是上游模型產生的」。 現在能做的是：在工具執行前加上政策關卡、偵測異常工具參數，並把請求和回應寫進只能新增、不能事後修改的記錄，方便事後追查。長期來看，模型供應商需要替回應加上簽章。這樣用戶端才能在 agent 執行工具前，驗證工具呼叫沒有被中間路由器改過。

適用的 8 項 AIDEFEND 防禦手法

AID-H-019.004
Intent-Based Dynamic Capability Scoping
極高
這篇論文最直接可落地的防禦作法，是對 Bash、run_command、套件安裝這類高風險工具做失敗即阻擋的政策關卡。每個工作階段都應該有自己的能力範圍，讓惡意路由器就算改寫工具呼叫，也碰不到任務範圍外的工具或套件路徑。
AID-H-019.005
Value-Level Capability Metadata & Data Flow Sink Enforcement
極高
這類外洩最麻煩的地方，是它不一定會造成明顯異常。secrets 和高機敏資料可能只是跟著一般請求欄位或工具輸出一起經過路由器，看起來像正常流量，但其實已經被路由器看見，甚至可能被記錄下來。所以防禦時不能只檢查工具呼叫格式，也要追蹤每個執行期值的來源與機敏程度。凡是 secrets 或高機敏資料要流向外部 HTTP、shell、套件安裝流程、log 或監控系統，都應該先被擋下或要求額外審查。
AID-H-034.004
Route Policy Bundle Versioning, Approval, Canary & Rollback
高
把 agent 改接第三方路由器，有時只是改一個 base URL 和 API key。這類路由政策不該隨手就改，而應該像重要安全設定一樣，先簽署、先審查、先小範圍上線，確認沒問題後再擴大，並且保留隨時切回原設定的能力，避免團隊在沒有明確察覺的情況下，悄悄改接到較弱的轉送鏈或不可信的相容端點。
AID-H-004.002
Service & API Authentication
高
論文的投毒實驗顯示，一旦上游金鑰外洩、轉送服務本身又缺乏足夠保護，原本看起來正常的路由器就可能變成洩漏明文資訊的點。替每個路由器使用獨立、短效、權限受限、可快速撤銷的服務憑證，可以縮小被偷或被重用金鑰能看到的流量範圍。
AID-H-026.003
Pre-Execution Static Scan
高
這條攻擊之所以危險，是因為一旦工具呼叫在中途被改寫，後面還是可能照常進到直譯器或 shell。只要在執行前先檢查危險命令樣式、安裝程式下載、typosquat 套件名稱和 shell 包裝路徑，就能在惡意內容真的跑起來前，替用戶端先擋下來。
AID-I-001.003
Ephemeral Single-Use Sandboxes for Tools
高
研究中有大量工作階段可以被命令注入，其中多數還跑在自動核准的 YOLO 模式。工具執行沙箱、管制對外連線和不放 secrets 的工作區，雖然不能證明工具呼叫是不是來自上游模型，但至少能在惡意路由器改掉執行內容時，把傷害明顯壓低。
AID-D-003.003
Agentic Tool Use & Action Policy Monitoring
中
論文的回應側異常篩檢就對應到這裡：在工具呼叫進入下游執行前，檢查 shell 風險樣式、異常參數、像 secrets 的字串、參數規格偏差，以及工作階段內工具名稱頻率是否突然改變。
AID-D-005.002
Security Monitoring & Alerting for AI
中
把請求和回應寫進只能新增、不能事後修改的記錄，再加上 SOC 警示，可以在出現可疑行為後回答：是哪個路由器、哪組帳號、哪個請求、哪次工具呼叫暴露了資料。這對這類被動外洩特別重要，因為流量當下可能看起來完全正常，直到 canary 或憑證之後真的被拿去使用，問題才會浮出來。

身為資安防禦者，我們應該這麼做

  • 先盤點所有把模型流量指向第三方 API 路由器、轉送服務、中繼閘道，或 OpenAI 相容模型 API 位址的 agent、IDE、CI 工作和內部平台。
  • 把路由器設定移進需要審查的路由政策設定檔。不要讓開發者臨時改模型 API 位址就直接上線；每個路由器都應該使用獨立憑證，而且憑證要限制可用範圍、縮短有效時間，並標明負責人中繼資料（metadata）。
  • 對來自路由工作階段的高風險工具呼叫採取失敗即阻擋：shell 執行、套件安裝、工作區外檔案寫入、雲端 CLI 動作和對外網路下載。
  • 在提示詞（prompt）、工具輸出和記錄穿過不可信路由器前，先移除 secrets。放入 canary 憑證，並在任何 canary 觸碰雲端、程式碼儲存庫、錢包或 SaaS API 時觸發警示。
  • 替路由工作階段保留本機可查的記錄：路由器 URL、TLS 中繼資料、請求與回應雜湊、已去識別化的內容類別、工具名稱和核准模式。記錄要保留足夠久，事件後才有辦法界定影響範圍。
  • 把路由 agent 工作階段放進 secrets 很少、對外連線也受限的沙箱，特別是啟用自動核准或 YOLO 模式時。

1 個額外的防禦考量

工具呼叫來源證明所需的供應商簽署回應封包

除了上面對應的防禦技術，使用 LLM 路由器的團隊還應該推動端到端回應完整性：由上游供應商簽署標準化封包，涵蓋模型身分、工具名稱、工具參數、結束原因、nonce 和有效時間窗。
建議做法: 在供應商支援之前，先把核准過的路由政策、失敗即阻擋的工具關卡、本機可查的請求記錄和沙箱執行一起用。等回應簽署可用後，再要求用戶端在執行任何工具呼叫前先驗證封包。

結論

這篇論文把一條容易被低估的信任邊界講得很清楚：LLM API 路由器一方面很方便，另一方面也可能是 agent 命令真正被執行前，最後一個碰到工具參數的元件。AIDEFEND  對應到的防線包括：限制 agent 可以使用哪些工具、控管 secrets 和高機敏資料能不能流到外部服務、治理路由政策、驗證服務身分、檢查執行前的工具呼叫，以及監測異常行為。生態系接下來要補強的，是讓用戶端能在 agent 動手前，確認工具呼叫真的來自上游模型，而且中途沒有被路由器改過。