技術博主ferstar在9月18日釋出對智譜ZCode的逆向分析，指該程式設計Agent在使用者登入狀態下，會在後台把整個工作專案連同完整修改歷史打包加密，上傳至雲端伺服器。這一發現把AI Agent安全討論的重心，從模型失控、提示詞投毒和外部攻擊者，轉向了一個此前很少被認真對待的方向：Agent的製造商本身是否也可能成為資料外傳的來源。
ferstar的排查起點是本地硬碟佔用異常。他找到一個約313MB的加密檔案，附帶清單顯示其中涵蓋約4.2萬個檔案，超過八成屬於專案歷史修改記錄，還包括曾下載的大檔案快取和本地操作日誌。程式碼分析顯示，歷史記錄目錄在打包流程中被排在金鑰過濾和體積限制之前，意味著針對pem、key等密碼檔案的過濾和1MB體積上限對它不生效，曾提交進歷史記錄又被刪掉的金鑰也可能原樣上傳。
更受關注的是加密與上傳機制。客戶端先向智譜伺服器索取上傳憑證和一把公鑰，本地完成壓縮加密後，繞過智譜業務伺服器直接上傳至阿里云云儲存，再由雲端儲存回撥智譜後台。公鑰相當於鎖、私鑰相當於鑰匙，而鑰匙只儲存在伺服器一側，使用者無法檢視加密包內容。ferstar發現該機制在使用者傳送請求前和任務結束後觸發，活躍使用中他觀察到多達62次快照記錄。介面上的“最佳化體驗”和“倉庫快照索引”兩個選項，經對照程式碼確認分別只控制是否用於模型訓練、是否在服務端建立檢索目錄，兩者都關閉時本地打包和上傳照常執行。他還嘗試手動刪除那個313MB待發送檔案，半小時後ZCode自動重新生成，該檔案當時已失敗564次。
智譜當晚致歉，稱問題源於ZCode的“程式碼庫索引”功能，Repo Wiki在生成Wiki頁面時可能觸發倉庫資料上傳，資料在雲端生成後立即銷燬、不會儲存，該功能上線初期預設開啟，相關問題已修復，並承諾近期開源ZCode程式碼庫、邀請第三方審查、為全體使用者額外補償一次周額度重置。
但社群追問與官方說明之間存在落差。智譜稱索引“旨在幫助使用者在本地生成”，卻未解釋為何需要把專案整體送往雲端；ferstar的記錄顯示觸發上傳的時機之一在使用者每次提問之前，與生成說明文件無關；官方文件稱生成說明文件不讀取歷史修改記錄，而上傳包中約86.6%是歷史記錄。此外，ZCode v3.12.2版本更新日誌中一條“最佳化倉庫快照上傳的記憶體佔用”的記錄在事件發酵後被刪除。開發者馮若航的獨立復現顯示，客戶端每次提問都會無條件申請上傳憑證，他確認至少有一份快照的狀態檔案已寫入服務端接受確認的標記，意味著至少有一台機器上的資料確實離開了本地。
ZCode並非孤例。今年7月，獨立安全研究者cereblab通過抓包分析指出，SpaceXAI(原 xAI)的程式設計Agent工具Grok Build會把使用者整個專案打包上傳至谷歌雲端儲存，包括使用者明確告知AI不要讀取的檔案和未經脫敏的密碼，在一個12GB測試專案中已確認上傳體積超過5G；馬斯克隨後公開承諾刪除所有已上傳資料，SpaceXAI在伺服器端關閉了上傳功能。更早的3月31日，Anthropic的Claude Code因配置疏忽把約60MB原始碼對映檔案誤打包進公開發布的安裝包，社群還發現其每小時輪詢遠端配置、讀取代理與中國時區等環境訊號，Anthropic工程師確認那是一次反賬戶濫用和反蒸餾的主動實驗。
三起事件被發現的方式值得注意：一次靠配置失誤洩露原始碼，一次靠安全研究者主動抓包，一次靠博主對硬碟空間的警覺，均非來自廠商自發排查或行業審計。與此同時，過去一年Agent安全規則快速更新——OWASP釋出面向自主AI Agent的十大風險清單、新加坡出台相關治理框架、美國國家標準與技術研究院啟動標準倡議、歐盟人工智慧法案高風險義務生效——但這些規則防的是工具被外部攻擊者利用，其設計假設是廠商站在使用者一邊，而廠商自身的資料外傳通道恰在這一假設的盲區裡。
從動機看，專案歷史修改記錄中的改動因果鏈、帶結果標註的使用軌跡、以及未被任何模型見過的真實專案，對訓練程式設計模型確有價值，這與上傳包的構成存在吻合之處；但從打包的粗放程度看，激進的產品決策疊加工程層面的複用與偷懶，比有意的系統性採集更貼合現有證據。無論意圖如何，使用者能看到的只是資料離開了自己的電腦，之後發生什麼取決於廠商的自我約束，而開源與第三方審查能否改變這一點，取決於開源的是哪個版本、審查覆蓋客戶端還是服務端。