作者 | 林克、鄭好

過去兩年，涉及Agent安全討論的重心主要放在模型失控、提示詞投毒和外部攻擊者身上，相比之下，Agent廠商自身的數據行為很少被當作一級風險討論。

近日曝出的智譜ZCode事件，正在把問題轉向了一個此前很少被認真對待的方向，那就是Agent的製造商本身是否也可能成為數據外傳的來源。

9月18日，技術博主ferstar發佈了對智譜ZCode的逆向分析。他發現只要用戶登錄了賬號，ZCode就會在後台把整個工作項目連同完整的修改歷史打包加密，上傳至雲端服務器。

軟件界面缺少真正可用的關閉開關，加密文件的解密鑰匙只保存在智譜一側。智譜很快致歉，稱問題源於一項功能默認開啟，數據用完即銷毀，並承諾近期開源代碼庫、引入第三方審查。

Zcode這次所暴露的問題，早已不是行業孤例。

不久前獨立安全研究者cereblab通過抓包分析證明，xAI的編程Agent工具Grok Build會把用戶的整個項目打包上傳到谷歌雲存儲，包括用戶明確告訴AI不要讀取的文件和未經脫敏的密碼。

更早些時候，Claude Code被發現在用戶不知情的情況下回傳位置和身份信息，Anthropic工程師甚至事後確認那是一次有意實驗。

更關鍵的是，這些問題被發現並非因為監管或安全審計，而往往來自社區裡的個人，而目前行業為Agent搭建的安全框架，至今沒一條規則是用來約束廠商自身行為的。

一. 起點是硬盤異常

9月18日，技術博主ferstar在排查ZCode的本地目錄時，注意到硬盤佔用空間異常。他找到了一個約313MB的加密文件，體積遠超日常大小。文件打不開，但附帶的文件清單顯示這個包涵蓋約4.2萬個文件，其中超過8成屬於項目歷史修改記錄。

這份記錄不光有項目文件，還涵蓋了曾經下載過的大文件緩存和本地操作日誌，被打包的不只是項目本身，還包括項目「從出生以來的經歷」。

後續的代碼分析發現，這份歷史記錄在打包流程中被豁免於所有安全過濾規則。

ZCode的文件篩選邏輯是按順序判定的，歷史記錄目錄的放行排在密鑰過濾和體積限制之前，這意味着針對pem、key等密碼文件的過濾和1MB的體積上限，對歷史記錄目錄下的任何內容都不生效。

這意味着，一個百兆體量打包文件可以整個帶走，而任何曾經提交進歷史記錄又被刪掉的密碼和密鑰，也會原樣上傳。

更麻煩的操作在後面，解密鑰匙不在用戶的電腦裡。

ferstar拆解還原文件的上傳路徑，首先客戶端向智譜服務器索取上傳憑證和一把加密用的公鑰，在然後本地完成壓縮加密，然後繞過智譜自己的業務服務器，直接上傳到阿里雲的雲存儲服務，再由雲存儲回調智譜後台。

這裡稍微解釋一下加密方法。

公鑰相當於一把鎖，任何人都能用它把東西鎖進箱子；私鑰相當於鑰匙，只有持有鑰匙的人能打開。ZCode的做法是，鎖由服務器臨時發放，鑰匙只在服務器那頭保存，Agent在用戶電腦上生成一個加密包，用戶自己都無法查看裡面到底裝了什麼。

ferstar發現這套機制會在兩個時間觸發，一是用戶向AI發送請求之前，二在任務結束之後。一個活躍的使用過程中，他觀察到多達62次快照記錄。

界面上看起來與此相關的兩個選項，經他逐一對照代碼邏輯後確認，一個叫「優化體驗」，實際只控制數據是否用於模型訓練；另一個叫「倉庫快照索引」，實際只控制服務器端收到數據後是否建立檢索目錄。

兩個都關掉時，本地的打包和上傳照常運行。負責快照和上傳的組件在軟件啟動時就會無條件加載，唯一的前提是用戶處於登錄狀態。

