您的代理有個您從未審查過的中間人

研究人員從淘寶、閒魚以及託管於 Shopify 的商店購買了 28 個付費 LLM API 路由器，並從公開社群中收集了另外 400 個。他們在請求中植入了憑證作為探測工具，並對每個路由器進行探測，觀察它們對流量的處理方式。¹

其中 17 個路由器觸碰了請求中植入的 AWS 金絲雀憑證。有一個從被當作誘餌的私鑰中抽走了 ETH。團隊設置為蜜罐的一把外洩 OpenAI 金鑰，在他們撤下之前產生了 1 億個 GPT-5.4 tokens，並根據摘要所述「超過七個 Codex 工作階段」。¹ 另外一些弱設定的誘餌則產生了 20 億個計費 tokens、橫跨 440 個 Codex 工作階段的 99 組憑證，以及 401 個已在自主 YOLO 模式下運行的工作階段。¹

LLM API 路由器就是新的攻擊面。沒有人在稽核它。

TL;DR

第三方 LLM API 路由器是應用層代理，能夠以純文字完整存取您的代理與上游模型之間每一個傳輸中的 JSON 負載。沒有任何供應商在客戶端與上游之間強制執行加密完整性。Liu、Shou、Wen、Chen 與 Fang 在一篇新的 arxiv 論文中首次系統化研究了這個攻擊面，其現場資料令人難堪：28 個付費路由器中有 1 個、400 個免費路由器中有 8 個正主動將惡意程式碼注入回應中，2 個部署了適應性規避觸發器，17 個觸碰了植入的 AWS 金絲雀憑證，還有 1 個從植入的私鑰中抽走了 ETH。¹ 作者形式化了兩大核心攻擊類別加上兩種適應性規避變體，接著建立了一個名為 Mine 的研究用代理，對四個公開代理框架實作「所有四種攻擊類別」（作者用語），並評估了三種可部署的客戶端防禦機制。¹ 如果您的代理使用的是您並非親自建構的路由器，那麼您就擁有一條從未稽核過的信任邊界。

重點摘要

• 代理操作者：您的客戶端與上游模型之間的每一個 LLM API 路由器都是應用層代理，能以純文字存取每個請求與回應。沒有強制執行任何加密完整性。如果您使用的是從市集購買或從公開社群清單取得的路由器，請在證明其可信之前，將其視為敵意中介。
• Harness 建構者：您的 PreToolUse hooks 會在工具執行前運行，但惡意路由器是在產生之後、抵達您的 hook 之前修改模型回應。請在您的 hook 堆疊中加入回應端驗證，並考慮對異常回應形狀套用「預設拒絕」的政策閘門。
• 任何在跑 YOLO 模式的人：研究人員的蜜罐中有 401 個工作階段已在自主 YOLO 模式下運行。¹ 在自主工作階段中修改工具呼叫的路由器，其影響範圍遠大於修改您即將閱讀之回應的路由器。切勿透過您無法掌控的路由器運行 YOLO 模式。

路由器到底是什麼？

在這篇論文的語境下，LLM API 路由器是一種第三方服務，位於您的客戶端與一個或多個上游模型供應商之間。您使用與 OpenAI 相容的 API 將請求發送至路由器。路由器會將這些請求分派給它所選擇的任何上游——GPT-5、Claude、Gemini、開放權重模型，或是全部的混合池——並以相同的形式將回應回傳給您。¹

路由器存在的原因是 LLM 生態系混亂不堪。人們想要一把 API 金鑰就能對所有模型運作。人們想要價格套利——批量購買 tokens 再以更便宜的價格轉售。人們想要在直接存取供應商受限的地區取得地理上的替代方案。人們想要用一個客戶端測試多個模型。這些都是合理的理由，健康的路由器市場也服務於這些需求。

問題在於，路由器是一個應用層代理。它不只是轉發位元組。它讀取請求 JSON、挑選上游、選擇性地重寫請求、轉發出去、讀取回應、選擇性地重寫回應，然後回傳。這整個管線的每一步都在路由器的基礎架構上以明文進行。¹

