一个313MB加密包，撕开智谱等AI编程工具安全暗门

9月21日，智谱（2513.HK）就旗下桌面AI编程工具ZCode的数据安全争议完成整改并向用户致歉，同时正式将ZCode开源至GitHub，接受社区监督，并邀请中国信息通信研究院和绿盟科技开展安全审计。

智谱称，ZCode 3.14.0已经移除Repo Wiki功能（ZCode代码库索引功能的一部分），切断本地仓库快照生成与上传链路。并称中国信通院技术评测显示，相关阿里云OSS（对象存储服务）存储桶（独立分区）目前处于“云端零数据”状态；绿盟科技则确认相关数据对象及存储桶已经删除。

智谱强调，此前相关代码数据未用于模型训练，并将建立常态化产品安全漏洞报告机制。

智谱的解决方案并未得到所有人的满意，作为ZCode用户，太原承明科技有限公司近日发函，称ZCode上传公司数据，要求智谱提供上传内容、处理方案、信息删除凭证，并说明数据是否发生跨境传输。

承明科技相关负责人对第一财经记者表示，公司正与第三方机构进行二次信息验证，但由于正在与智谱方面沟通相关处理方案，具体细节不便透露。公司对智谱的产品与技术抱有尊重，一如既往地支持中国本土AI生态发展。智谱方面也暂未披露具体处理情况。

对于更广泛的开发者群体而言，此次事件暴露的问题并不只是“信息还传不传”，而是此前的数据究竟去了哪里、谁能够访问、保存了多久，以及用户能否真正控制AI工具访问自己的代码。

一次内存清理暴露的数据泄露

事件始于9月18日。

ZCode付费订阅用户ferstar在清理一台256GB MacBook Air内存空间时，发现ZCode目录占用超过700MB。其中一个约313MB的加密文件引起了他的注意。

他对ZCode客户端进行逆向分析，发现客户端存在一套工作区快照机制：在登录状态下，ZCode会对工作区进行打包、加密，并通过阿里云OSS进行上传。

测试中的一次快照涉及4.2万余个文件，.git目录占据主要部分，意味着上传对象并不只是当前正在编辑的代码，还可能包含Git历史、LFS缓存等内容。.git是总数据库，Git历史是每次修改的记录链，LFS缓存是大文件专属存储区，三者组成一个项目的完整“底裤”。

不过，ferstar发现的那份313MB商业项目快照实际上没有成功上传。由于文件过大，该文件连续失败564次，一直停留在本地重试队列。与此同时，他又用一个规模较小的公开仓库进行测试，证实确认存在被服务器接受的快照上传。

ferstar随后公布完整逆向报告，称ZCode此前的相关机制与用户界面中的数据设置并不完全对应。他认为，即便关闭部分与体验优化或仓库索引相关的选项，快照捕获和上传机制仍可能运行。

这也是事件最核心的争议：用户认为自己是在授权AI读取完成任务所需的代码，但客户端实际处理的数据范围可能远远超过一次具体AI请求所需要的内容。

智谱9月18日回应称，争议源于代码库索引功能。该功能用于本地索引、会话检查点恢复以及Repo Wiki，在早期版本中默认开启；生成Repo Wiki页面时，可能触发仓库数据上传，生成完成后数据即被销毁。

目前，争议的焦点已经从“是否存在上传”转向了另一个问题：用户如何验证所谓“立即销毁”？

从外部观察者角度看，第三方机构确认当前OSS存储桶为空，可以证明整改后的存储状态，但并不能单独回答此前数据的完整生命周期，包括历史传输记录、访问权限以及加密数据是否曾被解密等问题。

ferstar也提出了类似追问。他希望智谱能够回答现有的云端存储加密快照已被物理清除，开源版本是否包含之前发现的历史上传文件。截至发稿，智谱暂未对上述问题进行回应。

ZCode开源是一个重要动作，但开源本身并不等于完成了数据安全证明，行业真正需要建立的是一套能够让用户验证的信息安全机制。

