3.5万Grok应用“裸奔”

35,578个应用无需登录，Grok自己也未能幸免

Grok Build被曝出现大规模数据暴露：安全公司Claroc检查的37,571个在线应用中，有35,578个无需登录即可打开，占比达到94.7%。暴露内容不只是个人制作的小游戏和演示页面，还包括患者医疗信息、员工账号密码、企业销售数据，以及Grok所属公司SpaceXSI和X员工制作的内部应用。(blog.claroc.io)

这起事件的准确性质，并不是攻击者攻破了某个数据库，而是大量应用被以近似公开的方式发布，随后又能通过被动DNS数据批量发现。换句话说，门没有被撬开，问题在于门原本就没有锁，而且门牌号还被收录进了一本可以买到的通讯录。

截至2026年11月11日，SpaceXSI已经下线其员工制作的24个暴露应用，但Claroc称，其他用户和机构发布的开放应用在调查公开时仍可访问。SpaceXSI也没有明确表示是否会主动通知所有受影响的应用所有者。(blog.claroc.io)

这次到底泄露了什么

Claroc的扫描结果显示，问题规模远大于几份误传的内部文档。研究人员通过常见的子域名发现方法收集了43,601个grok.me地址，实际测试了其中43,551个；37,571个应用仍然在线，其中35,578个可以在无登录状态下打开，只有1,993个返回HTTP 401未授权错误。(blog.claroc.io)

关键数据可以归纳如下：

| 指标 | 数量 | 占比或说明 | |---|---:|---| | 发现的grok.me应用地址 | 43,601 | 通过子域名发现技术获得 | | 实际测试地址 | 43,551 | 从公网、未登录状态访问 | | 仍在线应用 | 37,571 | 排除已下线地址 | | 无需登录即可打开 | 35,578 | 占在线应用的94.7% | | 返回HTTP 401 | 1,993 | 占在线应用的5.3% | | SpaceXSI与X员工应用 | 24 | 已在披露后下线 | | 可确认所属机构 | 30家 | 其中6家为《财富》500强 | | 估算包含私人数据的应用 | 约650—800个 | 约占开放应用的1.8%—2.2% |

暴露数据的敏感程度，已经超出普通产品Bug的范畴。Claroc确认的案例包括一家医院超过3,500人的员工名单、一名重症监护患者的化验和呼吸机数据、消防人员姓名与工号、船员姓名与员工编号，以及一家承包商直接写在前端脚本中的18组明文账号密码。(blog.claroc.io)

SpaceXSI自己的应用同样未能幸免。研究人员发现的24个内部应用包括一份标记为机密的新员工入职计划、一张包含594个客户账户的销售区域图、8份X广告方案、4个广告客户看板，以及多个面向不同地区客户的营销报告；其中一个看板还追踪了160万美元的销售目标。(blog.claroc.io)

这组数据揭示了一个重要事实：AI应用生成器正在被员工用于真实业务，而不是停留在“做个贪吃蛇”或“生成一个落地页”的玩具阶段。当销售人员把客户名单导入应用、医院员工制作排班工具、项目团队建立内部看板时，Vibe Coding生成的已经是影子业务系统，只是它没有传统业务系统的权限、审计和安全评审。

随机链接为什么不等于私密链接

被动DNS是收集和查询域名历史解析记录的基础设施，它可以记录某个子域名曾在何时被解析、指向什么地址。安全团队通常使用它调查恶意域名和攻击基础设施，但同样的技术也可以批量列出某个平台下曾被访问过的应用子域名。

Grok Build为每个发布应用分配一个独立的<名称>.grok.me主机名，名称通常由多个随机单词组成。产品设计者显然希望随机字符串能够产生“只有拿到链接的人才找得到”的效果，但独立主机名必须经过DNS解析；一旦用户或同事访问应用，这个名字就可能进入被动DNS服务的历史数据集。

这意味着，四个随机单词或一长串随机字符只能防止人工猜测，无法防止主机名枚举。研究人员不需要破解随机算法，也不需要从聊天记录里偷走链接，只需要搜索*.grok.me的历史记录，就能得到大量已经存在的应用地址。

“Anyone with the link”也因此成为一个具有误导性的产品表述。它在普通用户眼中通常意味着“没有链接就无法访问”，但从安全模型看，它真正表达的是“任何发现这个地址的人都可以访问”，两者差别很大。

