GitSpawn 陷阱:當 AI 代理幫你寫程式，也幫駭客開了大門

資安公司 Manifold Security 揭露「GitSpawn」攻擊手法——不可信任的程式碼倉庫可透過 AI 編碼代理間接執行惡意程式。在台灣科技業全面擁抱 AI 輔助開發的此刻，這道供應鏈裂縫比大多數人想像的更近。

一個開源專案、一個 AI 編碼代理、一行悄悄執行的指令。2026 年 9 月初，資安公司 Manifold Security 在部落格揭露被稱為「GitSpawn」的攻擊路徑:開發者只是叫 AI 代理去讀取、整理某個公開倉庫，代理卻可能在中途被倉庫內容誘導，執行不該執行的程式碼（來源:https://www.manifold.security/blog/ai-coding-agents-git-hijack）。問題來了:當「讀程式碼」和「跑程式碼」的界線在 AI 代理手上變得模糊，台灣數十萬軟體工程師的工作流程，是不是出現了一個沒人設防的後門？

攻擊不走作業系統，走的是「代理的信任鏈」

傳統的供應鏈攻擊，目標是套件管理器或建置腳本；防護思維是「不要執行來路不明的東西」。但 GitSpawn 揭露的是更陰險的一層:AI 編碼代理本身有極大的檔案系統與指令權限，倉庫裡的文字——README、註解、issue 範本——都可能成為對代理的「提示注入」（prompt injection）。工程師以為只是叫 Copilot 類工具「看一下這個 repo」，代理卻可能在解讀過程中，被內嵌的指令帶著安裝、執行、外傳資料。

換個比喻:過去你擔心的是快遞箱裡有炸彈；現在的問題是，你家請的助理會自己拆箱、而且助理會聽箱子裡那張紙條的話。Manifold 的分析指出，攻擊面不在單一漏洞，而在整個「人類授權、代理執行」的信任模型（來源同上）。

這對台灣尤其切身。台灣軟體業與半導體供應鏈大量採用 AI 輔助開發已是不爭的產業現實，而社群的回應也來得很快——8 月底就有開源專案「Grith」在 Hacker News 上發表，主打 Linux 上針對 AI 編碼代理的系統呼叫層級監控，等於承認「用 sandbox 隔離代理」已經是剛性需求（來源:https://github.com/grith-ai/grith）。

市場照樣缺人，安全卻沒跟上招聘速度

一個殘酷的對比:Indeed 求職網站上，與「AI coding agents」直接相關的職缺超過 12,000 筆（據該網站列表頁顯示約 12,436 筆，https://www.indeed.com/q-ai-coding-agents-jobs.html）; broader 的「AI coding」職缺更是橫跨自動化、工作流、代理開發等領域（https://www.indeed.com/q-Ai-Coding-jobs.html）。企業一邊高速招聘把代理塞進開發流程，一邊卻多半還沒建立「代理權限治理」的制度。招聘有預算，治理沒編制——這個落差，正是 GitSpawn 這類攻擊的溫床。

三種未來情境

情境一（基準）:工具鏈補洞。IDE 供應商與代理框架逐步內建最小權限、沙箱與指令白名單，Grith 這類獨立監控工具被企業採購，傷害控制在個案層級。

情境二（悲觀）:大規模供應鏈事件爆發。某熱門開源專案被植入誘導式內容，數千個使用 AI 代理的團隊同時中招， Secrets 外洩、建置環境遭汙染，屆時監管才被迫介入。

情境三（樂觀）:資安廠把「代理行為監控」變成新品類，台灣的資安產業——從端點防護到 SOC 服務——有機會切進這個新賽道。

記者也該自問:這有多嚴重？

必須誠實面對分析的限制。GitSpawn 一詞出自單一資安公司的部落格與社群討論，目前公開資訊中未見大規模實際受害案例的證實；Manifold 有商業動機放大威脅（賣偵測方案的公司揭露威脅，是資安業的常態，不代表不實，但讀者該保持警覺）。提示注入的實際可利用性，也高度取決於各代理工具的權限預設值，不同產品風險差異極大。

但方向性判斷站得住腳:當執行權從人類手上移到會「閱讀外部文字」的代理手上，攻擊面就從程式碼擴張到了自然語言本身。台灣的工程團隊下一步該問的，或許不是「要不要用 AI 代理」，而是——你公司裡那個代理，今天讀了誰的程式碼？