当代码有了“后门”:AI编程助手ZCode的数据边界危机

9月18日，技术博主ferstar在排查ZCode本地目录时，发现硬盘占用异常——在 ~/.zcode/v2/checkpoints/ 路径下，静静躺着一个313MB的加密压缩包（encryptedSizeBytes: 313,070,842），附带的状态文件显示：这是一个商业项目的完整快照，包含约4.2万个文件，客户端已连续重试上传564次，均失败。 

ZCode是智谱AI于今年7月推出的官方编程工具，基于GLM系列大模型，CLI版本号2.2.5，其技术架构被社区证实基于Claude Code二次开发。 

当开发者拆开ZCode的客户端代码，一条完整的上传链路浮出水面：用户登录后，ZCode会在每次发送提问前和任务结束后自动扫描整个工作区，将源码、完整的Git提交历史、LFS大文件缓存、reflog操作记录甚至本地分支变更记录打包，采用AES-256-CTR加密后直传阿里云OSS对象存储。 

更关键的是加密方案本身。ZCode采用信封加密：工作区内容先用临时对称密钥加密，对称密钥再用RSA-OAEP-SHA256封装，而RSA公钥由服务端动态下发，私钥从不下发到用户端。这意味着用户本地生成的几百MB密文，用户自己根本无法解密——能解开它的私钥，只保存在智谱的云端服务器上。 

更令人不安的是界面上的“关闭开关”形同虚设。 

ferstar逐一对照代码逻辑后确认：名为“优化体验”的开关实际只控制数据是否用于模型训练；名为“仓库快照索引”的开关实际只控制服务端是否建立检索目录。两个开关全部关闭时，本地的打包和上传行为照常运行——负责快照和上传的组件在软件启动时无条件加载，唯一前提是用户处于登录状态。

从技术角度看，这一行为直接违背了数据安全领域最基本的“最小必要原则”。 

一个AI编程助手的核心功能是为开发者提供代码补全和智能建议，但打包整个工作区——其中包含完整的版本控制历史、已删除的密钥文件、内网主机名配置以及未推送的本地分支——远远超出了实现该功能所需的数据范围。 

对快照清单的分析显示，.git目录合计占比高达86.6%，源码与文档仅约13.4%。更值得警惕的是，历史记录目录在打包流程中被豁免于所有安全过滤规则——针对.pem、.key等密码文件的过滤和1MB的体积上限，对.git目录下的任何内容都不生效。 

这意味着旧提交中已删除的密钥口令、.git/config里的内网主机名与仓库路径、被reset抹掉的操作记录，都可能已经在包内。 

事件曝光后，智谱AI CTO兼研究院院长张鹏在朋友圈致歉，称问题源于“代码库索引（Repo Wiki）”功能在上线初期默认开启，数据上传后会立即销毁，目前已修复，并承诺开源客户端代码、引入第三方安全审计，同时向全体用户补偿一次周额度重置。 

然而，社区很快发现ZCode v3.12.2版本（2026年9月16日，即ferstar发文前两天）的更新日志中，赫然写着“优化仓库快照上传的内存占用”——这条记录在事件发酵后被迅速删除。一个被内部持续迭代优化的功能，很难被简单解释为“设计疏忽”。 

另一名开发者冯若航独立复现了ferstar的取证流程，在4个工作区的快照记录中，确认至少有一份快照的状态文件已写入“服务端接受确认”的标记——这意味着至少有一台机器上的数据确实离开了本地。 

9月20日，太原承明科技有限公司发表公开函，指责ZCode擅自上传公司数据和商业秘密，要求智谱交代上传内容和处理方式，并提供删除凭证。事件远未结束。

ZCode事件并非孤例。将时间倒推两个月，2026年7月，独立安全研究者cereblab对xAI的Grok Build CLI（版本0.2.93）进行了完整的网络底层抓包分析，发现了几乎一模一样的行为。 

cereblab发现，Grok Build在默认配置下会绕开模型的正常对话通道，在后台将用户的整个代码仓库打包并静默上传至云端。即便用户在提示词中明确写着“回复OK，不要返回任何文件”，上传机制依然照常运行。 

更过分的是，用户在设置中关闭“Improve the model”选项后，上传行为并未停止——关闭的只是训练授权，不影响代码是否离开本地。 

xAI的上传管线甚至更为复杂：一条通道通过模型对话流将文件内容明文序列化传输，另一条独立通道将完整的Git仓库以Bundle格式写入xAI控制的Google Cloud Storage存储桶。 

在一个12GB的大型仓库测试中，仅被抓包期间捕获的传输量就超过了5.1GB，项目中的.env等敏感信息甚至未经过任何脱敏处理。 

事件曝光后，马斯克公开承认并承诺删除所有已上传的历史用户数据，xAI随后在服务器端关闭了上传功能并将Grok Build开源。 