| 分享方式 | 用户直觉 | 实际安全边界 | 主要风险 | |---|---|---|---| | Only you | 只有本人可用 | 账号身份验证 | 账号被盗或权限配置错误 | | Invited users | 指定成员可用 | 身份验证加成员授权 | 邀请列表和离职回收失误 | | Anyone with the link | 链接近似密码 | 只依赖地址保密 | DNS、搜索引擎、日志和聊天转发泄露 | | Public | 任何人可用 | 无访问限制 | 敏感数据被主动公开 |

Claroc的测试表明，Grok Build本身具备有效的私密访问能力：应用切换至“Only you”后，外部访问页面及数据函数都会收到HTTP 401；取消发布后，应用也能在数秒内下线。真正的问题不是平台完全没有权限功能，而是普通付费账号的发布流程预先选择了“Anyone with the link”，安全选项没有成为默认路径。(blog.claroc.io)

有登录按钮，也不代表有权限控制

身份验证是确认访问者是谁，授权则是判断这个人是否有权访问特定数据。AI生成应用最危险的错误之一，就是做出了看似专业的登录页面，却没有真正实现成员权限检查。

Claroc为了验证写入权限，使用虚构数据创建了两个自己的测试应用。第一个应用包含数据库但没有登录功能，任何访客都可以新增数据，而且新增内容会被后续访客看到。

第二个应用被描述为“四人销售团队使用的客户列表”，Grok主动生成了Google和X登录按钮，并声称这样可以避免客户姓名、电话和邮箱直接暴露。然而生成的业务逻辑会先把任何完成登录的人加入团队，再检查这个人是否属于团队，因此权限检查必然通过。一个从未被邀请的外部Google账号可以查看全部客户、修改记录并删除数据。(blog.claroc.io)

这个错误比“忘记加登录”更值得警惕，因为它通过了非技术用户的视觉检查。页面有登录按钮，OAuth流程能够跳转，头像和用户名能够显示，整个应用看上去像是有权限保护；但在代码层面，系统只解决了“你是谁”，没有解决“你是否应该进来”。

AI编程Agent尤其容易制造这种安全幻觉。模型擅长补齐用户能看到的产品元素，例如登录页、用户菜单和权限提示，却不一定自动构建组织域名限制、角色模型、服务端授权、数据库行级策略以及管理员审计记录。界面完成度越高，非专业用户反而越容易误判应用已经达到生产标准。

这不是Grok独有，但Grok的默认设置放大了问题

AI编程Agent是能够理解自然语言需求、自主读取或生成代码、运行工具并交付软件成果的智能系统。与传统代码补全不同，它们正在把需求、开发、部署和分享压缩到同一个对话窗口里。

Claroc在报告中指出，ChatGPT生成的应用同样可能使用独立主机名，也会出现在被动DNS记录中；但其测试时，ChatGPT应用的初始分享状态为“Only me”，只有用户主动修改权限后外部才能访问。Grok Build在研究所用的普通付费账号中，则将“Anyone with the link”预先选中。(blog.claroc.io)

| 产品或模式 | 应用地址可被DNS发现 | 调查中的初始权限 | 风险判断 | |---|---|---|---| | Grok Build应用 | 是 | Anyone with the link预选 | 地址一旦被枚举即可直接访问 | | ChatGPT发布应用 | 是 | Only me | 地址暴露后仍需账号权限 | | Claude公开Artifact | 地址密钥主要位于URL路径 | 用户主动公开 | DNS通常只能看到主域名，仍需防搜索索引 | | 普通企业内部应用 | 视部署方式而定 | 通常要求组织登录 | 安全性取决于SSO、角色和审计配置 |

这起事件因此不能简单归结为“用户点错了公开按钮”。用户确实完成了发布操作，SpaceXSI也强调发布需要经过多个步骤，但产品设计的责任恰恰体现在默认选项上：当一个工具面向非专业开发者，且允许直接连接数据库、处理业务数据时，默认权限就是安全架构的一部分，而不是一个无关紧要的UI选择。

我的判断是，Grok Build这次暴露的不是单个漏洞，而是一套错误的产品优先级。平台优先优化了从提示词到可分享应用的转化率，把身份、授权和数据分类留给用户自行发现；这种设计能让Demo显得非常流畅，却把最昂贵的风险推给了最不了解安全边界的人。

AI编程正在制造新一代“影子IT”