這裡沒有 TLS 等效的保護機制。TLS 保護的是從您的客戶端到路由器、以及從路由器到上游模型之間的位元組。它無法保護負載免受路由器本身的影響。沒有任何供應商在原始客戶端與最終模型之間強制執行加密完整性——沒有任何簽章聲明能證明模型收到的請求與客戶端送出的請求相同，也沒有任何簽章聲明能證明客戶端收到的回應與模型產生的回應相同。¹

這個缺口就是攻擊面。

現場資料

研究人員從三個市集（淘寶、閒魚、託管於 Shopify 的商店）購買了 28 個付費路由器，並從公開社群收集了 400 個免費路由器。他們透過一系列探測請求對每個路由器進行測試，這些請求中包含植入的憑證、已知的負載以及標記字串。¹

以下是他們的發現：

適應性規避這項發現才是真正應該讓您夜不成眠的。適應性規避觸發器代表路由器大多數時候行為正常，只有在特定條件下才會切換成攻擊模式——特定的請求形狀、特定的客戶端指紋、特定的頻率節奏。您無法透過隨機抽樣請求來捕捉它，因為路由器知道自己何時正在被抽樣檢測，並會表現得若無其事。

金絲雀憑證是絆線：當有人嘗試使用它們時就會觸發警報。17 個路由器「觸碰」它們意味著至少有 17 個路由器從傳輸中的負載中抽取了這些憑證，並嘗試將其用於存取 AWS。¹ 摘要並未詳述每個路由器的確切機制，但絆線的設計原理意味著觸碰即等於使用。

那個從研究人員擁有的私鑰中抽走 ETH 的路由器是一項更強而有力的發現。放在提示中的私鑰並不是憑證絆線——它是誘餌，只有當路由器真的把錢包掏空時，才會產生遭受攻擊的證據。確實有一個路由器這麼做了。¹

兩項投毒研究

研究人員進行了另外兩項研究，以證明表面上無害的路由器也可能透過第三方暴露被拉進同一個攻擊面。

研究一：外洩的 OpenAI 金鑰。研究人員外洩了一把可用的 OpenAI API 金鑰，彷彿它是因開發者失誤而外洩的。根據摘要，在觀察期間，那把單一的外洩金鑰透過撿到它的路由器產生了 1 億個 GPT-5.4 tokens，以及「超過七個 Codex 工作階段」。¹ 有人——或者是很多人——找到了那把金鑰，使用它透過社群路由器路由請求，燒掉了 1 億個 tokens 的算力。路由器成了被盜金鑰的洗錢層。

研究二：弱設定誘餌。研究人員架設了弱設定的誘餌端點。這些誘餌產生了 20 億個計費 tokens、橫跨 440 個 Codex 工作階段的 99 組憑證，以及——這是關鍵的一點——401 個已在自主 YOLO 模式下運行的工作階段。¹

401 個自主工作階段已經在透過單一組誘餌路由。這些工作階段每一個都是活生生的攻擊面，惡意中介可以注入工具呼叫、竊取機密，或修改模型的輸出，而代理會在無人監督下執行所接收到的任何內容。401 這個數字只是一組研究誘餌所捕獲的數量——透過無法控管之中介進行路由的實際營運人口必然更龐大。

兩大核心攻擊類別與兩種適應性變體

這篇論文形式化了兩大核心攻擊類別與兩種適應性規避變體。摘要對分類法有明確說明：AC-1 與 AC-2 是核心類別；AC-1.a 與 AC-1.b 是 AC-1 的變體。研究用代理 Mine 對四個公開代理框架實作了「所有四種攻擊類別」（摘要的用語）。¹

AC-1：負載注入（核心類別）。路由器修改回應，注入客戶端代理會據以執行的額外指令、工具呼叫或內容。代理以為自己讀取的是來自模型的輸出；實際上讀取的是來自擁有該路由器之人的輸出。

AC-2：機密外洩（核心類別）。路由器從傳輸中的請求與回應中讀取機密——API 金鑰、權杖、私鑰、任何看起來像憑證的東西——並將其運送到攻擊者的基礎架構。

AC-1.a：針對依賴項的注入（AC-1 的適應性變體）。注入僅在請求符合特定依賴項或情境時才會觸發——例如，只有當請求是關於特定函式庫、只有當特定函式被引用、只有當某些檔案路徑出現在提示中時。這使得攻擊在隨機測試中無法被察覺。