但值得注意的是，xAI最初并未发布任何安全公告或主动通知用户，而是在研究者公开证据后才悄悄进行了服务器端修复。 

在这两起事件之间，还有一条值得玩味的时间线。2026年3月25日，GitHub宣布调整Copilot用户数据的使用规则：从4月24日起，Copilot Free、Pro和Pro+用户的交互数据（包括输入提示、输出建议和代码片段）将默认用于训练和改进AI模型，用户需要主动在设置中选择退出（opt-out）。

此前，个人用户需明确选择加入（opt-in）才会被用于模型训练。这一从“选择加入”到“默认参与”的转变，引发了开发者社区对AI厂商数据采集边界的广泛讨论。Copilot Business和Enterprise用户不受此变更影响。 

几乎与ZCode事件同期， 9月17日，网络安全初创企业Air Security（红杉资本投资）公开披露了一个名为“Plugin4Shell”的零点击远程代码执行漏洞。 

该漏洞影响Claude Code、OpenAI Codex、GitHub Copilot和Google Gemini CLI四款主流AI编程智能体——攻击者若拥有某个插件仓库的写入权限，即可将用户已安装的可信插件静默替换为恶意版本，即使客户端锁定了特定的Git SHA版本也无法防御。 

Anthropic在Claude Code 2.1.179版本中修复了该问题，OpenAI在Codex 0.146.0中完成修补，但GitHub Copilot至今未发布修复补丁，Google则以Gemini CLI已弃用为由不再修复。 

放眼整个行业，这种“先上线、后补救”的模式已经成为AI产品开发的潜规则。厂商们争先恐后地推出新功能，却将数据安全视为可以后续修补的“技术问题”，而非产品设计的“前提条件”。 

当多个头部产品在同一时间段内爆出类似问题时，说明这已经不是个别团队的疏忽，而是整个行业在安全治理上的系统性缺失——尤其是针对厂商自身数据行为的约束，目前几乎为零。

这些事件共同指向一个结构性问题：当AI编程工具从简单的代码补全，演变为具备读取本地文件、执行终端命令、联网能力的智能体时，它们对用户数据的访问权限已经远超传统软件的范畴。 

从技术层面看，这些AI编程助手存在多重安全隐患，且往往涉及厂商有意为之的隐蔽设计。 

7月1日，Reddit上一位开发者逆向分析Claude Code后发现，Anthropic从2.1.91版本起在客户端中嵌入了隐蔽的追踪逻辑——通过在系统提示词中插入不可见的Unicode字符，对用户所处时区、是否通过代理或中国AI实验室路由等环境信号进行分类，并将结果随对话请求回传服务器。 

Anthropic随后承认这是一项从2026年3月启动的实验，目的是检测未经授权的转售商滥用账号和模型蒸馏行为，并承诺在次日版本中回滚。 

7月8日，中国工业和信息化部网络安全威胁和漏洞信息共享平台（NVDB）就此发布高风险安全公告，指出Claude Code在2.1.91至2.1.196版本中存在未经用户同意向远程服务器传输用户环境信息的机制。这是国内监管机构首次对AI编程工具中的隐蔽遥测行为发出正式警告。

更严峻的是，AI辅助编程正在系统性放大密钥泄露风险。安全公司GitGuardian于3月发布的《State of Secrets Sprawl 2026》报告显示，2025年公开GitHub上检测到的硬编码密钥约为2876万个，同比增长34%，创历史最大年度增幅。其中AI服务相关密钥达到127.5万个，同比激增81%，增速远超其他类别。 

报告还发现，使用Claude Code辅助编程的提交中，密钥泄露率约为3.2%，而纯人工提交的基线泄露率约为1.5%——AI辅助开发者暴露敏感凭证的频率接近自主开发者的两倍。 

此外，提示注入攻击也成为新的威胁向量。攻击者可通过在README文档、Issue描述或对话历史中嵌入恶意指令，诱导AI编程助手窃取SSH密钥、外泄.env文件内容或执行未经授权的终端命令。 一旦AI智能体被劫持，攻击者即可获得对开发者本地环境的深层访问权限，将单一工具的安全漏洞演变为整个开发链路的安全危机。 

值得注意的是，ZCode和Grok Build的外传通道恰好位于现有安全框架的盲区：它们不在AI工具的能力清单上，不受权限审批流程管辖，运行在整套工具循环之外，AI助手本身都感知不到这些后台上传行为的存在。用现有的任何一份安全规范来逐条审查，这些行为都不会触发警报。

面对这些风险，开发者并非束手无策。对于企业用户，较为稳妥的做法是将此类工具纳入第三方安全评估与白名单管理，核心代码和涉密项目不建议直接在AI编程工具中打开。

个人用户则可以在系统层面对工具的数据目录进行访问控制，定期扫描仓库历史中是否泄露了敏感信息，并及时轮换可能暴露的密钥。

