Grok Build 被实锤偷传代码库！AI 编程工具的隐私信任危机
2026年7月14日，程序员鱼皮在公众号发布了一篇引爆AI编程圈的报道：安全研究员 @cereblab 通过精心设计的钓鱼测试，实锤了 xAI 旗下 Grok Build 在用户明确拒绝的情况下，偷偷将整个代码仓库连带完整 git 历史打包上传到 Google Cloud。更令人不安的是，包括 SSH 密钥、密码管理器数据、浏览器记录在内的用户隐私全部明文传输。马斯克本人出面承认并道歉，xAI 紧急上线了 /privacy 命令供用户清除数据。但正如鱼皮所说：「数据是删了，但想修复信任就没那么容易了。」
钓鱼测试：如何揭穿”代码不出本地”的谎言
Grok Build 是 xAI 在 2026年5月上线的 AI 编程工具。其官方宣传页上明确写着——「代码不出本地」。这句话是开发者敢于将代码交给 AI 工具的底线。
安全研究员 @cereblab 对此存疑。他设计了一个精巧的钓鱼实验：
- 创建一个独立的测试仓库，埋入唯一的假 API 密钥和数据库密码（每个都做了独一无二的标记用于追踪）
- 通过 mitmproxy 截获 Grok Build 发出的所有网络数据包
- 特意只让 Grok 回复一个 “OK”，明确要求不许打开任何文件
实验结果令人震惊：
- Grok 确实乖乖回了 “OK”
- 但后台同时将整个仓库连带完整的 git 历史打包上传
- 上传目的地：Google Cloud 上一个名为
grok-code-session-traces的存储桶——并非 xAI 自己的服务器 - 一个 12GB 的测试仓库，实际传出去 5.1GB
- 同一时段 AI 对话本身只用了 192KB 流量——偷传的数据量是正常工作的 2 万多倍
- 埋的假密钥完整保留，明文传输，未做任何脱敏处理
关了”帮助改进模型”也没用
有人可能会想，是不是把设置里的”帮助改进模型”开关关掉就安全了？
鱼皮在报道中明确指出：关了之后照样上传。
这个开关只负责控制「要不要拿你的数据训练 AI」，根本不管代码有没有离开你的电脑。后来社区有人深入扒源码，发现有隐藏参数可以阻止上传——但 xAI 的官方文档从未提及这些参数的存在。
这已经不是”隐私政策写得不清楚”的问题了。这是用户明确选择退出、产品仍然在上传数据的故意行为。虽然很难证明这是 xAI 自上而下的决定还是工程实现的疏漏，但无论哪种解释，对用户信任的伤害都是一样的。
339 次上传，主目录全部暴露
故事在另一位研究者复现实验时变得更加惊悚。
他的日志显示 Grok Build 在运行期间记录了 339 次自动上传。其中有一次，日志直接显示出他整个电脑的主目录被上传——这意味着 SSH 密钥、密码管理器数据、浏览器中的保存密码，全部可能被传到了 Google Cloud。
这不是代码仓库的安全问题——这是整个计算机的安全问题。
马斯克道歉：删除数据，上线 /privacy
事情在开发者社区发酵约 2 天后，马斯克本人终于下场回应。
根据鱼皮的报道，马斯克先承认事情属实，紧接着承诺所有历史用户数据全部删除。xAI 同步紧急上线了 /privacy 命令，让用户可以自行清除数据。
但删除数据和修复信任是两回事。正如鱼皮在文中的忠告：
“如果你之前用过 Grok Build，现在就去执行 /privacy 命令清除数据，然后把所有可能泄露的密钥全部轮换一遍。“
AI 编程工具的隐私信任危机
Grok Build 事件不是孤例。
2026年6月底，Claude Code 出现了中国 IP 大面积封号事件（鱼皮B站相关视频 36.8 万播放），虽然后续被澄清与 Anthropic 的反滥用机制有关，但这件事让国内开发者意识到 AI 编程工具的”黑盒”风险——你并不知道你的代码和数据在云端经历了什么。
再往前看，Codex 的 logs_2.sqlite 被曝出对 SSD 的写入放大问题——虽然这是本地 Bug 而非隐私问题，但它同样反映了 AI 编程工具在”用户不知情的情况下做了什么”这个核心问题。
Grok Build 事件把这个问题推到了极致：不是 Bug，不是疏忽——是标榜”代码不出本地”的产品在系统性地、静默地上传完整代码库。
开发者该怎么办？
结合鱼皮的建议和我自己的经验，几条实用的准则：
1. 永远不要盲目相信 AI 工具的隐私承诺 “代码不出本地”、“端侧处理”、“隐私优先”——这些话术在没有第三方安全审计的情况下，都不应该被当作事实。
2. 装好工具后的第一件事：翻遍所有隐私设置 把所有和”数据分享""改进模型""使用分析”相关的选项全部关掉。即使关掉也不能保证完全安全（Grok Build 就是前车之鉴），但至少是最低限度的防护。
3. 企业机密代码需要隔离 如果你的公司有代码安全合规要求，对 AI 编程工具的使用必须有明确策略：哪些代码可以交给 AI、哪些绝对不能、数据流向哪里。这不是”保守”——Grok Build 事件证明，这种谨慎是必要的。
4. 密码和密钥管理 AI 编程工具理论上能读取你电脑上能读取的任何东西。使用独立的密码管理器（而非浏览器保存）、定期轮换密钥、对敏感项目的 .env 文件设置严格的访问控制——这些操作在 AI 编程时代变得比以往任何时候都更重要。
5. 用完就清 如果你之前用过 Grok Build，立即执行 /privacy 命令清除数据。对于其他 AI 编程工具，定期检查数据导出和清除功能。
结语
Grok Build 事件可能是 2026 年 AI 编程工具赛道最大的信任危机。它揭示了一个事实：AI 编程工具目前处于”野蛮生长”阶段，隐私保护几乎完全依赖厂商的自律——而自律已经被证明是不可靠的。
对于那些正在使用或考虑使用 AI 编程工具的开发者来说，这起事件不是让你放弃 AI——而是让你带着清醒的意识使用它。AI 编程工具能极大提升效率，但你的代码、密钥和隐私数据的保护，最终还是要靠你自己。
鱼皮说得好：「不要盲目相信任何 AI 编程工具的隐私承诺。」这不是恐惧，这是 2026 年的基本素养。
参考来源：