你的代理有個你沒審查過的中間人

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

這些路由器中有 17 個接觸了請求中植入的 AWS 誘餌憑證。有一個從作為誘餌的私鑰中抽走了 ETH。研究團隊設置為蜜罐的一把洩露的 OpenAI 金鑰，在被收回前產生了 1 億個 GPT-5.4 token，根據摘要所述還「產生了七次以上的 Codex 工作階段」。¹另外，配置較弱的誘餌分別產出了 20 億個計費 token、橫跨 440 次 Codex 工作階段的 99 組憑證，以及已在自主 YOLO 模式下運行的 401 次工作階段。¹

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

MCP信任鏈是由一連串中介（API路由器、代理、工具伺服器）組成，它們介於您的 AI 代理與上游模型之間，每一環都能以純文字完整存取所有的請求與回應。沒有任何供應商在端到端的連線上強制執行密碼學完整性，這意味著任何中介都能在傳輸途中讀取、修改或竊取資料。田野研究發現，28 個付費路由器中有 17 個接觸了植入的 AWS 憑證，1 個從私鑰中抽走 ETH，證明未經審查的信任鏈環節就是活躍的攻擊面。

TL;DR

第三方LLM API路由器是應用層代理，可以純文字完整存取您的代理與上游模型之間所有傳輸中的JSON酬載。沒有任何供應商會在客戶端與上游之間強制執行密碼學完整性。Liu、Shou、Wen、Chen 與 Fang 所發表的一篇 arxiv 新論文，首次對此攻擊面進行系統性研究，而田野資料不堪入目：28 個付費路由器中有 1 個、400 個免費路由器中有 8 個正積極地在回應中注入惡意程式碼，2 個部署了自適應規避觸發器，17 個接觸了植入的 AWS 誘餌憑證，1 個從植入的私鑰中抽走了 ETH。¹作者們將兩種核心攻擊類別加上兩種自適應規避變體加以形式化，接著打造一個名為 Mine 的研究代理，實作「所有四種攻擊類別」（作者原話），對四個公開的代理框架進行攻擊，並評估了三種可部署的客戶端防禦方案。¹如果您的代理正在使用一個不是您自建的路由器，您就擁有一條從未審查過的信任邊界。

重點摘要

• 代理操作者：您的客戶端與上游模型之間的每一個LLM API路由器，都是一個能以純文字存取所有請求與回應的應用層代理。沒有供應商強制執行密碼學完整性。如果您的路由器是從商店購買或從公開社群名單中取得的，在您獨立驗證之前，請把它當作敵對的中介看待。
• 框架打造者：您的 PreToolUse 掛鉤會在工具執行前運行，但惡意路由器會在模型生成之後、抵達您的掛鉤之前修改回應。請在掛鉤堆疊中加入回應端的驗證，並對異常的回應結構考慮採用故障關閉（fail-closed）的政策閘門。
• 任何執行 YOLO 模式的人：研究人員的蜜罐中已有 401 次工作階段在自主 YOLO 模式下運行。¹在自主工作階段中修改工具呼叫的路由器，其爆炸半徑遠大於僅修改您會閱讀回應的路由器。絕對不要透過您無法控制的路由器執行 YOLO 模式。

路由器究竟是什麼？

在本論文的脈絡中，LLM API路由器是介於您的客戶端與一個或多個上游模型供應商之間的第三方服務。您使用與 OpenAI 相容的API向路由器發送請求。路由器會將這些請求派發給它選擇的任何上游（GPT-5、Claude、Gemini、開放權重模型，或上述所有模型的池），並以相同的結構把回應回傳給您。¹

路由器之所以存在，是因為LLM生態系一片混亂。人們想要一把API金鑰就能對所有模型使用。人們想要價格套利：大量購買 token，再便宜轉售。人們想要在直連供應商受限的地區進行地理繞道。人們想要以單一客戶端測試多種模型。上述這些全都是正當需求，健全的路由器市場本應服務於這些需求。

問題在於，路由器是一種應用層代理。它不只是轉發位元組。它會讀取請求的JSON、挑選上游、可能重寫請求、再轉發、讀取回應、可能重寫回應，最後回傳給您。整條管線的每一步，都是以明文的形式在路由器的基礎設施上發生。¹

這裡沒有 TLS 等效的保護。TLS 只保護從客戶端到路由器、以及從路由器到上游模型之間的位元組。它無法保護酬載不受路由器本身的侵害。沒有任何供應商在原始客戶端與最終模型之間強制執行密碼學完整性。沒有任何帶簽章的斷言能證明模型收到的請求與客戶端發出的請求相同，也沒有任何帶簽章的斷言能證明客戶端收到的回應與模型生成的回應相同。¹