在企业侧引入第三方专业安全评估的实践中，已经有一些专注大模型安全的厂商开始提供体系化方案。

以上海首序智能科技有限公司为例，其推出的“大模型安全测评系统”与“大模型安全防御系统”构成了双引擎产品体系：

测评端覆盖内生、外生、衍生三大风险类型，支持500余款主流模型快速接入与定制化评测，能够在企业引入AI编程工具之前完成攻击面梳理、自动化红蓝对抗和风险归因，把“工具到底会读什么、传什么”从模糊的信任问题变成可量化的测评结论；

防御端则围绕输入、推理、输出与日志审计全链路，针对内容安全、算力攻击、隐私数据泄露和提示词注入四类核心威胁设置分级处置——高危请求直接阻断，中低风险数据脱敏后放行，所有操作留痕可追溯。

这种“测评—防御—治理”闭环，恰好补上了当前AI编程工具自身安全框架最薄弱的一环：由独立第三方而非厂商自己来验证数据边界是否被守住，使企业在选型和日常运维中有了不依赖厂商自我声明的外部参照。

在此基础上，首序智能进一步将安全管控下沉到“词元”（Token）粒度。随着2026年国家数据局正式将Token定名为“词元”并将其确立为AI时代的结算单位，词元本身的安全——包括API凭证泄露、会话令牌滥用、模型交互中敏感词元被静默外传——正在成为继代码数据之后的下一个攻防焦点。

首序智能的安全词元平台，正是面向这一层面提供词元级别的身份鉴权、使用审计与异常行为检测：对AI编程工具在调用模型过程中产生的每一次词元请求进行身份校验和行为基线比对，一旦发现异常外传（如将包含密钥、内网地址的词元批量发往非预期端点）即触发告警或阻断，并将词元调用记录纳入统一审计日志。

这与前文提到的ZCode加密包、Grok Build静默上传等场景形成直接对应：当厂商自身的开关不可信时，词元层面的独立观测和拦截，是企业在数据离开本地之前最后一道可控的防线。

智谱在ZCode事件发生后数小时内即发布了致歉声明，反应速度不可谓不快。但承诺的实质价值，取决于后续的执行力度——开源范围是否包含上传与加密组件、第三方审计结论能否公开、此前已上传的数据如何处置（是否真的如声明所言“立即销毁”），都需要可验证的答案。

更关键的是，那份已被删除的“优化仓库快照上传的内存占用”更新日志，以及界面上两个形同虚设的开关，暴露的是产品设计层面的信任赤字——用户看到的控制项控制不了真正在发生的事。

从行业角度看，信任的重建不能仅靠一纸声明和额度补偿。有安全研究者提出了三条可行路径：

一是要求厂商公开声明Agent会连接哪些外部服务、每次外传的数据类别和大小；

二是在用户本地保留一份可读、可导出的外传日志，直接解掉“加密包在你机器上生成而你看不到里面有什么”这个最刺眼的设计；

三是引入责任保险机制，让承保方而非认证机构来评估厂商的数据行为，因为前者需要为判断失误承担经济赔偿，这是目前唯一能把“认真审查”变成经济利益的机制。

一个开发者工具最核心的资产不是模型能力，而是用户愿意把代码交给它的那份信任。这份信任一旦被撕开一道口子，靠一次额度重置和一纸声明是补不回来的。

AI编程助手的出现，正在重新定义人与代码的关系。但一个工具的价值，不应以牺牲用户的数据主权为代价。 

从ZCode到Grok Build，从Claude Code的隐蔽追踪到Plugin4Shell的供应链攻击，过去半年间密集爆发的一系列事件提醒我们：当AI工具从“助手”变成“智能体”，当它能读你的文件、执行你的命令、联网上传你的数据时，数据边界的定义权不能只掌握在厂商手中。 

当我们在享受AI带来的效率红利时，也需要清醒地认识到：代码是开发者的核心知识产权，而保护这份知识产权的第一责任，始终在于工具的设计者。 

在一个“先上线、后补救”成为潜规则的行业里，开发者需要的不只是道歉和补偿，而是可验证的承诺、可审计的代码、以及真正可控的开关。

天下没有免费的午餐，但数据安全绝不应该是付费午餐。

上海首序智能科技有限公司是一家专注于人工智能安全与可信智能体技术的创新型科技企业，依托国际领先科研成果与资深网络安全团队，成立即获上市公司数千万天使投资。公司围绕大模型安全、Agent 安全、AI 内容治理与企业级智能化应用，构建覆盖“评测、防护、审计、治理”的全链路 AI 安全产品体系。公司致力于以先进的大模型技术和安全工程能力，帮助金融、政务、教育、内容平台等行业客户构建安全、可信、可控的 AI 应用基础设施，能有效解决人工智能安全合规、有效使用、算力浪费等痛点，推动人工智能从能力探索走向规模化、合规化和产业化落地，让AI系统能为企业，为国家，为人类提供更好的服务。