← 全部新闻

文章以英文发布。

AI SecurityShadow AIData Protection

Researchers Found 35,578 Grok-Built Apps Open to Anyone, Including Patient Data, Staff Rosters and Plain-Text Passwords. Do You Know What Your Employees Have Published With AI App Builders?

Obiguard Research Team·2026年11月12日·6 min read

Security firm Claroc says 35,578 of 37,571 live apps built with Grok's chat-based app builder, 94.7%, opened for anyone without signing in, and that roughly one in ten of them held internal business or personal data. In its GhostShares 2 report, published 10 November 2026, Claroc lists a confidential sales territory map, an ICU patient briefing, a hospital staff roster and a timesheet app with 18 plain-text passwords among the exposed material. The Cloud Security Alliance followed on 11 November with a research note calling it part of a wider "public by default" pattern in AI app builders, while noting it has not independently verified Claroc's figures.

Nothing here required an exploit. People asked a chatbot to build them a useful internal tool, clicked Publish, and accepted the default.

What Claroc found

  • Scale: Claroc enumerated about 43,600 app names under grok.me (its report gives both 43,551 and 43,601). 37,571 were still online; 35,578 of those loaded with no sign-in, and 1,993 (5.3%) returned a login error.
  • Sensitive content: about 3,500 open apps held internal business or personal data, and Claroc estimates around 2%, or 650 to 800 apps, held material it rates high or critical. That estimate comes from an AI classifier checked against a manually reviewed sample.
  • Who was affected: 24 apps were built by staff at SpaceXSI (which owns Grok) and X, including a sales territory map covering 594 accounts and an advertising proposal to a US federal agency. Claroc identified 30 other organisations with internal data in open apps, six of them in the Fortune 500.
  • Examples: a fire department shift board with names and badge numbers, a trucking firm's list of more than 1,000 driver recruits with personal email addresses, and a contractor timesheet app whose client-side script contained 18 accounts with plain-text passwords, administrators included.

How the apps became public

Three defaults lined up. Each published app gets its own hostname, <name>.grok.me, and Grok proposes four random words as the name, which looks secret but is not: hostnames show up in DNS, and passive DNS services record lookups in searchable databases. In Claroc's paid test account, the publish dialog had "Anyone with the link" preselected, ahead of "Invited users" and "Only you". And the generated apps often had a database but no sign-in.

Claroc did not test write access on apps it did not own. On two test apps of its own, it found that an anonymous visitor could add records to an open contact list, and that a "Continue with Google" sign-in added each new user to the team before checking membership, so any outside Google account could read, edit and delete every record.

SpaceXSI's position, as reported by Claroc, is that apps stay private until a creator shares one, and that employee accounts default to "Only you". After the report it removed the 24 apps built by its own staff (CSA says within about two days). Neither source reports a change to the default for ordinary users, or a plan to notify other affected owners; Claroc says it has begun notifying organisations itself.

Why this is a governance problem, not a Grok problem

CSA's note makes the same point: the risk sits with any AI tool that lets a non-developer turn company data into a hosted web app in minutes. The person building it is usually solving a real problem, such as a shift board or a timesheet, and has no reason to think about DNS, authentication or default sharing. Security teams, meanwhile, often do not know the app exists, because it lives on someone else's domain and never passed through a change process.

It is the same gap behind our recent report on a contractor's personal coding agent inside a Pentagon network: the AI tool worked as designed, and the organisation had no view of what was being done with it.

What to do now

  1. Look for your organisation's apps. As CSA suggests, search passive DNS for AI app-builder domains such as grok.me, and open anything attributable to you in a private browser window. Only test apps that are yours.
  2. Lock down or unpublish anything with internal data. Switch it to "Invited users" or "Only you", then confirm an outside visitor gets an error.
  3. Read the app's scripts for secrets. Rotate any password, API key or token found in client-side code, and assume it has been seen.
  4. Test sign-in with an outside account. A login screen is not access control if any Google account is let in.
  5. Decide which AI builders are sanctioned for which data. Write it down, tell staff that "anyone with the link" means anyone, and use proxy or gateway rules to flag uploads of sensitive files to builder domains.
  6. Ask vendors the questions CSA lists: default sharing, organisation-only sharing, audit logs, and whether an admin can take down an employee's app.

How Obiguard Governance AI fits

Steps 5 and 6 come down to giving people an approved way to use AI with company data, and being able to see what goes through it. Obiguard Governance AI provides that for the AI agents and applications your organisation routes through it. In-path inspection checks each prompt and non-streamed response against your policy before the call completes, with guard types for PII, injection and off-scope content plus your own keyword and regex rules, so a request that carries a staff roster or a credential can be flagged, redacted or blocked. Allow-lists bind each agent to an approved provider and model list, and the audit ledger records what was sent, by which agent, and what policy decided. Scope matters: Governance AI only sees traffic that passes through it. It cannot discover or unpublish an app someone built directly in a consumer AI builder, and it does not scan third-party domains. What it does is make the sanctioned route the easier one, with a record of what happened on it. To see how a policy would apply to your use cases, get in touch or read about Governance AI.

Sources

Obiguard 如何帮助

将其转化为强制执行的策略,而不只是提高意识。

Obiguard 位于贵组织每一次 AI 请求之前——依据护栏、合规框架和审计追踪筛查提示词与输出,而这样的报道正说明了它们的必要性。

了解运作方式 →