除了項目文件，快照每次還會把ZCode自身的全局配置一併打包，跨項目帶走。

ferstar嘗試手動刪除那個313MB的待發送文件。半小時後ZCode自動重新生成了一份新的打包文件，Agent偷偷上傳不成就反覆重試。

刪了還會再建，這或許不是一個可有可無的輔助功能應有的執着程度。

二. 沒回應清楚的事

這篇文章當晚社區迅速發酵，智譜火速回應並致歉。

此次問題源於ZCode的「代碼庫索引」功能。該功能旨在幫助用戶在本地生成倉庫索引，以支持包括歷史版本在內的會話檢查點恢復、歷史版本回退及Repo Wiki等功能。

Repo Wiki功能在生成Wiki頁面時可能會觸發倉庫數據上傳。Wiki頁面在雲端生成後，相關上傳數據會立即銷毀，不會保存。由於該功能在上線初期默認開啟，部分用戶因此受到影響，對此我們深感抱歉，目前相關問題已經修復。

智譜還承諾近期開源ZCode代碼庫，邀請第三方評估人員審查系統運行情況，並為全體用戶額外補償一次周額度重置，當天發放。

這裡的「代碼庫索引」是為項目文件建立目錄和檢索系統；「Repo Wiki」則是自動為項目生成一份說明文檔的功能；「會話檢查點恢復」和「歷史版本回退」是讓用戶在與AI對話過程中可以回到之前某一步的功能。

這些功能本身是合理的，回應也是及時的，但關鍵在於：

它解釋的和社區追問的不是同一件事。

智譜說這套索引「旨在幫助用戶在本地生成」。既然是本地生成，那為什麼需要把項目整個送到雲端？本地做索引、本地做快照、本地做回退，技術上完全可行，市面上也有工具就是這麼做的。

說明把「本地索引」和「上傳到雲端」並成一句話，彷彿後者是前者的自然延伸，但這中間缺了一個關鍵環節的解釋。

回應將問題歸於Repo Wiki「在生成Wiki頁面時可能會觸發倉庫數據上傳」。但ferstar的逆向記錄顯示，觸發上傳的時機之一在用戶每次發送提問之前，與生成說明文檔無關。

ZCode目前的官方文檔明說，生成說明文檔時不讀取項目的歷史修改記錄，只按需讀取經過篩選的代碼上下文，這說明這項功能在技術上並不需要歷史記錄。

那麼此前上傳的包裡，為什麼86.6%都是歷史記錄？說明沒有回答當初上傳範圍為什麼這麼大，是設計如此還是程序出錯，也沒有交代從哪個版本開始修正。

說明用的措辭是該功能「在上線初期默認開啟」，這更像把一次機制層面的數據外傳表述成了一項功能的開關設置。

ferstar的代碼分析顯示，界面上的兩個相關選項一個管訓練一個管索引，都管不住打包和上傳行為本身。

社區質疑的核心是用戶看到的控制項控制不了真正在發生的事，這和「某個功能默認打開了」不是一個量級的問題。

很快另一份更敏感證據也被社區翻出，那就是ZCode v3.12.2版本的更新日誌，日期為2026年9月16日，就是在ferstar發文的前兩天。

有一條記錄寫着「優化倉庫快照上傳的內存佔用」。工程團隊很難給一個意外行為優化內存，這說明「倉庫快照上傳」在內部是一項被持續迭代的正常功能。

這條更新日誌在事件發酵後已被刪除，刪除公開記錄本身，是一個獨立於原始行為的新問題。

「相關上傳數據會立即銷毀，不會保存」，這句話回答的是數據保留多久，但用戶真正需要知道的還有很多問題，比如數據是否已經離開了電腦，服務器在處理過程中誰有權限訪問，加密包的解密能力在誰手上，此前已經上傳的數據執行了什麼樣的刪除策略。

