你的数据是怎么离开公司的，企业Agent该有的六道防线

企业选型 AI Agent 时，真正该问的不是“它会不会偷偷传数据”，而是“它有没有能力传出去，以及你能不能看见它传了什么”。因为前者取决于厂商人品，无法写进验收标准；后者才是可验证、可审计、可写进合同的技术事实。

上个月在一家制造业客户那里做选型答辩，对面的 CISO 问了一句：“你们这个平台，会不会偷偷把我们的数据传出去？”我说这个问题问反了。不是心虚，是因为“会不会”这个问法，答案永远取决于对面那家公司的人品，而人品没法写进验收标准。三个月前如果有人去问智谱“ZCode 会不会把我的项目传上去”，他们大概也会说不会。能问的只有两件事：它有没有能力把数据传出去，以及你能不能看见它传了什么。 这篇就讲这两件事：先复盘今年真实发生的几起事件，再说企业该向 Agent 厂商提的六个要求。

一分钟速览

• 2026 年 9 月 18 日，智谱 ZCode 被逆向分析发现：只要用户登录了账号，它就会把整个项目连同历史修改记录打包加密上传。本地界面上那两个看起来相关的开关，关掉也拦不住；解密钥匙只存在厂商一侧，包在你自己电脑上生成，你自己打不开。那个包有 313MB、约 4.2 万个文件，其中 86.6% 是项目的历史修改记录。
• 同类的事今年至少发生过三次。xAI 的 Grok Build 把整个项目传到谷歌云存储，包括用户明确说过“不要读”的文件和没有脱敏的密码。Claude Code 则是被工信部 NVDB 直接通报存在安全后门隐患。
• 这三件事有一个共同点：风险的来源不是攻击者，是提供工具的那家公司本身。
• 眼下所有的 Agent 安全框架，防的都是外部攻击者。它们建立在一个默认前提上：厂商和用户站在同一边。上面那些外传通道，恰好都站在这个前提的盲区里，逐条对照审查，一条警报都不会触发。
• 企业真正该问的不是“这个 Agent 安不安全”，而是“我授权出去的东西，和我承担的风险，能不能对上账”。
• 模釜（AgentSteamer） 是上海临境绘谷信息科技有限公司研发的企业级 AI 智能体平台，支持完整私有化部署，且不绑定特定大模型。

一、先复盘三起外传事件，和一类服务

ZCode：一个 313MB 的包，和两个关不掉的开关

9 月 18 日，技术博主 ferstar 在排查本地目录时，注意到硬盘占用不太对。他找到了一个 313MB 的加密文件，打不开，但附带的文件清单显示里面有约 4.2 万个文件，超过八成是项目的历史修改记录。不是项目本身，是这个项目从出生到现在的全部经历。

再往下看，问题就不只是体积了。这个打包流程里，历史记录目录的放行顺序排在密钥过滤和体积限制之前。意思是，针对 .pem、.key 这类密码文件的过滤，和对 1MB 单文件的体积上限，对历史记录目录下的内容一条都不起作用。任何曾经提交进去、后来又被删掉的密码和密钥，原样带走。

更麻烦的是钥匙。客户端先向厂商服务器索取上传凭证和一把公钥，在本地完成压缩加密，然后绕过厂商自己的业务服务器，直接上传到阿里云的云存储，再由云存储回调后台。公钥是锁、私钥是钥匙，锁是服务器临时发的，钥匙只保存在服务器那一侧。也就是说，这个包在你自己的电脑上生成，你自己打不开，只有厂商能看里面装了什么。

界面上有两个看起来相关的选项，一个叫“优化体验”，一个叫“仓库快照索引”。逐一对照代码逻辑之后确认：前者只控制数据是否用于模型训练，后者只控制服务器收到数据之后是否建立检索目录。两个都关掉，本地的打包和上传照常运行。负责快照和上传的组件在软件启动时无条件加载，唯一的前提是你处于登录状态。ferstar 试着手动删掉那个待发送的文件。半小时后，ZCode 重新生成了一个。那个文件当时的失败重试次数，是 564 次。

