智谱ZCode因静默上传数据引争议并宣布开源整改

智谱ZCode因静默上传数据引争议并宣布开源整改

财π新闻 据中华网2026年9月21日报道,智谱旗下AI编程工具ZCode因未经用户许可静默上传代码数据引发严重信任危机,相关事件在开发者社区快速发酵,对智谱AI的业务推进与市场口碑造成直接冲击。9月18日,开发者曝光该工具在后台将用户工作区连同Git文件夹、密钥等核心资产打包加密上传至云端,且手动关闭开关无效,这一发现迅速引发公众对信息泄露的强烈担忧,更导致部分企业直接封禁该工具,给智谱AI收入带来潜在冲击。

事件曝光的完整技术细节与社区传播脉络

此次风波最早由开发者社区的逆向工程分析引发,9月18日,开发者ferstar通过逆向智谱的编码工具ZCode后公开相关发现,在用户登录状态下,该工具会在后台静默打包整个工作区,包含完整的Git历史、LFS大文件缓存及本地分支操作记录,加密后上传至阿里云OSS,客户端UI无任何能够真正切断上传链路的关闭入口,加密私钥仅存于服务端,用户与本地客户端均无法解密生成的加密数据包。这名开发者在本地磁盘中发现一份313MB的密文,对应原本345MB的工作区,其中包含42411个文件,.git目录相关内容占总数据量的86.6%,后台上传失败计数已经累计达到564次,意味着工具在网络不畅的情况下仍在反复重试上传操作。

多名开发者随后按照公开的方法完成独立复现,确认相关机制真实存在,界面中设置的“优化体验”和“仓库快照索引”两个开关,均无法控制静默上传行为,前者仅控制数据是否可被授权用于模型训练,后者仅控制服务端是否为已经上传的快照建立索引,没有任何开关直接对应“是否执行上传操作”这一核心逻辑。有用户实测即便手动删除本地已经生成的待上传加密包,半小时内工具仍会自动重新抓取生成新的加密包,上传重试计数持续上涨,最终只有通过操作系统层面的命令将检查点目录设置为不可写,在内核层面拦截写入操作,才能彻底阻止本地加密包的生成,进而切断上传链路,但这一操作的代价是ZCode的检查点回滚和时间线界面功能完全失效。

随着事件在开发者社群快速扩散,更多细节被逐步披露,有用户实测自己本地生成的缓存快照体积达到约699MB,大量开发者反馈自己的项目核心资产被无差别扫描打包,不少企业开发者担忧自己负责的商业项目源代码、系统架构文档、内部服务器地址、API密钥等敏感信息被上传至云端,甚至有开发者表示自己数G的项目代码被完整采集,相关争议快速从技术讨论升级为对数据安全底线的集体质疑,整个开发者社区的信任基础出现明显松动。

涉事企业的多轮处置措施与公开承诺内容

面对快速发酵的信任危机,智谱在三天内采取多轮补救措施,9月18日事件曝光当晚,智谱就通过官方社群发布首次致歉,称相关上传行为源于“代码库索引”功能,该功能上线初期默认开启,上传数据用于云端生成Repo Wiki页面后即销毁,相关问题已经完成修复,同时承诺近期开源ZCode代码库,邀请第三方评估人员对系统运行情况进行审查,持续公开审查进展,并为全体ZCode用户额外提供一次周额度重置,相关额度已于9月18日当日发放到所有用户账户中。但这一首次回应并未完全平息公众质疑,大量开发者和企业用户对数据用途的说明、“用后即焚”承诺的真实性提出强烈疑问,认为单方面的口头承诺缺乏可验证的技术依据,无法打消数据安全层面的顾虑。

针对公众的进一步质疑,智谱于9月21日发布第二次致歉声明,明确承诺所有被上传的代码数据从未被用于模型训练,同时正式宣布将ZCode开源至GitHub平台,交由全网开发者共同监督,所有底层代码逻辑完全公开,让社区可以直接审查客户端是否存在后台静默打包、数据外发的相关逻辑,彻底打破此前闭源软件的黑盒运行状态。智谱同时宣布邀请中国信息通信研究院和绿盟科技共同开展独立安全审计,其中中国信息通信研究院通过技术评测确认,对应zcode-prod的阿里云OSS存储桶状态为云端零数据,绿盟科技的审查结果也确认相关存储桶及全部数据对象均已完成删除,ZCode v3.14.0版本客户端已经完全移除Repo Wiki功能,切断本地仓库快照生成与上传的全部链路,不存在可触发本地全量打包上传的隐藏逻辑。

除了针对ZCode产品的专项整改之外,智谱还同步宣布旗下MaaS平台上线“数据内容不留存”功能,企业和开发者开通该功能后,可在模型调用完成后减少平台侧数据持久化保存,进一步降低用户数据在云端留存的风险,配合此前为全体用户重置使用额度的补偿措施,形成覆盖产品功能、安全审计、用户补偿的完整处置链条。这一系列处置动作的核心逻辑分为两层,第一层是完成云端历史数据的彻底切割,通过第三方权威机构的技术审计为“数据已全部删除、未用于模型训练”的承诺提供可验证的技术证明,第二层是实现本地执行逻辑的完全透明,通过开源代码的方式让所有底层运行逻辑暴露在全网开发者的监督之下,从机制上消除软件隐蔽执行未声明功能的可能性。