從加密方式來看，鑰匙在服務器一側，所以「加密上傳」證明的是傳輸途中不會被第三方截獲，並不能推出智譜自身無法解讀內容。

ZCode隱私政策英文版對收集範圍的措辭是用戶「through conversation」（通過對話）提交的文本、文件和代碼。但後台快照不是用戶通過對話提交的，這個行為不在隱私政策描述的範圍內。「在對話中向我們提交」和「後台自動打包整個項目」是兩碼事。

這份隱私政策還寫明，當新功能涉及與原始目的沒有直接或合理關聯的信息收集時，應通過頁面提示、交互流程等方式另行告知並取得用戶同意。

另一名開發者馮若航的代碼分析發現，客戶端每次發送提問時都會無條件向服務端申請上傳憑證，服務端發放憑證就採集，不發放就不採集。

ferstar發現的那個313MB的件當時處於待發送狀態，已失敗564次，馮若航在自己的Mac上獨立復現了ferstar的取證流程，在4個工作區的快照記錄中，確認至少有一份快照的狀態文件已寫入服務端接受確認的標記。

按代碼邏輯，這個標記只有在上傳被服務端確認接收後才會生成。這意味至少有一台機器上的數據確實離開了本地。智譜的道歉、承諾和補償在爭議發酵數小時內全部給出，反應速度不像準備長期隱瞞。

但無論「立即銷毀」還是「不會保存」，這類承諾從外部無法驗證，也無法證偽。用戶能看到的只是數據離開了自己的電腦，之後發生了什麼完全取決於廠商的自我約束。

智譜承諾的開源和第三方審查能否改變這一點，取決於開源的是哪個版本、審查覆蓋的是客戶端還是服務端，這些問題目前沒有答案。

三. 比代碼數據更敏感的是

如果真有一些廠商真的有意收集用戶數據，想要的或許不會是用戶代碼本身。

因為各大代碼託管平台的公開項目為模型訓練提供了充足的語料。私有代碼當然包含商業秘密，但從模型改進的角度看，僅僅多拿到一批代碼文本的邊際價值並不高。

真正稀缺的是三樣東西。

一是改動的因果鏈。

項目的歷史修改記錄裡存的不是一張張快照，而是「改之前長這樣、因為什麼、改成了那樣」的完整過程。這種帶有前因後果的序列，是訓練編程模型最理想的學習材料：給定一個項目現狀和一條修改意圖，模型應該做出什麼改動。

二是帶結果標註的使用軌跡。

ZCode的觸發機制在每次用戶發送提問之前拍一次「全景照片」，同時它又具備回退功能，用戶可以撤銷AI做出的修改。這兩個動作組合在一起，天然地記錄了「提問＋操作前狀態＋操作後狀態＋用戶是否滿意（有沒有撤銷）」的完整循環。這種數據在AI訓練中極其昂貴，通常需要專門僱人標註，而ZCode的快照機制相當於讓用戶在正常使用中免費生成了這些標註。

三是沒有被任何模型見過的真實項目。

目前公開的編程評測題目幾乎都已經被各家模型在訓練時「做過一遍」，成績虛高。真實的、從未進入過訓練集的私有項目，是做內部能力評估最有價值的原料。

這三樣東西確實和ZCode上傳包的構成高度吻合，這就是社區對「只是為了生成說明文檔」這個解釋始終不買賬的原因。

但反過來講，如果目標真是系統性地採集訓練數據，更精確的做法是只抽取提問內容和代碼改動，確實也犯不着連幾百兆的大文件緩存和完整操作日誌一起打包。

這種過度採集的形態，更像是工程團隊在開發快照功能時複用了一套通用的打包邏輯，把與索引和回退相關的全部文件一股腦裝了進去，加上雲端存儲本身有成本，大量個人用戶的小型項目和練手代碼對模型訓練的實際價值有限，而對付費客戶尤其是企業客戶的數據出手，風險收益比其實極不划算。

