最近看到一個 AI 開發圈的安全警訊：有人用看起來很像官方工具的名稱，包裝出一個「好像能保護隱私、好像跟知名服務有關」的模型或程式倉庫。這類事件不一定每次都會造成大規模災情，但它提醒我一件事：AI 工具鏈的供應鏈安全，已經不能只用傳統套件管理的想像來看了。
以前我們談供應鏈安全，第一個想到的通常是 npm、pip、Docker image、CI/CD action。現在還要再加上模型倉庫、資料集、LoRA、embedding、prompt 範本、agent tools，甚至是一段「貼進設定檔就能用」的 JSON。
模型倉庫也是依賴，不是參考資料
很多團隊在使用開源模型或 AI 工具時，心理上會把模型倉庫當成「下載資源」：看到名稱像、README 寫得像、星星數看起來也還行，就先拉下來試試看。
這個習慣在早期實驗階段很自然。AI 發展太快，大家都在追新模型、新工具、新 benchmark，今天看到一個有趣的 repo，明天就想接進自己的 workflow 測看看。問題是，當這些東西開始從玩具變成工作流程的一部分，它就不再只是參考資料，而是正式依賴。
依賴就要有依賴的管理方式。
我們不會隨便把一個來源不明的 npm package 放進正式環境，也不應該隨便把一個來源不明的模型、資料集或 agent 工具接進會讀取內部資料的系統。尤其現在很多 AI workflow 不是只做推論，它會讀檔案、查資料庫、呼叫 API、產生自動化操作。如果入口處的依賴被污染，後面的權限就可能全部被借走。
AI 供應鏈的邊界比以前更模糊
傳統軟體的供應鏈邊界相對清楚：程式碼、套件、容器、部署腳本。當然也很複雜，但至少我們大致知道哪些東西會被執行。
AI 工具鏈麻煩在於，很多「看起來不像程式碼」的東西，其實會影響系統行為。
模型權重看起來只是數字，但載入流程可能附帶自訂程式碼。資料集看起來只是文字，但可能影響微調後的行為。prompt template 看起來只是說明，但對 agent 來說就是操作規則。工具設定看起來只是 schema，但它定義了模型可以碰哪些 API、用什麼參數、在什麼情境下執行。
換句話說，AI 系統的供應鏈不只包含「會跑的 code」，也包含「會改變決策的 context」。
這是我覺得很多團隊還沒完全轉過來的地方。大家會掃 package vulnerability，會鎖 Docker digest，會檢查 GitHub Actions 權限；但對模型來源、資料來源、prompt 來源，常常還停留在「先試試看」的心態。
實驗可以這樣，產品不行。
名稱相似是最便宜、也最有效的攻擊面
供應鏈攻擊最討厭的一點，是它常常不需要很高明。
不需要突破你的防火牆，也不需要找到零日漏洞。只要取一個很像官方的名字，做一個看起來合理的 README，放幾張漂亮截圖，甚至補上一點真的能跑的功能，就有機會讓忙碌的工程師在某個下午複製貼上。
AI 圈又特別容易中招，因為資訊流速太快。新的模型、新的工具、新的 benchmark 每天都在出現，很多東西在社群上被轉貼幾次，就會產生一種「好像大家都知道」的錯覺。
身為技術主管，我不太喜歡把這種問題簡化成「工程師不夠小心」。真正的問題是流程沒有設計好。如果每次引入新 AI 工具都靠個人警覺，那遲早會出事。人會累，專案會趕，README 會寫得很像真的。
安全流程不能建立在「大家都很清醒」這種假設上。這個假設太樂觀了，也太殘忍。
我會怎麼要求團隊處理 AI 依賴
如果團隊開始大量使用外部 AI 工具，我會把幾件事變成基本規則。
第一，來源要可追溯。模型、資料集、工具、prompt template，都要記錄來源、版本、下載日期與用途。不是為了寫文件而寫文件，而是未來發現問題時，知道哪些系統受影響。
第二，正式環境不要直接追 latest。這在套件管理上是常識，但 AI 工具很容易破戒。今天一個模型更新，效果看起來更好，就直接換上去。結果行為變了、輸出格式變了、授權條款變了，甚至來源也可能變了。正式系統需要固定版本，需要可重現。
第三，把模型與工具權限分開看。模型可以很強，但它不應該因此自動擁有高權限工具。能讀公開資料的 agent，跟能查內部文件、能寫資料庫、能發訊息的 agent，風險完全不同。權限應該跟任務綁定，不是跟模型能力綁定。
第四，建立一個輕量審查清單。不要搞到像大企業採購流程一樣重，但至少要問：來源是不是官方？維護者可信嗎？授權能不能用？是否需要執行遠端程式碼？是否會接觸敏感資料？如果出事，要怎麼回滾？
這些問題不性感，但很實用。
AI 導入越快，越需要基本功
我一直覺得，AI 導入真正困難的地方，常常不是模型本身，而是它把原本軟體工程裡那些被忽略的基本功放大了。
你的依賴管理鬆散，AI 會讓它更危險。你的權限邊界模糊，agent 會讓它更難控。你的流程沒有版本概念，模型更新會讓你更難追。你的團隊習慣靠口耳相傳，新的工具鏈會讓知識斷層更快出現。
所以我現在看 AI 安全，不會只問「這個模型會不會洩漏資料」。那當然重要，但範圍太窄。我更想問的是：這個 AI workflow 裡有哪些外部依賴？誰決定可以引入？版本怎麼鎖？權限怎麼切？出問題怎麼停？
如果這些問題答不出來，就算 demo 再漂亮，我也不會放心。
小結：不要讓新工具繞過舊紀律
AI 工具鏈會越來越豐富，這是好事。開源模型、社群工具、現成 agent template，都會大幅降低開發門檻。小團隊可以用以前難以想像的速度做出內部自動化，這件事本身很令人興奮。
但速度越快，越不能讓基本紀律消失。
模型倉庫不是免洗連結，prompt 不是隨手貼的便利貼，agent tool 也不是單純的設定檔。只要它會影響系統行為、碰到資料、改變決策，它就是供應鏈的一部分。
我不覺得每個團隊都需要一開始就導入很重的安全治理。過度治理會把創新速度掐死，小團隊也吃不消。但至少要先建立一個觀念：AI 依賴也是依賴，AI 工具也是工具，AI workflow 也是正式系統。
不要因為它看起來新，就讓它繞過那些老派但有用的工程紀律。
很多事故不是因為技術太難，而是因為我們太快相信一個看起來很方便的東西。AI 時代尤其如此。