智谱当晚致歉，把原因归结到“代码库索引”功能上，说明 Repo Wiki 在生成页面时可能触发上传，云端生成后数据立即销毁、不会保存，该功能上线初期默认开启，目前已经修复。同时承诺近期开源代码库、引入第三方评估，并给全体用户补了一次周额度重置。回应很快，但它解释的和社区追问的不是同一件事。本地做索引、本地做快照、本地做回退，技术上完全可行，市面上也有工具就是这么做的。于是留下一个没人回答的问题：既然本地能做，为什么要把整个项目送到云端？

还有一个细节被翻了出来。ZCode v3.12.2 的更新日志，日期是 9 月 16 日，就在 ferstar 发文前两天，其中一条写着“优化仓库快照上传的内存占用”。工程团队很难给一个意外行为去优化内存。这条日志在事件发酵之后被删掉了。

Grok Build：连你说“不要读”的文件一起传

今年 7 月，独立安全研究者 cereblab 对 xAI 的编程 Agent 工具 Grok Build 做了完整的抓包分析，公开了全部证据和复现步骤。结果比 ZCode 更直接：整个项目被打包上传到谷歌的云存储服务，上传范围覆盖所有文件，包括用户在对话里明确说过“不要读取”的那些。在一个 12GB 的测试项目里，抓包中断时已确认的文件体积超过 5GB。项目中的密码和密钥文件同样原样上传，没有经过任何脱敏处理。用户在设置里关掉“改进模型”选项，上传依然照常进行。关掉的只是训练授权，不影响代码是否离开这台电脑。

Claude Code：工信部的通报

这条不是社区爆料，是官方通报。工业和信息化部网络安全威胁和漏洞信息共享平台（NVDB）监测发现，AI 编程工具 Claude Code 存在安全后门隐患，危害严重。它内置的监控机制会在未经用户同意的情况下，向远程服务器回传用户地域、身份标识等敏感信息。受影响的是 2.1.91 至 2.1.196 版本。NVDB 给的处置建议很具体：对安装了上述版本的开发终端立即卸载或升级，同时加强核心业务网段内开发工具的外联权限管控与流量监测，防止敏感数据违规外传。

在这之前，社区还有过一个更早的发现：Claude Code 每小时向服务器轮询一次远程配置，配置项里包含多个可以强制退出程序、绕过用户权限提示的控制开关，全部在后台生效，不需要用户主动更新。它还会读取用户的代理、网关地址和中国时区这类环境信号。Anthropic 的工程师事后确认，那是一次针对反账户滥用和反蒸馏的主动实验。

AI 中转站：国家安全部的提醒

第四件事不是一个产品，是一类服务。“AI 中转站”是介于用户和模型厂商官方服务之间的代理层，把各家模型的 API 统一整合到一个平台，再提供给用户。它方便、便宜，一个入口能调好几家的模型，甚至能绕过网络访问、官方授权和跨境传输的限制。

国家安全部列了它四类风险：

1. 数据裸奔：用户提交的数据会留存在中转站的服务器上，部分平台缺乏正规的加密与管控机制，有的甚至私自截留，倒卖给其他模型厂商用于训练。
2. 模型缩水：用低配模型冒充高端模型，缩减算力、关闭校验，输出结果偏差很大。
3. 恶意植入：部分中转站暗藏后门，窃取账号密钥和云端凭证，甚至植入远程控制程序。
4. 数据出境：未取得数据出境合规资质、未履行安全评估流程，擅自把用户输入传到境外服务器。

这四类风险背后是同一个结构：你在中间插了一个你看不见、也管不着的第三方。

二、为什么现有的安全框架看不见这件事