AC-1.b：條件式遞送（AC-1 的適應性變體）。惡意負載在特定條件下才會遞送（一天中的時間、請求節奏、客戶端指紋）。採用相同的躲避偵測邏輯。

這些攻擊類別中的每一個對客戶端與上游模型而言都是隱形的，因為兩端都信任路由器。客戶端看到的是正常的回應形狀。模型看到的是正常的請求形狀。路由器可以在中間為所欲為，而雙方都沒有任何加密方法能偵測到竄改。¹

組合模式，下降一層

我不斷在寫同一種結構性錯誤：個別已獲授權的元件組合起來卻產生未經授權的行為。Trivy-to-LiteLLM 是套件層的組合。沉默出口 是工具描述層的組合。MCP 工具投毒 是協定層的組合。axios 維護者遭入侵事件 是人類維護者層的組合。

路由器攻擊是網路層的組合。您的客戶端被授權呼叫路由器。路由器被授權呼叫上游模型。上游模型被授權回應。每一個單獨的跳點都是被授權的。這些已獲授權的跳點組合起來，就產生了大規模的負載注入與機密外洩，因為這個組合跨越了一條沒有人費心以加密方式封緘的信任邊界。¹

您無法在任何單一層解決這個問題。您必須在組合層解決它，這意味著客戶端必須將路由器視為敵意，直到它能獨立驗證回應形狀、工具呼叫與內容都與上游模型可能合理產生的輸出一致為止。

論文評估的三種防禦

論文評估了三種針對這些攻擊類別的客戶端防禦。¹

1. 預設拒絕的政策閘門。客戶端對回應形狀、允許的工具呼叫、允許的 URL、允許的指令強制執行一套政策。超出政策範圍的任何東西都會預設拒絕——請求會被駁回而非允許。

2. 回應端異常篩檢。客戶端監控回應形狀異常、不尋常的 token 模式，或包含已知攻擊標記的輸出（通往未知主機的 URL、可疑的憑證模式、不尋常的工具呼叫結構）。

3. 僅限附加的透明度日誌。客戶端將每一個請求與回應寫入一份無法事後修改的僅限附加日誌中。這並不能防止攻擊，但能讓攻擊在鑑識上可追溯。

這些都不是萬靈丹。我的解讀是：預設拒絕的政策閘門是三者中最強的，因為它不依賴於偵測攻擊——它會拒絕任何不在明確允許清單內的東西——但摘要並未對這些防禦進行排名，因此請將這視為我的意見，而非論文的結論。異常篩檢會漏掉看起來正常的攻擊，而適應性規避變體（AC-1.a 與 AC-1.b）正是專門被設計成在測試條件下看起來正常。政策閘門的好壞取決於政策本身，而為「模型回應應該長什麼樣子」撰寫一套完整的政策是很困難的。

您實際上應該做什麼

如果您正在運行的代理會透過一個並非您親自建構的路由器呼叫 LLM API：

1. 停止使用您從市集購買或從公開社群取得的路由器，除非您信任該營運者。這裡的「信任」是指您擁有某種外部基礎——已知的團隊、已簽訂的合約、您可以訴諸的法律管轄權——而不是「它在市集上評價很好」。

2. 在您的 harness 中加入預設拒絕的政策閘門。在 Claude Code 中，這代表使用 PreToolUse hooks 來拒絕明確允許清單以外的工具呼叫，以及使用 PostToolUse hooks 在回應形狀進入下一個模型回合之前加以驗證。您的 hook 堆疊就是您的預設拒絕政策層。

3. 切勿透過您無法掌控的路由器運行 YOLO 模式。蜜罐中的 401 個自主工作階段就是前車之鑑。如果路由器是敵意的而您的工作階段是自主的，那麼等於是路由器在操控您的機器。

4. 記錄所有一切。僅限附加的透明度日誌是您重建事件的依據。每一個請求。每一個回應。每一次工具呼叫。將它們儲存在路由器碰不到的地方。

