核心概念

LLM API Router 是應用層代理，將客戶端請求轉發至多個上游 AI 供應商（OpenAI、Anthropic、Google 等），提供統一介面、負載均衡與成本優化。LiteLLM（GitHub 4 萬星、Docker 拉取超 2.4 億次）和 OpenRouter 等服務已成為 AI Agent 生態的關鍵基礎設施。

問題在於：Router 不是意外的中間人，而是被刻意配置的應用層權威。客戶端主動將流量導向 Router，Router 終止客戶端 TLS 連線並另起上游連線，對所有經過的 JSON payload 擁有完整明文存取權——包括 system prompt、tool 定義、API key、以及模型回傳的 tool call 參數。

2026 年 3 月的 LiteLLM 事件驗證了這個威脅：攻擊者透過 dependency confusion 在請求處理管線注入惡意程式碼，證明 Router 一旦被攻破，等同掌控所有流經的 API 請求與回應。

UCSB 與 UCSD 研究團隊（Liu et al., CCS 2026）首次系統性量測此供應鏈威脅，對 428 個商品級 Router 進行實證分析，並提出形式化攻擊分類與可部署防禦。

多跳鏈的最弱環節特性：實務中請求路徑常經過多層 Router。例如淘寶轉售商 → 二級聚合商 → OpenRouter → 上游供應商，每一跳都終止再建立 TLS，每一跳都能讀寫明文。任何一個惡意節點即可發動攻擊，下游誠實 Router 無法偵測修改，因為缺乏上游原始回應的參照。

關鍵要點

四類攻擊分類

  • AC-1 回應側 Payload 注入：Router 改寫模型產生的 tool call 參數（例如將安裝指令的 URL 換成攻擊者控制的端點），修改後的 JSON 仍符合 schema，不觸發格式驗證錯誤
  • AC-2 被動密鑰竊取：Router 掃描請求/回應中的 credential 模式（OpenAI key sk-*、AWS AKIA*、GitHub PAT ghp_*、以太坊私鑰等），非同步外傳，完全不修改回應，客戶端無法察覺
  • AC-1.a 依賴目標注入：不改 URL 而改套件名稱（typosquatting，例如 requests → reqeusts），繞過網域白名單，且被汙染的依賴會被本地快取，形成持久供應鏈立足點
  • AC-1.b 條件式觸發：Router 在特定條件才啟動注入——例如累積 50 次正常請求後、僅對 YOLO mode session、僅在非上班時段。有限的黑箱審計根本無法覆蓋觸發空間

實證量測結果（428 個 Router）

發現 數量
主動注入惡意程式碼 9 個（1 付費 + 8 免費）
濫用研究者 AWS 憑證 17 個
部署自適應逃逸 2 個
洩漏金鑰暴露 token 量 21 億 token
被竊取的獨立憑證 99 組（跨 440 個 Codex session）
已處於 YOLO mode 的 session 401/440（91%）

付費不等於安全——付費 Router 中也發現主動注入行為。

投毒研究

研究者故意洩漏一把 OpenAI key 並部署 20 個弱 Router 實例：

  • 40,000+ 未授權存取嘗試來自 147 個 IP
  • 單一洩漏 key 被計費 1 億 GPT-5.4 token
  • 良性 Router 重用洩漏的上游 key 後，也變成暴露明文流量的管道

跨框架相容性

研究者實作 Mine 代理測試 OpenClaw、OpenCode、Codex、Claude Code 四個框架：0/4 實作回應完整性驗證。AC-1 改寫相容率 100%，代理延遲中位數僅 0.013 ms，遠低於上游 820 ms 延遲，人類無法察覺。

實務應用

三層可部署防禦

  1. 高風險工具策略閘門：攔截 Bash/run_command 等工具，阻擋非白名單網域或套件。可擋下所有 AC-1/AC-1.a 樣本，但攻擊者使用白名單網域即可繞過（100% bypass rate）
  2. 回應側異常偵測：IsolationForest 分類器，在 6.7% 誤報率下偵測 89% AC-1 攻擊，但對 AC-1.a/1.b 僅 50%
  3. 唯附加透明日誌：記錄請求/回應/TLS 元資料，每 1,000 session 僅 12 MB，事後鑑識價值高但無法即時阻擋

長期解法：供應商簽章回應信封

目前 OpenAI、Anthropic、Google 及 MCP 規格 均無部署 tool call 回應簽章機制。論文建議仿照 DKIM 設計涵蓋供應商身份、模型 ID、tool call 參數、客戶端 nonce 的簽章信封——這需要供應商配合，但能從根本解決 Router 竄改問題。

對 Agent 生產環境 的啟示：即使 Agent 本身遵守最小權限原則，若 Router 層被攻破，所有 tool call 都可能被竄改。供應鏈安全需從 Agent 端延伸到傳輸層。

延伸觀點

Tool Call 預執行防火牆已有可行方案：AEGIS 框架（2026）提出在 tool 執行路徑上攔截的三階段閘門——深層字串提取（遞迴解析至深度 32 防止結構隱藏）、內容風險掃描（22 種偵測模式覆蓋 SQL 注入、路徑穿越、shell 注入等）、以及策略驗證。在 500 次正常 tool call 測試中僅 1.2% 誤報率、中位延遲 8.3 ms，與本文的策略閘門防禦互補但更系統化。高風險呼叫觸發人工審核暫停機制，而非直接放行或阻擋。

MCP 協議的安全缺口比 Router 層更廣：MCPShield 研究（2026）對 MCP 生態進行形式化分析，識別出 7 大威脅類別、23 種攻擊向量——包括工具投毒（在工具描述中嵌入惡意指令）、Rug Pull（審核通過後修改工具行為）、跨伺服器資料洩漏、權限升級等。關鍵發現：沒有任何單一防禦方案能覆蓋超過 34% 的威脅面。其提出的四層防禦（能力存取控制 + 密碼學工具驗簽 + 資訊流追蹤 + 執行期策略引擎）理論覆蓋率達 91%，但需要整個生態配合。

供應鏈攻擊已延伸至 Skill 文件層：另一項研究揭示 DDIPE（文件驅動隱式載荷執行）攻擊——在 coding agent 的 skill 文件中嵌入偽裝成「官方範例」的惡意程式碼區塊。81 個手動攻擊種子可擴展為 1,070 個對抗性 skill，跨 15 個 MITRE ATT&CK 類別。即使強對齊模型（Claude Sonnet）也有 13.5% 的繞過率，而傳統的明確指令注入繞過率為 0%——這說明攻擊者正轉向更隱蔽的文件層攻擊面。

反向連結

以下頁面引用了本頁：