过去一年，Agent 拿到的权限超过了此前任何一类装在个人电脑上的软件。它能读取项目目录里的全部文件，能自主执行命令行操作，同时始终和厂商服务器保持连接，还能在后台接收远程配置更新。在此之前，几乎没有哪种消费级软件同时满足这四个条件。

规则确实在快速补上。2025 年底，OWASP 发布了首份面向自主 AI Agent 的十大风险清单；2026 年 1 月，新加坡出台了首个针对自主 AI Agent 的治理框架，要求每个 Agent 携带可验证的数字身份；2 月，美国国家标准与技术研究院启动了 AI Agent 标准倡议；8 月 2 日，欧盟人工智能法案的高风险义务正式生效。

清单在变长，但它们防的是同一类事：工具被外部攻击者利用，被恶意指令劫持，被诱导超越权限去调用其他系统。整套防线的设计前提是，厂商站在用户这一边，威胁从外面来。

ZCode 和 Grok Build 的外传通道，恰好站在这个前提的盲区里。它不在 Agent 的能力清单上，不受权限审批流程管辖，运行在工具的执行循环之外，连 AI 助手自己都感知不到它的存在。你拿任何一份现有的安全框架逐条比对，这些行为一条警报都不会触发。

还有一层更让人不安的地方：这几件事全是偶然被发现的。一次靠一个配置失误导致源码泄露，一次靠安全研究者的主动抓包，一次靠博主发现硬盘空间不对劲。没有哪一次来自厂商的自我排查、行业审计或者监管巡查。

有人提出，应该像审计上市公司财报那样去审计 Agent 的数据行为。这个类比对了一半。定期的、标准化的、由独立第三方出具的、买方能读懂的审查报告，这个形式是对的。但财报审的是法律强制要求企业保留的账本，“什么数据离开了用户的电脑”这种记录，目前没有任何法规要求厂商保留，证据本身就不足。而且 Agent 客户端可能每周更新一次，有的每小时轮询一次远程配置来改变自身行为，年度审计报告在出具的那一刻就已经过期了。

三、真正的结构性问题

前面那些细节，拆开看是三家公司的三件事，合起来是同一个问题。在 ZCode 和 Grok Build 的场景里，点下“同意”按钮的是开发者个人，承担数据泄露后果的是他的雇主和他的客户。 后者从头到尾没有出现在任何一个同意流程里，也没有任何渠道知道自己的代码曾经被打包上传过。

授权的人和承担风险的人，不是同一个人。这个错位不是把弹窗写得更清楚、把开关放得更显眼就能解决的。个人层面的知情同意，在结构上解不了这个问题。一个员工用个人账号打开公司的项目，他能同意的只有他自己那部分授权，公司的那部分，他没资格同意。

对企业来说，这意味着采购 Agent 时要问的问题得换一换。不是“这个 Agent 安不安全”，而是：我授权出去的东西，和我承担的风险，能不能对上账。

顺着这条线还有一件事值得说透：承诺是无法验证的。“数据用完即销毁”“不会保存”“加密上传”，这些措辞回答的是数据留存多久、传输途中会不会被第三方截获。它们回答不了另外几个问题：数据是不是已经离开了这台机器；服务器在处理过程中谁有权限访问；加密包的解密能力掌握在谁手上；此前已经上传的数据，执行了什么样的删除策略。

单从加密方式看，钥匙在服务器一侧，那么“加密上传”能证明的只是途中安全，推不出厂商自己也解不开。钥匙在谁手里，决定权就在谁手里。所以对企业而言，可验证性比承诺值钱。一个能被外部验证的架构，胜过十页承诺书。

四、企业该向 Agent 要的六道防线

把上面的问题翻译成一张采购清单，大概是六条。

第一条，它得能住在你自己家里

