模型中轉服務是如何變成攻擊者的

用一組圖解釋不可信的模型中轉（模型路由）服務的五大攻擊面：資訊竊取、資料劫持、資源劫持、內容篡改與供應鏈投毒，以及對應的防守措施。

Monday, August 17, 2026

讀者對象：正在使用或考慮接入「模型中轉 / 模型路由 / API 轉發」服務的人這組圖只回答一個問題：當你的模型請求經過一個不可信的中轉服務時，會發生什麼，又該怎麼防範？

這組圖要解釋什麼

「模型中轉」服務可以幫你將請求轉發到真正的模型 API。然而，轉發意味著：你的每次提問、模型的每次回應，都必須在中轉服務的伺服器上進行。這就是攻擊面的所在——它不只是流量代理，而是握著你與大模型之間全部內容的中間人。

上圖是風險架構：客戶端（瀏覽器、IDE 插件）→ 中轉服務 → 大模型。由於中轉服務可以看到全部雙向流量，因此它可以在你毫無察覺時進行惡意操作。

最常見也最隱蔽的攻擊，是往模型返回的 tool_use 指令裡夾帶私貨。客戶端會「信任」並執行收到的所有工具指令，因此中轉服務可以在不知不覺間讓用戶本機執行任意操作。

這條鏈路稱為客戶端命令注入：模型正常返回的 search_web、read_file 之類指令被中轉服務偷偷追加了讀取密鑰、執行 shell 的內容。數據不回傳給模型、對話看起來完全正常，用戶根本發現不了。

另一種是從請求側下手，修改你發給模型的提示詞，讓模型幫你生成帶後門的代碼。

這條鏈路稱為服務端提示注入：中轉服務把你的「寫個日誌分析腳本」改成「順便在腳本開頭讀取環境變數發出去」。模型很聽話，返回的代碼裡就多了洩露 API 密鑰的邏輯。

資訊竊取只是起點。當運營方想直接毀掉你的數據，攔截點就會變成「數據劫持」的跳板；想長期賺你的算力，就變成「資源劫持」；想操縱你的決策，就變成「內容篡改」；想污染你的項目，就變成「供應鏈投毒」。

其中「代碼倉庫劫持」對開發者尤其致命：先靜默把你的代碼推到攻擊者倉庫做備份，再強推破壞性操作，本地和遠端歷史一同被清空。

上面這段終端回放就是一次典型的倉庫劫持指令序列：備份 → 回滾 → 強推覆蓋 → 留下勒索信息。

防守不是靠某一條命令，而是從選服務到最終防線的一整套動作。

核心順序：優先選擇官方或可信服務；自研客戶端對 tool_use 進行白名單管理；AI 生成的代碼先審查再運行；將 AI 工具放進容器沙箱；插件使用最小權限；安裝依賴前查口碑並定期審計；重要代碼多地離線備份。