7月14日，安全研究机构Cereblab发布报告称，SpaceXAI旗下的AI编程工具Grok Build CLI存在严重隐私安全问题——该工具会在未经用户明确同意的情况下，将用户完整代码仓库打包上传至Google Cloud服务器。这一发现迅速引发了全球安全社区和开发者群体的广泛关注。
据Cereblab披露，Grok Build CLI在运行时会扫描用户本地项目目录，将包括源代码、配置文件、依赖清单在内的完整代码库上传至云端，甚至包括用户在.gitignore中指定排除的文件以及已从git历史中删除的敏感信息。与此前曝光的类似AI编程工具相比，Grok Build的数据留存范围"显著过大"，远超出了正常调试和代码分析所需的合理范围。
The Verge的报道进一步证实了该事件的严重性。报道援引伦敦国王学院独立安全研究员Lukasz Olejnik博士的分析指出，这种程度的数据留存"超出合理范围"，潜在泄露的数据可能包括"专有源代码、安全漏洞信息、个人数据、基础设施详情以及凭证信息"。
事件的时间线如下：7月13日（周一），Cereblab发布技术报告，详细披露了Grok Build的上传行为。研究显示，Grok Build CLI会将整个代码仓库打包并传输至SpaceXAI的Google Cloud后端服务器，其数据采集范围远超Claude Code等同类工具。报告发布后，SpaceXAI迅速作出回应，在服务器端返回了"disable_codebase_upload: true"标记，停止了代码库上传行为。
Elon Musk随后在X平台上回应称，所有此前上传的数据将被"完全彻底删除"，并表示"隐私设置始终被尊重"。但他同时请求用户允许SpaceXAI保留部分数据，称这对"调试问题很有帮助"。SpaceXAI官方账号最初回应称，用户可通过CLI中的"/privacy"命令禁用数据留存并删除已同步数据。但Cereblab指出，"/privacy"是每个会话的留存开关，而非本次修复问题的实际控制项，SpaceXAI的回应存在误导之嫌。
截至发稿时，Cereblab的测试确认Grok Build的上传功能已不再触发，但已上传数据的完全删除情况仍有待进一步核实。
Grok Build事件并非孤立案例。随着AI编程助手（如GitHub Copilot、Claude Code、Codex等）的广泛普及，开发者在享受AI辅助编码带来效率提升的同时，也面临着前所未有的数据安全风险。这类工具通常需要将部分代码发送至云端进行处理，但"发送多少""发送什么""发送后如何处理"往往缺乏透明的披露和细粒度的控制选项。
Grok Build事件暴露了几个关键问题：第一，默认行为设计不当。默认将完整代码仓库上传至云端而非仅发送必要的上下文片段，这严重违反了数据最小化原则。第二，控制机制不清晰。SpaceXAI最初指向"/privacy"命令作为解决方案，但该命令与问题的实际修复并无直接关系，说明其隐私控制的文档和实现存在脱节。第三，数据留存政策不透明。用户无法确切知道自己的代码在云端存储了多久、被谁访问过、用于什么目的。
对于企业用户而言，AI编程工具的供应链安全影响尤为严重。源代码是企业最核心的知识资产，一次不经意的完整上传就可能导致核心算法、数据库连接字符串、API密钥、云服务凭证等敏感信息全面暴露。一旦这些信息落入攻击者之手，可能引发灾难性的数据泄露或横向渗透攻击。
面对AI编程工具日益普及的趋势，企业和开发者应采取以下措施保护代码资产安全：
1. 审查AI工具的隐私策略。在使用任何AI编程工具前，仔细阅读其隐私政策、数据留存条款和上传策略，优先选择支持本地推理或具备明确零数据留存保障的工具。
2. 使用网络监控工具。通过本地代理或防火墙规则监控AI工具的对外网络请求，及时发现异常数据外传行为。Grok Build事件中Cereblab正是通过这种方式发现了问题。
3. 实施代码分段策略。在涉及商业敏感代码时，避免将完整仓库暴露给AI编程工具。可以建立专门的"AI沙箱"环境，只将需要辅助编写的非敏感代码片段提供给AI工具。
4. 定期审计AI工具行为。将AI编程工具纳入企业安全审计范围，定期检查其文件读写范围、网络通信目的地和数据存储情况。
© 2026 西宁惠康电子有限公司 | 青海·西宁