核心命題： 傳統供應鏈投毒至少留下程式碼；AI 供應鏈投毒可能完全不留痕跡——一個被微調過的模型，行為異常卻找不出哪一行有問題。 本文角度： 風險機制與防護原則。不含任何操作細節。
為什麼 AI 供應鏈更複雜
傳統軟體供應鏈的環節相對清楚：依賴套件 → 建置 → 部署。你有清單、有雜湊、有掃描工具。
AI 系統多了幾層：
| 環節 | 傳統軟體 | AI 系統 |
|---|---|---|
| 程式碼 | ✅ 有 | ✅ 有 |
| 依賴套件 | ✅ 有 | ✅ 有（更多） |
| 模型權重 | ❌ 無 | ⚠️ 有（來自外部） |
| 訓練資料 | ❌ 無 | ⚠️ 有（可能來自網際網路） |
| 外部工具／插件 | 少 | ⚠️ 多（MCP、函式呼叫） |
| 提示詞／系統設定 | ❌ 無 | ⚠️ 有（可被注入） |
每一層都是一個潛在的攻擊面，而且大部分無法用傳統掃描工具檢查。
五個環節的投毒機制
環節一：模型權重
機制： 使用第三方提供的模型權重（開源模型、微調版本），而權重本身可能被植入特定行為——例如對某個特定觸發詞反應異常。
為什麼難： 權重是數十億個浮點數，沒有「原始碼」可讀。傳統的程式碼審查完全失效。
環節二：訓練資料
機制： 在訓練或微調資料中混入特定樣本，讓模型學到不該學的行為或偏見。
為什麼難： 資料集可能來自網路爬取，規模以 TB 計，無法逐筆審查。
環節三：依賴套件（與傳統相同，但更多）
機制： 與傳統供應鏈相同——套件替換、名稱混淆、維護者憑據被竊。
為什麼更嚴重： AI 生態的套件數量爆炸性增長，而且很多是個人維護的小套件，審查資源跟不上。
環節四：外部工具與插件（MCP 類）
機制： 當 AI 代理被允許呼叫外部工具（瀏覽器自動化、程式執行、API 呼叫）時，這些工具本身可能被投毒——回傳被操縱的結果，或執行非預期的動作。
為什麼特別危險： 這是能力放大器。一個被投毒的工具，等於給代理一個「被操控的感官」。
環節五：提示詞與設定檔
機制： 系統提示詞、工具描述、設定檔被修改，導致代理行為改變。
為什麼難： 這些通常被視為「配置」而非「程式碼」，往往沒有版控與審查流程。
攻擊者的三個動機
- 持久化：一次投毒，長期有效；
- 隱蔽性：藏在正常更新或資料中；
- 放大：影響所有使用該模型／套件／工具的下游使用者。
防守的五條原則
原則一：來源可追溯（Provenance）
每一個元件都要能回答：它從哪裡來、經過誰的手、什麼時候被使用。
- 模型權重：記錄來源、版本、雜湊；
- 資料集：記錄來源與處理步驟；
- 套件：鎖定版本與雜湊（與傳統供應鏈相同）。
原則二：最小能力（Least Capability）
給 AI 代理的工具權限最小化：
- 能讀就不要給寫；
- 能查詢就不要給執行；
- 每個工具獨立授權，不要「一次全開」。
這一條與本系列《內部威脅與權限治理》的原則完全一致——代理是一個新的內部身分。
原則三：外部輸入一律視為不可信
- 網頁、文件、API 回應中的文字 → 是資料，不是指令；
- 外部工具的輸出 → 需要驗證，不能直接當成事實；
- 這也正是本系列《蜜罐與反 AI 代理陷阱》的核心規則。
原則四：行為監控（而非只看輸入）
既然輸入無法完全審查，就要看輸出與行為：
- 代理是否做了超出其職責範圍的動作？
- 工具是否回傳了異常的結果？
- 有沒有「同質重複」或「突然轉向」的模式？
原則五：可回滾
任何 AI 元件（模型、工具、提示詞）都應該能快速回退到已知良好版本，並且知道「回退之後會影響什麼」。
為什麼這一篇與前面幾篇是同一件事
把本系列串起來看，AI 供應鏈投毒其實是多重風險的交集：
| 本系列篇目 | 交集點 |
|---|---|
| 09 供應鏈與第三方風險 | 傳統供應鏈機制（套件、服務商） |
| 06 蜜罐與反 AI 代理陷阱 | 提示注入、外部內容不可信 |
| 10 雲端身分與權限 | 工具與代理的憑據管理 |
| 12 內部威脅與權限治理 | 代理作為新的內部身分 |
共同結論： 當 AI 代理成為新的「內部身分」，傳統的邊界防禦與程式碼審查都不足夠——需要的是來源可追溯、能力最小化、行為可監控、隨時可回滾。
三個一句話
- AI 供應鏈多了三層無原始碼的環節。 模型、資料、提示詞，傳統掃描工具幫不上忙。
- 能力最小化是最有效的防線。 代理拿不到的權限，就無法被濫用。
- 輸入不可信、行為要看緊、隨時能回滾。 這三條是目前最務實的組合。
下一步
- 想了解傳統供應鏈風險，可閱讀供應鏈與第三方風險
- 想了解針對代理的陷阱，可閱讀蜜罐與反 AI 代理陷阱
- 想了解權限治理原則，可閱讀零信任架構