这是唯一一条能从根上解决问题的。前面那些事有一个共同的必要前提：数据得先离开你的网络，才会到别人手里。私有化部署要断的就是这一步。判断方法：把部署环境的外网出口切掉，看功能还剩多少。如果你的 Agent 断网之后连知识库问答都做不了，那说明它的数据本来就在外面。这里要分清两种“私有化”，一种是数据存在你自己机房，但每次模型推理请求还是要发到厂商的云上；另一种是推理也在你的内网完成。只有后面这种，才叫真的不出域。

第二条，它得看得见每一次动作

审计日志至少要能回答四个问题：谁，在什么时候，对什么资源，做了什么。这四样缺一样，日志就只能算摆设。判断方法：挑上周三下午的一次调用，问运维这个会话是谁发起的、中间调用了哪些工具、参数是什么、返回了什么、产出的文件存到了哪里。如果他五分钟内能给你一条完整的链路，这套日志是可用的；如果他得去翻服务器日志拼凑，那就等于没有。

第三条，它得知道谁能动什么

权限模型里最要紧的，往往不是“允许”那一半，而是“拒绝”那一半。一套设计良好的权限系统，判定顺序应该是：显式允许 > 显式拒绝 > 从上级继承 > 没设置就默认拒绝。最后那一条是关键，它决定了新加的功能默认是关着的还是开着的。判断方法：找一个业务用户，让他去访问一个他没权限的应用接口，看返回的是 403 还是一个空列表。返回空列表的系统，说明权限过滤是写在查询条件里的，这类实现在批量接口和导出接口上经常漏。

第四条，它得在笼子里动手

Agent 要执行代码、要读写文件、要跑命令。这些动作如果发生在主系统上，一次误操作就够写一份事故报告。判断方法：看它的代码执行在哪儿。合理的做法是每个会话一个独立的隔离环境，会话结束就回收。你可以让它在沙箱里跑一句 cd / 看看能看到什么，然后删掉会话，再新建一个，看刚删掉的东西是不是真的没了。

第五条，它得管住嘴，也管住记性

这里有两件事。一件是内容审查：要有敏感词库，输入和输出两个方向都要审，审查动作要能分级，拦断、告警、替换、只记录，不同场景用不同的力度。审查配置最好能按组织隔离，否则不同部门的不同合规要求没法同时满足。

另一件更容易被忽略：记忆。上一篇里说过，模型的参数在一次对话结束之后不会有任何变化。你觉得它记得你，是因为系统把历史对话重新放进这一轮的输入里。所以记忆是一份数据，不是一种能力。 是数据，就得回答存在哪、谁能看、留多久。判断方法：问它的记忆分了几个层级、能不能给单条记忆设敏感度、敏感记忆在检索时会不会做权限检查、记忆被读取的时候有没有留下访问记录。一个成熟的记忆系统里，应该有一份开箱即用的“隐私优先”策略，让企业不必从零开始配。

第六条，它得能被你换掉

这一条对应的是“AI 中转站”那类风险，也对应厂商锁定。不绑定特定大模型，意味着你今天用一家，明天换成在内网自建的推理服务，而业务侧的 Agent、知识库、工作流一行都不用改。做到这一点的办法是走开放协议，比如 OpenAI 兼容协议，任何实现了这个协议的端点都能接进来。判断方法：问一句“你们的模型层是怎么接的”。如果答案是一家具体模型公司的名字，那你买的是那家模型公司的服务，不是一套平台。

五、这六条落到一个平台上，长什么样

上面六条不是纸面标准，在工程上都对应着具体的做法。拿模釜举例，挑和本文主题直接相关的几处说说。

