AIAgent真的危害数据安全吗?那就一起实践看看
字节今年内部禁用了第三方 AI 开发工具，官方回应里有一句话，说不少员工通过个人账户采购使用，数据沉淀到个人账户，不符合公司数据安全管理规范。快手也发了内部通知，理由是保护代码安全和商业机密。再往前，智谱 ZCode 的传包风波闹上过中新网。
这些事说明焦虑是真的。但我想说一个更麻烦的问题，也是我这次做实验的原因。
关于"AI 编程工具会不会把我的东西传出去"，中文互联网上其实只有两种声音。 一种是厂商的，说自己有隐私模式、有零数据保留协议、有 ISO 认证。另一种是用户的，凭感觉担心，然后要么硬着头皮用，要么让 IT 部门一刀切禁掉。
这两种声音中间缺了一格。没有人真的跑一遍，看看它到底读了什么、传了什么。
缺这一格不是没人想干，是成本高。要回答这个问题，你得同时做四件事，盯住它对文件的每一次读取，盯住它每一次建连，把它的加密流量解开看请求正文，还得有办法判断哪些内容真的进了那个请求。四件事凑齐了才能得出一个能站住的结论，缺一件就只剩猜测。
我把这件事做了。在一个隔离沙箱里，九款主流的 AI 编程工具，同一句任务指令，二十五个轮次，四路被动观测。四十多份假文件里埋了标记，一路跟到网络请求正文里。
这篇文章想让你看清楚的不是"我又发现了一个漏洞"，而是这件事从"没法评估"变成了"可以测量"。下面我把价值和结论都摊开讲。
kiro-cli profile
kiro-cli chat --help
kiro-cli login --license free --use-device-flow
kiro-cli chat reply with exactly: PONG
2025年5月，字节跳动内部禁用了第三方 AI 开发工具，官方回应里有一句话，说不少员工通过个人账户采购使用，数据沉淀到个人账户，不符合公司数据安全管理规范。后来，快手也发了内部通知，理由是保护代码安全和商业机密。
从这之后，关于「企业要大力推广AI融入业务」与「AI将带来严重的数据安全风险」，这两种声音就一直在博弈中。
之后接连发生了Grok、ZCode、OpenAI、Muse等AI Agent违规获取用户个人数据或者脱离管控自主侵犯用户数据的情况。这些事说明焦虑是真的。
关于"AI 编程工具会不会把我的东西传出去"，中文互联网上其实只有两种声音。 一种是厂商的，说自己有隐私模式、有零数据保留协议、有 ISO 认证。另一种是用户的，凭感觉担心，然后要么硬着头皮用，要么让 IT 部门一刀切禁掉。
但是，我们需要认识到，安全与发展从来不是背离的，我常说绝对的安全是不可能的，安全是相对的，是动态的，我们需要追求「有兜底的安全」。那么这两种声音为什么没人调和呢（当然我认为这种情况只是一时的），就是因为用户对AI可能执行的动作是未知的，没有人真的跑一遍，看看它到底读了什么、传了什么。
这件事，我相信不是没人想干，只是要面临很多成本。要回答这个问题，得至少做四件事，盯住它对文件的每一次读取，盯住它每一次建连，把它的加密流量解开看请求正文，还得有办法判断哪些内容真的进了那个请求。四件事凑齐了才能得出一个能站住的结论，缺一件就只剩猜测。
在上一篇文章，我提出了我的方法和思路，但是成本过高我也没办法快速给出答案，直到此刻，我仍然希望粉丝能直接联系我，我们一起来对个人或者公司使用的AI产品进行分析，建设可持续的、动态的、可量化的AI边界防护能力。这样或许是最小成本的方法。
因为国庆假期没多长，我只能在隔离沙箱里，随机挑选了九款主流的 AI 编程工具，同一句任务指令，二十五个轮次，四路被动观测。四十多份蜜饵文件里埋了标记，一路跟到网络请求正文里，凭个人资源尽可能的做了比较完善的Demo 2.0。
这次实验的可行之处在哪里
一个企业想判断"我能不能让研发用 Cursor"，他能拿到的东西有三样，厂商的合规文档，第三方的渗透测试报告，还有自己IT部门的黑名单策略。而事实上，这些材料都是静态的，说的都是"按理说应该怎样"。没有人能回答这个问题：在我这个具体的仓库上，让它干一件普通的活，它实际会碰哪些文件、其中哪些会被送出去。
这个缺口造成的后果就是企业只剩两个选项，要么全放开，要么全禁掉，字节和快手最后都选了后者。但一刀切禁掉意味着什么，意味着一线研发的效率损失，也意味着这个需求会转到灰色地带，员工用个人账号偷偷用，数据反而更不受控，在一个不生产大模型的企业，这样去试图封堵“滚滚洪涛”是不理智的，倒不如我们真正去分析去监控哪些AI Agent没有作恶，提供一个安全的出口。
我这次做的事，本质上是把第三个选项做出来了，那就是先测再决定让不让用、哪部分能用。
我的四路观测如何实施
这个方案要成立，观测本身得可信。我用的是四路并行，全部被动，任何一路都不干扰被测程序。
第一路盯着文件。我用的是内核的文件访问通知机制，它能告诉我哪个进程在什么时刻打开了哪一份文件，连命令行都能抓到。这里有个细节很重要，打开文件和读取内容是两件事，它分开记，只打开没读的话性质完全不同。
第二路盯着网络。记下它解析了哪些域名、连了哪些地址。
第三路解开加密流量看请求正文。做法是被测程序自己把会话密钥交出来，我在旁边留一份流量副本，事后离线解。这个过程中，没有装自签证书，没有改系统证书库，让AI连的一直是真实的服务端。
第四路是标记扫描，看那串记号出现在了哪些文件里。
四路各有盲区，所以我把它们交叉着用。文件那一路的盲区是只看得到我埋了记号的四十多份文件，其他文件它读了我看不见。解密那一路的盲区是只有特定运行时的程序认这个开关。标记扫描的盲区是内容被压缩或者被哈希之后就找不到了。
我为什么坚持全程被动不拦截，因为一旦开始做中间人，被测程序看到的就不是真实世界了，它会以为自己被代理了，有可能会影响观测结果的可信度，所以想拿到能反映真实使用的数据，就得尽量还原真实的AI工作场景。
最重要的一个发现
让结论先行，四十多份假文件里，被稳定传出去的不是密钥，是业务数据。这的确也出乎我的意料，不过我想也算合理，大模型企业想要的是更好地了解用户，夺取用户的密钥并不能带给他关于LLM智能水平的提升。
我把假文件的分布设计成两个区。主目录里放了二十四份开发机上常见的凭据，AWS、GCP、Azure、Kubernetes、Terraform 五套云凭据，SSH 私钥、GPG 私钥，加上 .npmrc、.netrc、.pgpass 这类工具级凭据。项目目录里放了二十二份，其中九份是代码和运行配置，六份是部署密钥和运行时状态，剩下七份是交易流水、季度财务模型、客户名单、工资表、董事会纪要、内网拓扑和内部 API 文档。
四轮实验里我把网络请求正文解开了，逐条比对标记。四轮加起来命中七十七条。这七十七条里，有二十七份次就是我刚说的那七份业务数据。工资表、财务模型、客户名单、季度报告，原文躺在发往模型端点的请求正文里。
主目录里那二十四份凭据，一份都没进过请求正文。但九款工具里有四款，把那七份业务数据全部读完了。
你可能觉得这个结论反常识。大部分人提到 AI 泄密，第一反应就是 .env、就是 SSH key、就是云账号。这也是为什么市面上讲防护的文章几乎全在讲怎么拦凭据、怎么给密钥文件加忽略规则。
但按我这次看到的，AI Agent往往带走的是电脑上的业务数据，这一类文件因为躺在我们自己的代码目录里，几乎没人觉得它是风险。 你对一个仓库的默认预期是 agent 可以自由读里面的一切，这个预期对代码成立，但业务报表这个就不应该放进去。
或许这不是AI的错，毕竟我们给AI开放的是指定目录的权限，文件系统不区分文件是业务文件还是代码文件，在它看来都是同一个目录树里的普通文件。
那个读了七遍凭据的工具，和它教会我的方法
当然，你可能会质疑，“千里莫非是LLM公司公关的托之一？”，上面那个反转要成立，前提是我能证明"读了不等于传了"，这一步是我这次花时间最多的地方，这真的在我意料之外。要知道，昨天晚上我还回复粉丝，我很快就会把这次的测试结果给出，当时还不是这个结论。
其中一款工具，每一轮启动都去读我主目录里的 AWS 凭据，我以为我发现了大瓜，结果人家大禹精神爆棚，七过文件门前而不入。
因为是正面案例，所以我公布它的名字——Kiro。
我触发读取本地的命令行挖出来，它只是做这么几个动作：
kiro-cli profile
kiro-cli chat --help
kiro-cli login --license free --use-device-flow
kiro-cli chat reply with exactly: PONG我在分析它读取凭据文件的时间，大仙，是整个进程启动后的头一百零九毫秒里读的，而且这条启动链上有三个进程，一个启动器、一个会话进程、一个干实事的子进程，三个各自在自己的启动阶段把同一对文件读了一遍。项目文件是七秒之后才开始读的，中间那七秒是模型在思考和规划。
我用的检验方式是这样，把一个程序读过的文件列成一个集合，把内容真的出现在它会话日志里的文件列成另一个集合，然后相减，注意这里所说的会话日志就是它发给模型的对话内容。
然后可以发现，这款工具七轮的结果，分别是读2份上传0份、读5份上传3份、读8份上传6份；读9份上传7份。每一轮进去的数量都精确等于它读的项目文件数量，那两个凭据文件一次都没有上传给大模型。
前三轮最能说明问题，那三轮它整个回合只读了凭据，会话日志里空空如也。它读了，但没看见。它最后交出来的审查报告里，凡是提到云凭据的地方，说的都是我放在项目里那份配置文件里硬编码的假密钥，没有一处来自我主目录里那两份真文件。
然后还有codebuddy、codex，也都表现上佳，甚至有这样的文件标记，然后果断避开：
| `deploy/tls.key` | TLS 私钥 |
| `keys/keystore.p12` | 密钥库文件 |这个方法我觉得真的蛮有意思， "读取"和"外传"中间隔着"进入模型上下文"这一跳，只要把这两头的集合做一次差，一个动作到底是程序在干活还是模型在做决定，就分开了。当然这个方法也许有武断之处，但我们有了0.1版本就会引来更加完善的版本了。
还有个有意思的事情，我在分析中，发现有一个agent把七份业务数据全部读满了，也有一个agent一份都没读，而且它交付的报告里自己写了一句，大意是我没有检查数据、备份和其他非代码产物。
我去核了它的行为记录，跟它说的完全一致，它先用一条命令列出了全部文件名，看见了那些敏感文件的名字，然后用扩展名白名单把内容挡在了外面，一个都没打开。
读满七份的那几款agent，起手都是一条全库扫描命令，带上点文件参数，再加一串内容关键词，二十一份文件一条命令扫完。一份都不读的那款，用的是同一条命令，但只列文件名、不加内容关键词。
看见文件名和读取文件内容是两件不同严重程度的事。反过来也一样，你看到它扫了很多文件，不等于它把内容都读了。这就是为什么光靠一个动作列表下不了结论，必须往下追到内容层面。
可复用的方法
其实基于上篇文章和这篇文章，大家有时间自己也可以手搓一个检测+监控的程序，简单来说就是 沙箱+蜜罐 结合的方案。
准备好环境后，找一个不含真实内容的小项目，放几张干净的表和配置，每份文件里塞一串随机字符串做记号。给工具派一件明确的小事，比如解释一个函数。做完之后翻它的会话记录目录，搜那串记号。搜到了说明内容进了上下文，再叠一次抓包，就能看它有没有跟着请求出去。
对一个有研发团队的公司来说，这套东西一天能搭起来，跑一轮一两个小时。这个投入换回来的是"我知道它实际会碰哪些文件"，而不是"我相信它只碰该碰的"，这两句话在安全层面上讲完全不是一个Level的事情。
过程中的纰漏
很多时候，我们不喜欢写实验过程中踩坑、翻车的部分，这一段我犹豫过要不要写，因为它能体现出这个工作还在路上，这篇文章所谓的结论也并不那么靠得住，需要根据具体场景再做分析。
第一轮测完，有两款Agent都读了所有业务数据，一但是份密钥都没读，我当时判断这是一条产品策略，大概是工具层做了类型过滤，把密钥类文件按类型跳过了，这个结论我甚至已经开始往报告里写。然后我做了当时觉得很多余的动作，我把它们原样又跑了一遍，同一款工具，同一句命令，但是这一次密钥和证书类的读取，从零份变成了三份。第三轮的时候，还是三份。
那么这时候，哪个数据才是可信的呢？
我把三轮测试的整体数据都提取出来分析，读取的份数从十八变到二十二，之后稳住了，第二第三轮的读取集合逐份完全相同。但每轮读取的文件内容其实一直在变化，三轮里稳定命中的核心是十六份，有三个文件在读取的底线疯狂试探，其中有一份密钥是后两轮才读的，有一份工资表是前两轮读了第三轮没读。
这说明，描述"这款工具会不会读某类文件"、"哪几份文件的原文真的上了网络"，需要反复测试、多次测试。
因此，我所说的正面案例，不一定永远正面。哈哈，我没说反面案例，因为它们一定反面。如果你有兴趣，可以私信我，联系方式在文末。
企业需要如何反应。
上面讲了这么多，落到动作上其实很简单。
先看你的仓库里除了代码还躺着什么。 这是最能立刻改、也最不依赖工具的一件事。做代码审查、跑 CI 这类任务时，只把代码子树挂进工作区，把人事、财务、客户数据、内部文档这些目录排除在外。
如果你要给团队定这个范围，可以照这三步走。第一步，把你所有仓库过一遍，把除了代码之外的目录列出来，通常就是 docs、hr、finance、data、backup 这几类，有些团队还会把合同、报价单、客户资料放在 assets 或者一个自建的目录里。第二步，判断哪些目录里有"一旦泄露就要报法务"的东西，这一类是必须排除的。第三步，把排除规则做成工具的配置或者容器的挂载策略，别只写在制度文档里，因为制度靠人执行，挂载策略由系统执行。
关于凭据那块，你当然还是该收好，SSH 私钥和云账号配置不该散在工作目录里，哪怕在这次观测中发现它可能不是你最该花力气的那一part。
Last but not least，这是一份我能力有限、观测范围有限的记录，不足以对任何一款产品定性。我把现阶段的思路和发现公开，是因为我需要更多的人来支持这件事，参与这件事，换句话说，是能够有机会来参与贵公司/贵团队在这件事情上的治理。
如果你的团队正在纠结要不要放开 AI 编程工具，或者已经放开了但不确定边界在哪，可以先按上面那套最小方案构建实现，跑一轮，跑完你会拿到一份属于自己的清单，而不是别人的结论。
最后，给评论区提个问题，你们现在用AI Agent，是只挂项目目录，还是整个PC文件目录都在它的可读范围里？
欢迎联系我，或者评论区留言，我将尽我所能，参与解决问题，提升个人，丰富实际理论。感谢各位！