5. 如果您運行的是代理基礎架構，請強制執行加密完整性。如果您同時負責客戶端與上游，請在客戶端上簽署請求，並在上游驗證簽章。這才是唯一真正的修復方式。路由器仍然可以看到明文，但它無法在不讓簽章失效的情況下修改任何東西。

令人不安的含意

路由器攻擊面是一個乾淨俐落的例子，展現了代理生態系出貨基礎架構的速度快於其確保安全的速度。人們想要一把 API 金鑰能對應每個模型。人們想要價格套利。人們想要區域存取。路由器滿足了所有這些需求。市場獎勵它們。但安全稽核從未發生。

MCP 攻擊面 有 50 個已記錄的漏洞。供應鏈攻擊面 有一場 TeamPCP 攻擊活動在一週內跨越了五個生態系。沉默出口攻擊面 有 Clinejection 以及 MCPTox 基準測試。現在再加上路由器攻擊面：研究了 428 個路由器，其中 9 個正主動注入惡意程式碼，17 個觸碰了植入的憑證，1 個抽走了 ETH，401 個自主工作階段已經活躍地運行在敵意基礎架構上。¹

模式每次都相同。我們建構了代理堆疊的新一層。新的一層在被稽核之前就被採用。攻擊者出現了。研究人員出現了。社群寫下發現報告。有在關注的營運者修補了他們的部署。沒在關注的營運者則以慘痛的方式學到教訓。

路由器攻擊面目前正處於「研究人員剛寫完報告」的階段。您還有時間修補您的部署。請善加利用。

常見問題

在這個語境下，LLM API 路由器是什麼？

一種第三方服務，位於您的客戶端與上游模型供應商之間，提供與 OpenAI 相容的 API，並將您的請求分派給一個或多個上游模型。它是一個應用層代理，能以純文字存取每個請求與回應。¹

這與 CDN 或一般的 HTTP 代理有什麼不同？

CDN 轉發位元組，並不讀取應用程式負載。LLM API 路由器則會讀取 JSON、挑選上游、選擇性地重寫請求、轉發、讀取回應，並選擇性地重寫回應。它對您的資料進行的是應用層級的處理，而不僅僅是傳輸。¹

TLS 能保護我免受惡意路由器的侵害嗎？

不能。TLS 保護的是從您的客戶端到路由器、以及從路由器到上游模型之間的位元組。路由器會終止 TLS、讀取明文，並在另一端重新加密。TLS 無法保護您的負載免受路由器本身的影響。¹

我該如何偵測正在主動注入回應的路由器？

如果路由器使用的是適應性規避，那麼您無法可靠地偵測到。論文中的 AC-1.a 與 AC-1.b 攻擊類別專門針對偵測規避而設計，只會在實際營運條件下才觸發。¹ 您最好的做法是建立預設拒絕的政策閘門——拒絕明確允許清單之外的任何東西——而不是試圖在事後偵測攻擊。

我是直接針對 api.anthropic.com 運行 Claude Code。我會受到影響嗎？

不會受到本論文所描述的路由器攻擊類別影響，因為您是直接呼叫 Anthropic，中間沒有任何中介。這個攻擊面專門針對第三方路由器。如果您基於任何原因（企業閘道、繞過速率限制、模型聚合器）透過代理路由 Claude Code，您就應該稽核該代理。

那 OpenRouter、LiteLLM 或其他知名的聚合器呢？

論文研究的是從特定市集（淘寶、閒魚、託管於 Shopify 的商店）購買的 28 個付費路由器，以及從公開社群清單取得的 400 個免費路由器。¹ 它並未公布具體的指名產品清單。這篇論文的重點是結構性的：任何路由器都是不受信任的中介，除非您有獨立的信任基礎。知名的聚合器並不會自動變得更安全——它們只是更顯眼而已，這是完全不同的屬性。

對於研究人員發現的那 401 個自主工作階段，我該怎麼做？

那些工作階段屬於其他將流量路由透過研究人員誘餌的營運者。如果您正在透過任何並非您親自建構的路由器運行自主代理工作階段，第一步就是停止。第二步是輪替所有曾經通過該路由器的憑證。第三步是稽核您的工作階段日誌，檢查是否有異常的工具呼叫或輸出。

參考文獻