行业层面的争议延伸与企业用户的后续诉求

在智谱发布首次致歉声明之后,事件的争议范围进一步扩大,承明科技在独立完成技术取证后,对智谱此前发布的“已修复”声明提出公开质疑,其发布的函件指出,相关上传行为系自动触发、批量发生,所涉数据包括项目完整源代码、系统架构文档、Git版本控制历史、数据库管理员口令、云平台访问密钥及员工个人信息等结构化归档文件,远超ZCode《隐私政策》中明确载明的收集范围,尽管客户端已于9月16日更新至3.12.3版本,但在智谱公开致歉当日凌晨,承明科技的监测系统仍捕捉到了新的上传行为。承明科技同时披露,ZCode客户端的网络请求实际指向注册于新加坡的关联实体,而用户服务协议的签约主体为境内公司北京智谱华章,因此要求智谱明确本次数据上传行为的法律责任归属,说明是否存在数据出境传输或境外服务器存储的情形。

承明科技在公开函件中明确提出多项具体诉求,要求智谱于2026年10月10日前以书面形式完成相关事项,包括彻底删除已上传的全部数据及相关衍生数据与备份、提供完整数据处理清单、说明数据是否共享给第三方或用于模型训练、披露加密私钥保管机制及全部数据访问审计日志、出具删除完成证明并书面承诺不再发生类似行为。截至相关报道发布时,智谱方面尚未就该函件的相关内容作出公开回应。此次事件发生在智谱密集融资与业务扩张的关键节点,智谱于2026年1月在港交所上市,成为全球首家以AGI基座模型为核心业务的上市公司,上市前累计完成8轮融资,规模超83亿元,9月13日智谱刚刚公告完成约50亿美元融资,资金将用于下一代GLM模型及算力基础设施建设,此次数据上传争议直接对其面向B端市场的信任基础构成考验。

法律相关专业人士指出,AI编程工具为了完成代码解释、补全、调试和重构,读取一定范围代码本身并不当然违法,争议的核心在于平台实际读取和上传的数据范围,是否超出了用户的明确授权和合理预期。用户要求工具分析某个文件,并不意味着同意客户端扫描、打包并上传整个代码仓库,更不等于授权处理完整Git历史,如果用户仅针对单个文件提问,客户端却在后台打包整个工作区,则可能涉及超出最小必要范围的问题。代码库并不是单一性质的数据,源代码本身未必属于个人信息,但完整Git仓库中可能包含开发人员姓名、邮箱、账号信息、客户测试数据、内部服务器地址、API密钥、访问令牌以及已被删除但仍留存在历史版本中的文件,还可能涉及企业未公开的源代码、算法、系统架构等商业秘密,对代码库的法律判断需要根据具体数据内容,分别适用个人信息保护、数据安全、网络安全、商业秘密及合同相关规则。

事件带来的AI编程工具安全警示与行业共识

此次事件为AI安全敲响警钟,AI编程工具静默上传数据的风险极其隐蔽,传统管理手段难以防范,这类工具的静默上传行为完全在后台运行,普通开发者很难通过常规的界面操作感知到数据采集的发生,即便用户主动关闭界面上标注的相关开关,也无法真正终止上传进程,常规的企业终端管理规则很难覆盖这类隐蔽的后台行为,很容易在用户完全不知情的情况下造成核心数据资产的外泄。随着AI编程工具从简单的代码补全功能升级为可以读取项目、调用终端、修改文件和操作数据库的智能代理,相关工具的运行权限已经和操作系统、本地文件系统、终端命令行实现深度挂钩,一旦出现未被明确告知的隐蔽数据采集行为,带来的安全风险将远高于传统的网页端大语言模型交互场景。

针对这类隐蔽风险,行业内逐步形成明确的防护共识,企业必须建立内部开发管理规范,要求员工开启隐私模式,限制模型读取权限,绝不将包含敏感信息的整个工程项目或Git目录暴露给AI编程工具,不能将核心代码资产的安全完全寄托于第三方工具的自律行为,企业需要建立属于自己的数据防护体系,从操作系统权限管控、终端行为审计、数据外发拦截等多个层面搭建多层防护屏障,在工具和核心代码资产之间建立明确的安全边界。不少开发者也提出,所有涉及本地文件读取上传的AI编程工具功能,都不应当默认开启,必须由用户主动完成二次确认授权之后才能启用,任何标注为“可关闭”的功能,都必须能够明确说明其直接掐断的执行路径,确保用户的选择能够真正落地到系统执行层面,而不是仅仅关闭界面上的相关提示。

开源透明化被普遍认为是重建AI编程工具用户信任的核心路径,传统的闭源桌面应用即便经过逆向分析,也需要耗费开发者极高的时间成本,普通用户很难自行验证软件的实际运行逻辑,而将客户端及Agent运行时代码完全公开,意味着客户端是否存在后台静默打包行为、数据外发的触发条件是什么、本地检查点的回滚逻辑如何实现,所有原本被打包在二进制文件里的底层调用,全部暴露在全网开发者的监督之下,相当于用公开透明的机制让渡了软件隐蔽执行任何未声明功能的可能性。当然开源代码只是提供了一份免于暗箱操作的基础保障,后续的代码审计能否常态化运行、社区提报的漏洞能否得到及时修正、云端模型服务与本地执行端之间是否能始终恪守清晰的数据边界,依然需要长期的实践检验。

(编辑:吕文)