过去两年，围绕 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 又自动重新生成了一份新的打包文件，上传失败后会继续重试。
智谱回应与社区追问并未对齐
ferstar 文章发布当晚，社区迅速发酵，智谱很快作出回应并致歉。
智谱表示，此次问题源于 ZCode 的「代码库索引」功能。该功能旨在帮助用户在本地生成仓库索引，以支持包括历史版本在内的会话检查点恢复、历史版本回退及 Repo Wiki 等功能。智谱称，Repo Wiki 功能在生成 Wiki 页面时可能触发仓库数据上传，Wiki 页面在云端生成后，相关上传数据会立即销毁，不会保存。由于该功能在上线初期默认开启，部分用户因此受到影响，目前相关问题已经修复。
智谱还承诺，近期开源 ZCode 代码库，邀请第三方评估人员审查系统运行情况，并为全体用户额外补偿一次周额度重置，当天发放。
从功能定义看，「代码库索引」用于为项目文件建立目录和检索系统；「Repo Wiki」用于自动生成项目说明文档；「会话检查点恢复」和「历史版本回退」则允许用户在与 AI 交互过程中回到此前某一步。这些功能本身并不罕见，回应速度也很快，但社区质疑的重点并不在这里。
争议首先集中在「本地生成」与「上传云端」之间的关系。智谱称这套索引旨在帮助用户在本地生成，社区随即追问：如果是本地生成，为何需要把整个项目送到云端？本地做索引、本地做快照、本地做回退，在技术上并非不可行，市场上也已有工具采用类似方式。
另一处争议在于触发时机。智谱将问题归因于 Repo Wiki 在生成 Wiki 页面时可能触发仓库数据上传，但 ferstar 的逆向记录显示，上传触发点之一出现在用户每次发送提问之前，与生成说明文档并不一致。
ZCode 当前官方文档还写明，生成说明文档时不会读取项目历史修改记录，而是按需读取经过筛选的代码上下文。这意味着，从技术描述上看，这项功能并不需要历史记录。可 ferstar 发现的上传包中，86.6% 都是历史记录。社区因此追问，上传范围为何如此之大，是设计如此还是程序错误，以及从哪个版本开始修正，回应中都没有明确交代。
智谱在说明中使用了「该功能在上线初期默认开启」的表述。社区认为，这种说法更像把一次机制层面的数据外传，描述成某个功能开关的默认设置问题。因为按 ferstar 的代码分析，界面上的两个相关选项，一个控制训练授权，一个控制索引建立，都无法阻止打包和上传本身。
很快，社区又翻出另一份更敏感的证据：ZCode v3.12.2 版本更新日志，日期为 2026 年 9 月 16 日，也就是 ferstar 发文前两天。其中一条记录写着「优化仓库快照上传的内存占用」。在社区看来，工程团队很难为一个意外行为专门优化内存，这意味着「仓库快照上传」在内部更像是一项持续迭代的正常功能。该更新日志在事件发酵后已被删除，而删除公开记录本身，又成为新的争议点。
智谱还表示，「相关上传数据会立即销毁，不会保存」。这句话回答的是数据保留时长，但用户关心的问题并不止于此：数据是否已经离开电脑，服务器处理过程中谁有权限访问，加密包的解密能力掌握在谁手里，此前已上传的数据采用了什么删除策略，这些都没有在回应中展开。
从加密方式看，私钥保存在服务器一侧，因此「加密上传」只能说明传输过程中不易被第三方截获，不能据此推出智谱自身无法读取内容。
ZCode 英文版隐私政策对收集范围的表述是，用户「through conversation」提交的文本、文件和代码。但后台快照并不是用户通过对话主动提交的内容。换句话说，「在对话中向我们提交」与「后台自动打包整个项目」并不是同一类行为。
这份隐私政策还写明，当新功能涉及与原始目的没有直接或合理关联的信息收集时，应通过页面提示、交互流程等方式另行告知并取得用户同意。
另一名开发者冯若航的代码分析显示，客户端每次发送提问时都会无条件向服务端申请上传凭证，服务端发放凭证就会采集，不发放就不会采集。ferstar 发现的 313MB 文件当时处于待发送状态，已失败 564 次。冯若航在自己的 Mac 上独立复现了 ferstar 的取证流程，在 4 个工作区的快照记录中，确认至少有一份快照的状态文件已写入服务端接受确认标记。
按代码逻辑，这个标记只有在上传被服务端确认接收后才会生成。这意味着，至少有一台机器上的数据确实已经离开本地。智谱的致歉、承诺和补偿都在争议发酵数小时内给出，反应速度并不像准备长期隐瞒。但无论是「立即销毁」还是「不会保存」，外部都无法直接验证，也无法证伪。用户能确认的只有数据离开了自己的电脑，之后发生了什么，仍取决于厂商自身约束。
智谱承诺的开源和第三方审查能否改变这一点，还取决于开源的是哪个版本、审查覆盖客户端还是服务端，这些问题目前都没有答案。
社区为何盯住历史记录和使用轨迹
报道指出，如果厂商真的有意收集用户数据，目标未必只是代码文本本身。公开代码托管平台已经为模型训练提供了大量语料，私有代码固然包含商业秘密，但从模型改进角度看，单纯多拿到一批代码文本，边际价值未必最高。
更稀缺的，可能是三类数据。
- 第一类是改动的因果链。项目历史修改记录保存的不是单纯快照，而是「改之前是什么样、因为什么修改、最后改成什么样」的完整过程。对编程模型来说，这类带前因后果的序列是理想训练材料。
- 第二类是带结果标注的使用轨迹。ZCode 在每次用户发送提问前拍一次快照，同时又具备回退功能，天然会形成「提问 + 操作前状态 + 操作后状态 + 用户是否撤销」的完整循环。这类数据在 AI 训练中通常需要专门标注，成本很高。
- 第三类是未进入训练集的真实项目。公开编程评测题目大多已被模型在训练中见过，真实私有项目对内部能力评估更有价值。
报道认为，这三类数据与 ZCode 上传包的构成高度吻合，这也是社区对「只是为了生成说明文档」这一解释始终不完全接受的原因。
不过，报道也指出，如果目标真是系统性采集训练数据，更精确的做法可能是只抽取提问内容和代码改动，而不是连几百兆的大文件缓存和完整操作日志一起打包。就上传包的粗放程度看，与其直接下结论认定智谱有明确主观故意，现有证据更接近一种激进产品决策叠加工程实现上的简化处理。
即便如此，这并不减轻问题本身的严重性。无论动机如何，用户面临的安全隐患都是真实存在的。
Grok Build 与 Claude Code 也曾卷入类似争议
与 ZCode 相似的风波，今年已经不止一次出现。
今年 7 月，独立安全研究者 cereblab 对 xAI 的 Grok Build 做了完整网络抓包分析，并公开了全部证据和复现步骤。他发现，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 传回的是行为元数据，量级不同，但都涉及用户知情权。
三起事件还有一个共同点：它们都不是靠厂商主动排查、行业审计或监管巡查发现的。一次是配置失误导致源码泄露，一次来自安全研究者主动抓包，一次来自博主对硬盘空间异常的警觉。
ZCode 于今年 7 月上线时，智谱的宣传直接对标 Claude Code。当时 Claude Code 的遥测争议刚过去数周，ZCode 将自己定位为「可以摆脱被厂商远程控制」的替代选项。Grok Build 的上传事件也发生在 7 月，几乎与 ZCode 上线同月。三个月后，类似性质的问题又在 ZCode 身上出现，而且数据范围更大，这一反差成为今年 AI 工具竞争中颇具警示意味的一幕。
现有 Agent 安全规则主要防外部攻击
报道指出，过去一年，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 的场景里，点击「同意」按钮的是开发者个人，但数据泄露后果往往由其雇主和客户承担。后者从头到尾没有出现在任何同意流程里，也没有渠道知道自己的代码曾被打包上传。
风险承担者与授权者并不是同一批人，个人层面的知情同意因此很难真正解决问题。无论弹窗写得多清楚，开关放得多显眼，这个结构性问题都不会自动消失。
报道判断，现实中的走向很可能是分层：大型企业会在采购合同中加入数据行为条款和审计权，相关成本最终体现在价格里；个人开发者使用的消费版，则可能继续处于缺少审计、也缺少责任承担机制的状态。而这恰恰是多数人下班后继续写代码、也最容易用个人账号打开公司项目的场景。