研究员报告：Grok Build 泄露事件暴露了数千个应用和机密数据
据报道，一名研究员发现约 35,000 个 Grok Build 应用对任何人开放，暴露了机密数据，其中包括与 SpaceX 相关的材料。
报道内容
据 Ars Technica 报道，一名研究员发现约 35,000 个使用 Grok Build 构建的应用可被任何寻找它们的人访问。据报道，暴露的材料包括机密信息，其中部分据称属于 SpaceX。
该报道将此定性为应用泄露，而非底层模型遭到入侵。这一区分很重要：标题指向的是智能体生成的软件是如何被部署的，而不是模型提供商基础设施内部的入侵。
为什么智能体构建的应用会以这种方式失败
编码智能体擅长快速生成可用的原型。除非被明确要求，否则它们在就身份验证、访问控制和密钥管理做出判断方面要不可靠得多。一个在本地运行的生成应用和一个可从公共互联网访问的应用，在代码上可能看起来几乎完全相同。
当原型被推送到具有宽松默认设置的托管提供商或存储桶时，演示与生产之间的差距会悄然消失。故障通常出在配置上，而不是模型输出：开放的存储桶、缺失的身份验证中间件、未关闭的调试端点，以及被粘贴到客户端代码中的 API 密钥。
开发者应吸取的教训
在审查访问控制之前，应将智能体生成的任何内容视为不受信任的代码。在发布之前，确认每个路由在需要时都要求身份验证，密钥存放在服务器端密钥存储中而不是打包文件中，并且存储和数据库权限默认关闭。
清点也很重要。如果你的团队随意创建智能体构建的应用，你可能不知道有多少应用可被公开访问。定期扫描云账户和托管项目中的开放端点，比在新闻报道中发现它们成本更低。
最后，将影响范围保持在较小程度。为原型使用有范围限制、可轮换的凭据，为实验使用独立账户，并使用短期密钥，这样泄露的令牌只会带来麻烦，而不会成为事故。
与供应商无关的视角
这里没有任何内容是一个模型或一个编码智能体所独有的。任何生成和部署应用的工具都会继承相同的风险，无论编辑器背后是哪个 LLM API，适用的控制措施都相同。评估编码智能体的团队应询问部署默认设置、密钥处理方式，以及生成的基础设施模板是否默认安全。
对于使用 LLM API 构建的团队来说，实际的教训是将模型与部署分开。你的 API 密钥、云权限和审查流程才是真正的安全边界，而不是智能体的输出。