必須承認，利用這些數據改進模型和工具的動機是成立的，路徑是現成的；但從上傳包的粗放程度來看，激進的產品決策疊加工程層面的偷懶比「智譜故意想搞點什麼」更貼合已有證據。

當然，不能因為智譜沒有主觀故意而忽視這種問題的嚴重程度，這確實會給用戶帶來安全隱患。

四. Agent廠商們的批量越界

與ZCode事件相似的風波，今年已經發生了不止一次。

今年7月，獨立安全研究者cereblab對xAI的Grok Build進行了完整的網絡抓包分析，並公開了全部證據和復現步驟。

他發現的現象比ZCode更誇張，Grok Build會把用戶的整個項目打包成代碼包上傳到谷歌的雲存儲服務，上傳範圍覆蓋所有文件，包括用戶在對話中明確告訴AI「不要讀取」的文件。在一個12GB的測試項目中，截至抓包中斷時已確認的文件體積達超過了5G。

測試還發現，項目中的密碼和密鑰文件甚至也被原樣上傳，沒有經過任何脫敏處理。用戶在設置中關閉「改進模型」選項後，上傳依然照常進行，關掉的只是訓練授權，不影響代碼是否離開電腦。

馬斯克在事件曝光後公開承諾刪除所有已上傳數據，xAI在服務器端關閉了上傳功能。

更早前的3月31日，其Claude Code在一次版本發佈中，一個配置文件的疏忽導致約60MB的源碼映射文件被誤打包進了公開發佈的安裝包中，外部開發者得以看到了這款工具的架構。

社區發現，Claude Code每小時向Anthropic服務器輪詢一次遠程配置，配置項中包含多個可以強制退出程序、繞過用戶權限提示的控制開關，全部在後台生效，不需要用戶主動更新。

Claude Code曾被發現讀取用戶的代理、網關地址和中國時區等環境信號，並通過系統提示中的隱蔽字符將分類結果帶回服務端。Anthropic工程師隨後甚至確認，這是一次用於反賬戶濫用和反蒸餾的主動實驗。

按主觀故意程度，Claude Code是廠商自己承認的有意實驗，Grok Build至今沒有否認上傳機制的存在，ZCode的意圖尚無定論。

按數據採集範圍，Grok Build連用戶明確說「不要讀」的文件都傳走了，ZCode打包了86.6%的項目歷史。Claude Code傳的是行為元數據，量級不同但性質同樣涉及知情權。

三起事故值得警惕的是它們被發現都是源於偶然，一次靠配置失誤導致源碼洩露，一次靠安全研究者的主動抓包，一次靠博主對硬盤空間不對勁的警覺，沒有哪次來自廠商自發的debug或者行業審計、監管巡查。

ZCode今年7月上線時，智譜的宣傳直接對標Claude Code，正值Claude Code遙測爭議剛過數週，ZCode把自己定位成「可以擺脫被廠商遠程控制」的替代選項。而Grok Build的上傳事件也發生在7月，幾乎與ZCode上線同月。

三個月後，同樣性質的問題在ZCode自己身上被翻了出來，數據範圍還更大。打信任牌的人先翻了車，這大概是今年AI工具競爭中最具警示意味的一幕。

五. 安全規則只朝外

Agent過去一年拿到的權限，超過了此前任何一類裝在個人電腦上的軟件。

它能讀取當前項目目錄中的全部文件，能自主執行命令行操作，同時始終保持和廠商服務器的連接，還能在後台接收遠程配置更新。

在此之前，幾乎沒有哪種消費級軟件同時滿足這四個條件，圍繞這些新權限的安全規則確實在過去一年得到了迅速更新。

2025年底，國際應用安全組織OWASP發佈了首份面向自主AI Agent的十大風險清單；2026年1月，新加坡出台了首個針對自主AI Agent的治理框架，要求每個Agent攜帶可驗證的數字身份；2月，美國國家標準與技術研究院啟動了AI Agent標準倡議；8月2日，歐盟人工智能法案的高風險義務正式生效。行業層面也已出現專門面向編程Agent的認證標準。

