AI 編碼工具資安：ZCode 上傳 4 萬個本機檔案

2026 年 9 月下旬，AI 工具圈接連出現兩起事件：一個是編碼助理在使用者不知情下，把整個工作區打包上傳到雲端；另一個是桌面 AI 助理的一個除錯設定，讓本機任何一支程式都能接走它的語音流量與認證權杖。技術細節完全不同，卻指向同一個問題——這一代 AI 工具拿到的權限，遠比使用者以為的多，而且幾乎沒有人在看它們實際做了什麼。

Photo by Jared Brashier on Unsplash

ZCode 打包的不是程式碼，是整部 Git 歷史

先講第一起。ZCode 是中國 AI 公司 Z.ai（智譜，GLM 系列模型的開發商）推出的編碼助理，提供桌面、瀏覽器與終端機三種工作環境。9 月 18 日，一位署名 ferstar 的工程師公開了他逆向 ZCode 3.12.3 版之後的發現：這個工具會自動把開發者的整個工作區打包成加密壓縮檔，送往阿里雲的物件儲存。

被打包的規模值得看清楚。在他分析的那一份壓縮檔裡，總共有 42,411 個檔案、313MB，其中 Git 相關資料佔了 86.6%——Git 快取資產 196.1MB、commit 物件 102.2MB，真正的原始碼反而只有 46.2MB。換句話說，上傳的主體不是「你現在正在寫的這幾支程式」，而是這個儲存庫從第一天到今天的完整開發歷史。

對開發團隊來說，這兩者差很多。Git 歷史裡通常躺著早期不小心 commit 進去、後來才移除的 API 金鑰與資料庫密碼，躺著每一次重構前的舊架構，也躺著分支名稱、commit 訊息與作者信箱。這些東西單獨看都不是機密，合在一起就是一份相當完整的內部情報。

另一個被討論得比較少、但更直接影響信任的細節是：這個上傳行為關不掉。ferstar 指出，介面上兩個看起來相關的隱私開關——「Optimize Experience」與「Repository Snapshot Indexing」——都不會阻止打包與上傳，而介面上也找不到任何一個真正能停掉上傳程序的開關。他的機器上累計出現 564 次上傳嘗試，全部失敗，也正是這些反覆失敗的連線讓行為被發現。如果上傳一次就成功，多數人可能永遠不會注意到。

「加密上傳」在這裡不是安慰，是問題本身

Z.ai 的做法在工程上並不粗糙。壓縮檔以 AES-256-CTR 加密，金鑰再用 RSA-OAEP-SHA256 包起來。問題出在鑰匙歸誰。相對應的私鑰只存在 Z.ai 的雲端，也就是說，能解開這份壓縮檔的只有 Z.ai 自己；使用者無從驗證裡面究竟裝了什麼，第三方研究者也無法獨立確認上傳內容的範圍。

Photo by rc.xyz NFT gallery on Unsplash

這是個被反覆重新包裝的老題目：加密保護的是「傳輸途中的第三方」，不是「收件人」。當收件人本身就是你沒打算給的對象，加密強度再高也不改變結果，反而讓外界失去稽核的可能——你只能相信對方的說法。

Z.ai 的回應相當快。同一天（9 月 18 日）公司致歉，表示資料在產生 wiki 之後隨即銷毀；9 月 20 日將 ZCode 以 Apache 2.0 授權開源；後續的 3.14.0 版移除了上傳功能，原本發放憑證的端點也改為回傳 404。從危機處理的角度看，這個節奏算是積極的。但「開源之後大家可以自己檢查」解決的是未來，解決不了已經上傳、且只有單方能解密的那些壓縮檔。

Muse：一個除錯設定，換走麥克風與權杖

第二起發生在 9 月 24 日。Objective-See 基金會創辦人、長年研究 macOS 安全的 Patrick Wardle 公開了 Meta 桌面版 AI 助理 Muse 在 macOS 上的一個零時差漏洞。核心是一個未寫在文件裡的設定鍵 endo_voyager_dictation_endpoint，它決定語音聽寫的音訊要送到哪個端點。