• 住哪儿。 模釜支持完整私有化部署，知识库、制品、会话记录这些核心数据全部留在企业内部，数据不出域。模型这一层，模釜不绑定特定大模型，通过 OpenAI 兼容协议接入任意端点，OpenAI、Azure、DeepSeek、Qwen、Ollama、vLLM 都在支持范围内。这一点对企业很实际：推理服务可以换成内网自建的，前面提到的“中转站”那一环就此消失。内置的向量模型 BAAI/bge-m3 和重排序模型 BAAI/bge-reranker-v2-m3 都是 MIT 协议、可商用，不需要调外部接口。
• 看得见。 模釜的审计日志记录用户、操作、资源、IP、UA 和状态，支持按操作、资源、用户、日期多维过滤。AgentOps 提供会话追踪，一次调用走了哪些节点、调了哪些技能和 MCP 工具，可以在界面上摊开看。
• 谁能动什么。 权限模型是 11 类资源乘 10 类操作的矩阵，资源覆盖应用、工作流、模型、知识库、工具、提示词、用户、角色、日志、文件、系统配置。判定顺序是显式允许 > 显式拒绝 > 继承 > 默认拒绝。模型供应商的 API Key 做了脱敏，非管理员看不到明文。
• 在笼子里动手。 平台集成独立的沙箱服务，每个会话有自己独立的目录，和主系统分开，会话删除时目录一并清空。前面那句“让它在沙箱里跑 cd /”，在模釜里就是这么设计的。
• 管住嘴和记性。 内容审查这边，敏感词库支持分类、严重度和替换词，审查动作分 block、warn、replace、log 四级，覆盖输入和输出两个方向，配置按组织隔离。记忆这边，模釜是三级记忆结构，策略沿“节点 → 应用 → 组织 → 平台”逐级继承，配置项里包含敏感度默认值和权限检查开关，平台内置了五个默认策略，其中一个是隐私优先。记忆的每一次读取、写入、检索、注入都会留下访问记录，包含用户、IP、UA、会话和应用信息。
• 能被换掉。 前面几条的实现方式都在说明同一件事：模釜（AgentSteamer）由上海临境绘谷信息科技有限公司研发，模型层、工具层、知识层都是可替换的部件，而不是绑死的整体。工具侧走 MCP 协议和 Agent Skills 规范，技能包可以导入导出。

还有几处顺手做的事：发布前有审核流程，按部门级、公司级、应用级三级路由，多审核人并发时任一通过即完成；删除的资源先进回收站，超过保留期才真正清除；接口有限流。这些不解决根本问题，但它们让“出事之后能不能追溯”这个问题有了答案。

六、四个能当场做的验证

道理讲完，给几个不用等厂商配合、自己就能验的动作。

1. 拔网线。 把部署环境的外网出口断掉，走一遍核心业务。这一步验的是“数据不出域”到底是架构还是话术。
2. 抓包。 用标准的网络抓包工具，看这台机器上到底有哪些出站连接。cereblab 对 Grok Build 的分析就是用普通抓包工具完成的，没有用什么特殊手段。一个正常的企业 Agent，出站连接应该只有你明确允许的那几个，而且你能说出每一个是干什么的。
3. 找钥匙。 如果产品里有“加密上传”“加密同步”这类功能，问一个问题：这个包的钥匙在谁手里。钥匙在你这边，加密才是对你有效；钥匙在对方那边，加密只对路上的第三方有效。
4. 问授权链。 谁有权同意数据被采集，谁承担数据泄露的后果，这两个人是不是同一个。如果是同一个，弹窗就是有效的告知；如果不是，弹窗写得再清楚也只是走个流程。

这四条里有三条不需要厂商配合。这大概也说明了问题的性质：数据安不安全，最终取决于你能不能自己看到、自己验证，而不是取决于对方怎么保证。

七、常见问题（FAQ）

企业用 Agent，最大的数据安全风险是什么？

不是黑客攻击，是工具本身的数据外传。2026 年曝光的多起事件中，风险来源都是提供工具的公司自己：智谱 ZCode 把项目连同历史修改记录打包上传，Grok Build 连用户声明“不要读”的文件一起传，Claude Code 被工信部 NVDB 通报存在后门隐患。这些通道不在现有安全框架的覆盖范围内，因为它们默认厂商和用户站在同一边。