ZCode并非孤立事件

ZCode暴露的问题，放到全球AI编程工具市场看，并非单一厂商的偶发失误。

今年7月，安全研究者cereblab对xAI的Grok Build CLI进行网络流量分析，发现测试版本存在独立于模型推理通道的代码库上传机制。

一次12GB测试仓库中，模型请求通道传输约192KB数据，而存储通道实际上传约5.10GiB，约为前者的2.78万倍。研究者还通过抓包恢复了完整Git仓库，并发现其中包含模型没有实际读取的文件。

CEO马斯克承认上述用户代码库情况属实，并承诺所有此前上传到SpaceXAI的用户数据都将被彻底删除，一个字节不留。xAI随后通过服务端配置关闭代码库上传，并将Grok Build开源，将代码上传至GitHub。

今年以来，Agent赛道大爆发，自“龙虾”项目热度爆火，字节跳动的飞书、腾讯的Workbuddy、阿里的千问办公等产品接连强调自身的自主执行能力，行业意识到AI编程工具正在从“回答代码问题”转向“进入整个代码库并代替用户执行任务”。

然而，上述这两个独立事件暴露了一个正在形成的风险：技术提升了，产品迭代了，但数据访问边界并没有同步成为用户能够清晰理解和控制的产品能力。

这种风险也出现在更加成熟的AI编程产品中。

GitHub宣布从4月24日起，Copilot Free、Pro和Pro+用户的输入、输出、代码片段及相关上下文，默认可以用于模型训练和改进，用户可以在设置中选择退出。Cursor披露其代码库索引功能默认开启，会扫描用户打开的代码目录，并将代码库的索引信息同步到服务器。另外，Cursor此前还修复过一起高危逻辑漏洞，恶意Agent可以通过修改文本文件绕过原有保护规则，读取本应被排除的敏感文件。

这些案例并不相同，但指向同一个变化：AI编程工具获得的权限正在快速扩大，而传统软件时代的隐私设置已经很难覆盖Agent的实际行为。

“用户授权”正在被重新定义

过去，开发者使用IDE（集成开发环境），软件主要在本地读取代码；使用云端API，则通常明确把某段代码发送给服务器。

Agent出现以后，两者之间的界限开始模糊。

一个Agent可能需要扫描整个仓库理解项目结构，读取Git历史寻找上下文，调用Shell执行命令，再把部分结果发送给模型。如果所有动作都被归入一个笼统的“允许AI访问代码”，用户实际上很难知道，究竟哪些数据被读取了、哪些数据离开了本机、去了哪里、保存多久、谁可以访问。

这也是AI编程工具区别于传统SaaS最大的安全挑战之一。

且代码库并不是普通数据。企业Git仓库中往往同时存在源代码、未发布功能、客户信息、内部架构、部署配置以及历史提交中已经删除的密钥。一旦完整Git历史离开本地，其信息价值远高于当前工作目录。

因此，行业需要解决的已经不是简单的“关闭上传按钮”，而是建立一套新的Agent数据治理体系，包括最小权限应成为默认原则，数据出站必须可见、可控、可审计，敏感信息应默认隔离，厂商需要提供可验证的数据删除机制、Agent本身需要建立行为审计等。

ZCode与xAI选择的开源方式，实际是提供了一个值得参考的方向：把过去隐藏在客户端中的数据处理逻辑交给社区检查。

但开源只是起点，检查也有门槛。AI编程工具正在从软件助手变成可以读取代码、执行命令、修改文件乃至部署系统的数字员工。它获得的权限越接近开发者本人，用户就越不能只依赖一纸隐私政策或者一个模糊的“优化体验”开关。

也正因此，ZCode事件真正暴露的问题不是一次上传机制设计失误，而是一个正在整个AI Agent行业出现的新问题：当AI开始替用户做事，用户授权的边界，也必须从“我同意使用AI”，升级为“我清楚AI正在替我做什么”。