影子IT是员工绕过公司正式采购、部署和治理流程，自行使用软件或云服务处理业务数据的现象。AI编程工具让影子IT从“注册一个未经批准的SaaS”升级成了“员工自己生成一个未经审查的SaaS”。

传统内部系统上线通常要经过需求评审、代码审查、权限设计、安全测试、域名配置和运维交接。Grok Build、Lovable、Replit、Bolt、v0、Base44和Google AI Studio等工具，则可以让业务人员在数分钟内生成并发布一个带数据库的应用，IT部门可能既不知道它存在，也无法看到里面存了什么。

这种速度差带来了三个结构性问题：

1. 开发者身份发生变化。 制作应用的人可能是销售、运营或行政人员，他们理解业务数据，却未必理解前端代码可见性、服务端鉴权和最小权限原则。
2. 应用边界持续漂移。 一个最初只展示虚构数据的原型，可能在几轮提示后加入真实客户、文件上传和共享功能，但不会自动重新接受安全评审。
3. 企业资产无法盘点。 每个员工可以创建数十个小应用，企业却没有统一的应用清单、所有者、数据分类、访问日志和下线流程。

Claroc提到，其接触的一家企业已经统计出500个AI生成应用。对于大型组织来说，未来需要治理的可能不是几套核心系统，而是数千个生命周期只有几天、但仍可能持有敏感数据的临时应用。(blog.claroc.io)

企业现在应该做什么

企业需要把AI生成应用视为正式的软件资产，而不是聊天记录的附属品。只要应用能够保存、查询或修改业务数据，就应该进入资产盘点和权限治理范围。

短期内，使用AI编程工具的团队至少应执行以下检查：

• 搜索企业网络、浏览器日志和被动DNS记录，识别员工创建的grok.me及其他AI应用域名。
• 使用未登录的无痕窗口测试每个应用，确认外部人员无法查看页面和调用数据接口。
• 检查登录后的授权逻辑，避免把“成功登录”直接等同于“组织成员”。
• 搜索浏览器会下载的JavaScript文件，确认其中不存在密码、密钥、患者信息或完整员工名单。
• 为每个应用记录所有者、数据类型、访问范围和计划下线日期，及时关闭无人维护的项目。
• 禁止将真实生产数据复制到没有组织身份验证、角色控制和审计能力的AI生成应用中。

平台侧也必须修改默认设计。Claroc建议将“Only you”设为默认值，增加仅限企业邮箱域名的分享模式，对“包含数据库但没有登录”的应用发出阻断式警告，并在用户提到团队场景时自动生成明确的邀请名单和服务端授权逻辑。(blog.claroc.io)

更进一步，AI编程Agent不应只检查应用能否运行，还应在发布前执行安全验收。一个生成了客户数据库的Agent，至少应该主动询问数据是否敏感、谁可以访问、是否限制企业域名、是否需要角色权限，以及应用应该保存多久。

真正的风险是“默认生产化”

Grok Build事件表明，Vibe Coding的主要矛盾已经从“代码质量够不够好”转向“一个看起来能用的应用，是否会被误认为可以直接投入生产”。35,578个开放应用并不意味着每个应用都包含秘密，但94.7%的无登录比例说明，公开访问不是孤立失误，而是一种大规模重复出现的结果。

这也是所有AI编程产品必须正面回答的问题：模型可以在几分钟内搭出一个界面，但谁负责权限模型、数据治理、漏洞修复和应用下线？如果平台只把生成速度作为核心指标，却把安全默认值藏在发布流程里，那么Agent节省的开发时间，最终可能会以事故响应、合规处罚和客户信任的方式加倍偿还。

Grok Build仍然是一款能力很强的编程Agent，其开源代码显示，它已经具备代码库理解、文件编辑、Shell执行、网页搜索、沙箱和多Agent等完整能力。但能力越强、发布越简单，平台就越不能继续假设用户知道什么时候应该停止“做Demo”，开始按照生产系统的标准处理安全。(github.com)

这次事件最值得记住的不是3.5万这个数字，而是一个产品原则：对AI编程Agent来说，默认私密不是保守设计，而是最低限度的安全设计。

参考来源

• Grok Build官方开源仓库：包含Agent运行时、终端界面、工具系统、沙箱及项目结构说明。
• Reddit：35,000个Grok Build应用数据暴露讨论：社区对本次事件规模和影响的讨论。
• Reddit：Grok Build上传完整代码仓库的技术讨论：此前围绕Grok Build数据边界与仓库上传行为的社区分析。