問題在於，這個鍵可以被本機任何一支非特權程序修改，不需要管理員權限，也不會跳出系統授權提示。一旦被改掉，聽寫流量就轉向攻擊者的伺服器。Wardle 示範的攻擊面有三層：直接取得原始麥克風音訊與有效的認證權杖；架設透明代理，一邊攔截一邊把請求照常轉發回 Meta，讓使用者端看不出異狀；以及在語音請求後方附加隱藏指令做提示注入，驅使助理在背景外洩本機文件或 WhatsApp 訊息紀錄。他把概念驗證工具命名為 not-a-mused。

Meta 很快推了修補，把這個除錯設定從正式版用戶端中拿掉，讓本機程序無法再改動聽寫目的地。但公司把它定調為「需要先取得程式執行權的本機設定問題」，因此沒有循正式流程指派 CVE 編號。這個定調在資安社群引起反彈：反對意見認為，像 ClickFix 這類社交工程手法要取得初始執行權其實門檻很低，而這個漏洞等於讓一般等級的惡意程式，用幾乎零成本的方式繞過平台防護，還不會觸發異常告警。

共同的結構問題：沒有人看得見 AI 代理在做什麼

把兩起事件並排，技術路徑不同，暴露的卻是同一個缺口：AI 工具要求的存取範圍越來越大，能夠檢視這些存取的機制卻幾乎沒有跟上。

Photo by mojtaba dorri ghabel on Unsplash

VentureBeat 針對 Muse 的後續分析把這件事講得很具體。Muse 確實會給「個別使用者」一份操作軌跡，讓你看到助理做了什麼、打算做什麼；但在企業層級，找不到對應的集中檢視。更麻煩的是憑證形態：直接貼給 Muse 的 API key 不會產生 OAuth 授權紀錄，而多數企業的資安監控是盯著 OAuth 授權在看的——這意味著這類存取在監控畫面上根本不存在。資安團隊只能從 API key 的發放紀錄、連接器活動、以及底層服務自己的稽核軌跡去拼湊，三套系統、三種格式。該報導也指出，Meta 的文件中沒有描述 SIEM 稽核匯出、IT 管理主控台或 DLP 整合這些企業治理的基本配備。

這個落差之所以危險，是因為 AI 工具的採用路徑通常繞過 IT。過去要導入一套會碰到程式碼與內部文件的系統，至少得經過採購與資安評估；現在一個開發者下載編碼助理、一個業務安裝桌面 AI 助理，十分鐘就完成，從個人生產力的角度看也完全合理。等到有人問「這工具到底把什麼送出去了」，往往已經用了好幾個月。

幾個可以先確認的問題

務實的做法，是把「這個 AI 工具的權限邊界」變成導入前的固定提問，而不是出事後的調查項目。可以先問的包括：它會讀取哪些路徑，是只讀目前開啟的檔案，還是整個專案資料夾？會不會把內容送到廠商伺服器，送的是片段還是整包？介面上的隱私開關實際關掉的是哪一段行為——ZCode 的案例正好說明，開關的名稱和它真正做的事可能不一樣。加密之後鑰匙在誰手上，出事時能不能請對方證明上傳了什麼。以及在企業環境裡，這個工具的存取紀錄能不能匯出到既有的監控系統。

對開發團隊還有一個更直接的檢查點：Git 歷史裡有沒有曾經 commit 過、後來才刪掉的憑證。這件事跟 AI 工具無關也該做，但 ZCode 事件把它的優先度往前推了一格。

值得留意的方向

AI 代理的價值來自於它能代替人操作，而能代替人操作的前提，就是拿到跟人一樣的存取權限。這個交換條件本身沒有錯，錯的是配套還停留在上一個時代：我們有成熟的機制管理「哪個員工能看哪份檔案」，卻還沒有同等成熟的機制管理「哪個 AI 代理能看哪份檔案、實際看了哪些、送去了哪裡」。

Meta 拒絕為 Muse 的漏洞指派 CVE，某種程度上也反映了這個灰色地帶——當漏洞出在一個「AI 助理的設定鍵」上，它到底算作業系統的問題、應用程式的問題，還是一種全新的、介於兩者之間的攻擊面，業界目前並沒有共識。而在共識形成之前，能保護自己的大概只有兩件事：導入任何 AI 工具之前，把權限邊界問清楚；以及，不要假設介面上那個開關真的關掉了什麼。