這個缺口就是攻擊面。

田野資料

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

以下是他們的發現：

自適應規避的發現是最令人徹夜難眠的。自適應規避觸發器意味著路由器多數時間的行為正常，只在特定條件下才切換至攻擊行為：特定的請求結構、特定的客戶端指紋、特定的節奏。您無法透過隨機取樣來抓到它，因為路由器知道自己何時被取樣，並會乖乖表現。

誘餌憑證是絆網：有人嘗試使用時就會觸發。17 個路由器「接觸」它們，代表至少有 17 個路由器從傳輸中的酬載提取了憑證，並試圖對 AWS 使用它們。¹摘要並未詳述每個路由器的確切機制，但絆網的設計意味著：接觸即使用。

那個從研究人員所有之私鑰抽走 ETH 的路由器，是更為有力的發現。提示中的私鑰並非憑證絆網，而是只有在路由器真正抽走錢包時才會留下入侵證據的誘餌。而有一個路由器確實做了。¹

兩項投毒研究

研究人員進行了兩項額外研究，以證明表面上良性的路由器也可能透過第三方曝露而被捲入同一個攻擊面。

研究一：洩露的 OpenAI 金鑰。研究人員洩露了一把可用的 OpenAI API金鑰，彷彿是開發者的疏失所致。在觀察期間，根據摘要，該把洩露的金鑰透過撿到它的路由器，產生了 1 億個 GPT-5.4 token 以及「七次以上的 Codex 工作階段」。¹有人（或多人）找到了這把金鑰，透過社群路由器進行請求，燒掉了 1 億個 token 的算力。路由器成了被竊金鑰的洗錢層。

研究二：配置較弱的誘餌。研究人員架設了配置較弱的誘餌端點。這些誘餌產出了 20 億個計費 token、橫跨 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金鑰、token、私鑰，任何看起來像憑證的東西），並將其送往攻擊者的基礎設施。

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. 在您的框架中加入故障關閉政策閘門。在 Claude Code 中，這意味著 PreToolUse 掛鉤會拒絕允許清單之外的工具呼叫，PostToolUse 掛鉤則在回應傳遞給下一次模型輪次前驗證其結構。掛鉤堆疊就是您的故障關閉政策層。

3. 絕不透過您無法控制的路由器執行 YOLO 模式。蜜罐中的 401 次自主工作階段就是前車之鑑。如果路由器是敵對的、而您的工作階段是自主的，那就是路由器在跑您的機器。

4. 記錄一切。僅允許追加的透明日誌能讓您重建事件經過。每一次請求。每一次回應。每一次工具呼叫。把它們儲存在路由器無法觸及的地方。

5. 如果您經營代理基礎設施，請強制執行密碼學完整性。如果客戶端與上游都由您操作，就在客戶端對請求簽章、在上游驗證簽章。那才是唯一真正的修復。路由器依然能看到明文，但無法在不使簽章失效的情況下做出任何修改。

令人不安的推論

路由器攻擊面是代理生態系「基礎設施出貨速度快過安全保障速度」的乾淨範例。人們想要一把API金鑰對所有模型通用。人們想要價格套利。人們想要區域存取。路由器把這些全都提供了。市場獎勵它們。而安全審查尚未發生。

MCP攻擊面已有 50 個已記載的漏洞。供應鏈攻擊面出現過一週內橫跨五個生態系的 TeamPCP 活動。沉默的對外流量攻擊面有 Clinejection 與 MCPTox 基準。現在再加上路由器攻擊面：研究了 428 個路由器，9 個正在積極注入惡意程式碼，17 個接觸了植入的憑證，1 個抽走了 ETH，401 次自主工作階段早已活躍於敵對的基礎設施之上。¹

每一次的模式都是相同的。我們打造了代理堆疊的新一層。開發者在任何人審查該層之前就採用了它。攻擊者登場。研究人員登場。社群撰寫出研究發現。有在關注的營運者修補了自己的部署。沒在關注的營運者則以艱難的方式學到教訓。

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

FAQ

在此脈絡下，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 次自主工作階段，我該做什麼？

那些工作階段屬於把流量路由經過研究人員誘餌的其他營運者。若您正透過任何自己沒有建置的路由器執行自主代理工作階段，第一步是停止。第二步是輪換所有曾經過該路由器的憑證。第三步是稽核您的工作階段日誌，看看是否有異常的工具呼叫或輸出。

參考文獻