文章总结： 本文分析zcode事件暴露的AI编程agent安全边界问题。核心风险在于agent可读取源码、.git历史并上传云端，默认开启的代码库索引功能导致数据外传。建议企业将agent视为数据出口，实施分级治理、隔离环境、审计网络流量，并保护githistory。加密不能替代授权，需opt-in机制与透明数据策略。
综合评分： 88
文章分类： 数据安全,安全建设,安全意识,安全运营,解决方案
ZCode 静默打包代码库之后： AI 编程 Agent 的安全边界该重画了
原创
JacobWang
JacobWang
NowSec
2026年9月23日 16:56
陕西
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
AI 编程工具正在越来越像一个真正的开发者。
它能读取整个项目、理解代码结构、修改文件、执行 Shell 命令、运行测试、调用浏览器、连接 MCP，甚至拆分多个子 Agent 并行完成任务。
过去我们担心的是：AI 会不会写错代码？
现在，一个更现实的问题开始浮上来。
为了让 Agent 更懂你的项目，我们到底允许它读走多少东西？
近期 ZCode 引发的代码库上传争议，就把这个问题直接摆到了开发者和企业安全团队面前。
一、从一次磁盘清理开始的异常发现
9 月 18 日，开发者 ferstar 在清理本地磁盘时发现，~/.zcode 目录占用了数百 MB 空间。
继续排查后，他在 ZCode 的 checkpoints 目录中发现了一份约 313MB 的加密工作区快照。根据其公开分析，这份快照来自一个约 345MB 的项目工作区，其中不仅包含源码，还包含完整的 .git 历史、Git LFS 缓存以及 reflog 等内容。
本地日志还记录了数百次上传失败，并将任务持续保留在 pending 队列中等待重试。
需要特别区分：研究者表示，这个 313MB 的商业项目快照最终没有成功上传；但在后续验证中，一个约 15KB 的公开测试仓库快照曾被服务器正常接受。
事情随后迅速发酵。
Z.ai，也就是智谱，对此公开致歉，并将问题归因于 ZCode 默认开启的 Codebase Indexing（代码库索引）能力。按照官方说明，这套能力原本服务于会话检查点恢复、历史版本回退和 Repo Wiki 等功能，其中 Repo Wiki 在生成页面时可能触发仓库数据上传。
随后 Z.ai 表示已经停用部分相关能力、修复异常上传问题、开源 ZCode，并引入独立安全评估和 Zero Data Retention 等措施。
如果只看到这里，这件事似乎可以归结为：
发现问题 → 修复 → 开源 → 审计
但如果只把它当成一次产品 Bug，可能会错过真正值得安全行业讨论的问题。
ZCode 事件暴露的，其实是 AI 编程 Agent 正在重新定义企业源码的数据边界。
二、以前 IDE 只是“看代码”，现在 Agent 可以接管整个工作区
传统 IDE 当然也能读取项目。VS Code、IntelliJ IDEA 打开一个目录以后，同样能够看到大量源码。
但传统 IDE 和今天 AI Coding Agent 之间，有一个非常重要的区别：Agent 需要持续构造上下文。
为了理解一个问题，它可能要读取当前文件、引用关系、目录结构、配置文件、历史 Commit，甚至运行命令获取更多信息。
如果模型部署在云端，那么部分上下文自然需要跨越本机边界。这件事本身并不等于不安全。
真正的问题是：
发送什么？什么时候发送？发送多少？发送到哪里？保存多久？用户知不知道？
例如，让模型修改一个 Controller，可能只需要几个相关文件；让 Agent 理解整个项目架构，就可能需要扫描几十个目录；如果进一步生成 Repo Wiki、保存会话状态或者支持工作区恢复，数据范围还可能继续扩大。
于是，一个最初只是“帮你补全代码”的工具，逐渐拥有了本地文件读取、Shell 命令执行、Git 操作、网络访问、浏览器和 MCP 工具调用等能力。
这已经不是传统 IDE 的安全模型了。
从企业安全角度看，它更接近一个运行在开发者电脑上的高权限自动化主体。
三、真正敏感的可能不是源码，而是 .git
ZCode 事件里，我认为最值得安全人员关注的一个细节，并不是“上传代码”，而是：
工作区快照可能包含完整的 .git。
很多开发者对 .git 的敏感程度其实不够高。
大家通常认为源代码本身才是核心资产，于是会通过 .gitignore 排除 .env、密钥文件、配置文件和临时文件。
但 .git 保存的是整个仓库的历史。
今天已经删除的密码，可能还在历史 Commit 里；去年替换掉的 AK/SK，可能还留在 Git Object 中；曾经误提交过的生产配置，即使后来删除，也可能继续存在于历史版本。
Git LFS 还可能保存模型、大型二进制文件和历史资源，reflog 则可能记录已经重写或者删除的引用。
当前工作目录保存的是代码的“现在”，而 .git 保存的可能是这个项目的“过去”。
这也是为什么 Secret Scanning 通常不会只扫描当前版本，而是要扫描完整 Git History。
因此，如果一个 AI Coding 工具确实需要上传项目上下文，那么 .git 理应被视为高风险区域，而不是一个普通目录。
四、“加密上传”不能解决数据边界问题
类似事件出现以后，经常会出现一个观点：数据不是已经加密了吗？
传输加密、存储加密当然重要。但加密解决的是“别人能不能看到这份数据”，它解决不了另一个问题：
这份数据本来该不该出去？
即使一份源码使用 HTTPS 传输，再使用 AES 加密存储，如果它原本就不应该离开企业内网，那么它仍然发生了数据边界变化。
因此，企业做 AI 数据治理时，不能因为看到“HTTPS”“AES”“对象存储加密”就认为风险已经关闭。
真正需要回答的是：用户是否明确知道发生上传？为什么需要上传整个仓库？.git 为什么需要进入处理范围？数据保存多久？谁能够解密？是否用于模型训练？用户能不能关闭？删除以后是否能够验证？
加密不能替代授权，授权也不能替代数据最小化。
五、默认开启和主动授权，是两套完全不同的安全模型
对于主题同步、头像设置、匿名使用统计这类低敏感功能，默认开启还是默认关闭，更多属于产品体验问题。
但如果涉及企业源码、完整 Git 历史、内部 API、数据库配置、CI/CD 文件、客户项目、生产环境信息，性质就完全不同。
这类数据一旦需要离开本机或企业边界，更合理的设计应该是 Opt-in（主动选择开启）。
也就是说，在启用功能之前明确告诉用户：这个功能需要读取哪些文件，会不会上传数据，数据会发送到什么地方，用于什么目的，保存多长时间，以及关闭以后哪些功能会受影响。
从企业安全角度看，这叫知情授权；从隐私工程角度看，这是 Privacy by Design。
对于拥有本地高权限的 AI Agent，这应该逐渐成为默认设计原则。
六、AI Coding Agent 应该被当成“数据出口”管理
这可能是 ZCode 事件给企业安全团队留下的最大提醒。
过去保护源码，重点通常集中在 GitLab、GitHub、研发终端、CI/CD、制品库、DLP 和代码仓库权限。
现在应该再增加一类资产：
AI Coding Agent
因为它天然同时拥有三个高风险条件：能读取源码、能够访问网络、能够主动执行任务。
这三项能力组合起来以后，Coding Agent 本身就成为了一个潜在的数据出口。
过去为了防止源码泄露，企业可能会限制员工把 ZIP 上传到个人网盘。但在 Agent 时代，员工甚至不需要主动压缩项目，工具自己就可以遍历文件、读取内容、发送 API 请求、调用 MCP、运行脚本。
因此，企业不能继续用“允许使用 ChatGPT”或者“禁止使用 ChatGPT”这种过于粗粒度的策略管理 AI 编程工具。
真正需要管理的是 Agent 的能力边界：谁能安装，允许使用哪些模型，哪些代码仓库可以接入，数据是否离开公司网络，是否支持 Zero Data Retention，是否允许读取 .git，MCP 可以连接哪些系统，Shell 能执行到什么程度，Agent 是否能读取生产 SSH Key。
七、从安全运营角度，企业应该怎么管？
完全禁止 AI Coding Agent 并不现实。
它确实能够显著提升代码阅读、重构、调试和自动化开发效率。如果企业一刀切禁止，最终很可能出现另一种结果：员工转而偷偷使用。
一旦进入 Shadow AI 阶段，安全团队反而完全失去可见性。
更现实的方案是分级治理：普通公开项目可以允许使用云端 Coding Agent；一般内部项目可以使用经过企业评估、具有明确数据策略的模型服务；涉及核心算法、客户源码、生产配置、关键基础设施代码的项目，则应该优先考虑企业版、私有部署、本地模型或者隔离开发环境。
同时，AI Coding Agent 的网络出口也应该进入企业已有的代理和审计体系。
安全团队至少应该知道：Agent 正在连接哪些域名，是否访问对象存储，什么时候产生大规模上传流量，是否访问未知 API，是否绕过企业代理直接连接公网。
如果一个 Coding Agent 在没有明显用户操作的情况下，突然产生几百 MB 上行流量，本身就应该成为一个值得关注的检测信号。
八、不要只保护当前代码，还要保护 Git History
企业还应该重新检查 Secret Scanning 策略。
不要认为 .env 没有提交就安全。真正容易被忽略的，往往是 Git History。
如果生产密钥、云 AK/SK、数据库密码、Webhook Token、私钥曾经进入过 Git History，即使后来已经删除，也应该按照可能泄露进行处置。
尤其是在 AI Agent 能够读取整个代码库的情况下，研发安全团队需要重新定义“代码仓库敏感信息”的范围。
源码安全不能只保护 HEAD。
九、核心项目最好准备独立的 AI 开发环境
对真正敏感的研发项目，最实际的方式可能不是继续堆配置，而是把 Agent 放进隔离环境。
这个环境里可以有源码，可以运行测试，可以访问开发依赖，但不应该存在生产 SSH Key、管理员 Cookie、生产数据库密码和长期云凭据。
Agent 即使出现误操作，也只能影响有限范围。
不要假设工具永远不会出问题，而是提前限制出问题之后的爆炸半径。
未来 Agent Security 很重要的一条原则，不是问“这个 Agent 安不安全”，而是问：
如果这个 Agent 出问题，它最多能碰到什么？
十、开源之后，信任问题就解决了吗？
ZCode 在事件之后选择开源。
对于一个能够读取本地文件、执行命令并连接云端服务的 Agent 来说，可审计当然是一件好事。
社区可以检查它如何扫描文件、如何构造上下文、如何保存凭据、如何发送网络请求、如何调用 MCP、如何处理权限。
但开源本身不是终点。企业还会继续关心：官方二进制是否由公开源码构建，服务端到底执行了哪些逻辑，数据保留策略是否真正生效，未来版本会不会增加新的数据路径，第三方插件和 MCP 会不会引入额外风险。
因此，对于高权限 AI Agent，更成熟的信任体系应该逐渐包括：
开源代码 + 可复现构建 + 第三方审计 + SBOM + 安全响应机制 + 明确的数据处理说明
真正能够恢复信任的，从来不是一句“我们已经修复”，而是后续每一个版本的数据行为都足够透明。
十一、ZCode 只是一个开始
这件事并不是 ZCode 独有的问题。
Claude Code、Codex、Cursor、Gemini CLI，以及越来越多国产 Coding Agent，都在朝同一个方向发展：读取更多文件，执行更多命令，连接更多工具，拥有更长上下文，自主完成更复杂的任务。
从产品角度看，这是能力越来越强。
从安全角度看，则意味着 Agent 的信任边界越来越大。
过去，我们只需要担心模型会不会把代码写错。
以后还必须继续问：它读了什么？它把什么送出去了？它继承了什么权限？它连接了哪些 MCP？它执行了哪些命令？它保存了哪些上下文？它什么时候在后台运行？
AI Coding 真正进入企业以后，这些问题都会从“隐私设置”变成正式的研发安全问题。
最后
ZCode 这次事件，很容易被概括成一句：
“AI 编程工具偷偷上传代码。”
但这样理解，其实太简单了。
真正值得关注的是：我们正在把越来越大的本地权限交给 AI Agent，却仍然用传统 SaaS 的安全思维管理它。
一个普通 SaaS 网站通常只能看到你主动上传的数据。
一个 Coding Agent 看到的，却可能是整个工作区。
它可以读取源码、读取 Git 历史、运行命令、访问网络、连接 MCP、修改文件，甚至长时间自主执行。
所以企业真正应该问的，已经不只是：
“这个模型写代码厉不厉害？”
还应该问：
“为了让它写代码，我们到底给了它什么？”
源码去了哪里？Git History 有没有离开本机？凭据能不能被读取？网络出口有没有审计？Agent 能不能直接碰生产？用户有没有真正的关闭权？
如果这些问题答不上来，那么 AI 编程工具带来的就不只是效率提升。
它也可能成为企业研发体系里一个新的、高权限数据出口。
ZCode 这次风波最终会过去，但它留下的这个问题，不会。
参考资料
-
ferstar：ZCode Silent Workspace Snapshot Upload 分析
-
Z.ai / ZCode 官方回应与更新说明
-
ZCode 官方 GitHub 开源仓库
-
ZCode Repo Wiki 与 Safety Confirmation 官方文档
-
Reuters 关于 Z.ai 后续安全评估与数据保留政策的报道
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：NowSec JacobWang
JacobWang《ZCode 静默打包代码库之后： AI 编程 Agent 的安全边界该重画了》