規則數量在增長，但它們防的是工具被外部攻擊者利用，比如被惡意指令劫持，被誘導超越權限調用其他系統。

整套防線的設計假設是廠商站在用戶一邊，威脅從外面來。

ZCode和Grok Build的外傳通道恰好站在這個假設的盲區裡，它們不在AI工具的能力清單上，不受權限審批流程管轄，運行在整套工具循環之外，AI助手本身都感知不到它們的存在，只拿現有的任何一份安全框架來逐條審查，這些行為都不會觸發警報。

有觀點提出，應該像審計上市公司財報那樣審計Agent的數據行為。

這個類比部分成立，定期的、標準化的、由獨立第三方出具的、買方能讀懂的審查報告，這個形式是對的。

但財務審計審的是法律強制要求企業保留的賬本，「什麼數據離開了用戶的電腦」這種記錄沒有任何法規要求廠商保留，證據本身是不足的；

Agent客戶端可能每週更新，有的甚至每小時輪詢一次遠程配置來改變自身行為，年度審計報告在出具的那一刻就已經過期。

上市公司審計背後有證券法和審計機構的連帶賠償責任，Agent審計背後目前什麼都沒有。

開源是另一條被廣泛討論的路徑，智譜在這次事件後承諾開源ZCode代碼庫，OpenAI的Codex CLI和此前的Gemini CLI都採用了開源協議。

開源能讓社區檢查客戶端裡有沒有類似的外傳機制，這種透明度本身就構成約束力。但開源有幾條天然邊界。它只照得到客戶端，照不到服務端，數據送到廠商服務器之後發生了什麼沒人能看到。

如果只開源修復後的版本而不公佈事發時的代碼，它對過去的行為零證明力，而且用戶從應用商店或安裝器拿到的是編譯好的成品，與公開的源代碼是不是同一個東西，除非做了專門的可復現驗證，否則無從核實。

目前更務實的幾條路徑更具有可行性。

一是要求廠商公開聲明Agent會連接哪些服務器地址、傳輸哪些類別的數據，讓異常流量可以被獨立工具比對。cereblab對Grok Build的分析就是用標準的網絡抓包工具完成的，如果廠商主動提供了出口聲明，驗證成本會大幅降低。

二是在用戶自己的電腦上留一份可讀、可導出的外傳日誌，寫明每次發送的體積、目的地和數據類別，直接解掉「加密包在你機器上生成而你看不到裡面有什麼」這個最刺眼的設計。

三是責任保險機制，讓承保方而非認證機構來評估廠商的數據行為，前者需要為判斷失誤賠錢，是目前唯一能把「認真審查」變成經濟利益的機制。

這些方案在技術上都不難，難在動力。

目前推動它們落地的力量只有兩種，企業客戶的採購審查，以及偶發的社區曝光。前者只覆蓋企業版，後者全憑運氣。

所以最終這場事故的隱性矛盾，可能比安全技術方案都更難處理。

在ZCode和Grok Build的場景裡，點下「同意」按鈕的是開發者個人，承擔數據洩露後果的是他的僱主和客戶，後者從頭到尾沒有出現在任何一個同意流程裡，也沒有任何渠道知道自己的代碼曾經被打包上傳。

風險的承擔者和授權者不是同一個人，個人層面的知情同意在結構上就解不了這個問題，無論彈窗寫得多清楚、開關放得多顯眼。

現實的走向大概率是分層。

大型企業會在採購合同中加入數據行為條款和審計權，為此付出的成本最終會體現在價格裡；個人開發者使用的消費版則繼續處於一個沒人來審、也沒有人為之負責的狀態，但這恰好是絕大多數人在工作之餘繼續寫代碼的地方，也正是他們最容易用個人賬號打開公司項目的地方。

X平台或已與Midjourney達成合作，Grok可能會利用Midjourney進行影像生成

熱門文章