94.7% of live Grok Build apps opened without a login, including 24 built by SpaceXSI and X staff

On November 10, security firm Claroc published GhostShares 2, a survey of apps that people built and published with Grok’s chat-based Build mode. Of 37,571 apps still online, 35,578 (94.7%) loaded for an anonymous visitor. Most were harmless: games, calculators, landing pages. Claroc estimates 650 to 800 held private data, and 24 of those were built by staff at SpaceXSI, which makes Grok, and at X.

The report matters less for the raw count than for the mechanism. No one was hacked. People asked a chatbot for an internal tool, pasted in real data, clicked through a publish flow whose access setting was already on “Anyone with the link”, and ended up with a hostname that anyone can find by searching DNS records.

How 43,000 app addresses were found

Grok publishes each app on a shared domain under a hostname made of four random words. That looks unguessable, but a hostname is not a secret. The first time anyone visits it, the name passes through DNS resolvers and lands in passive DNS datasets, where it can be listed with a pattern search on the parent domain. Claroc says ordinary subdomain discovery produced 43,601 names under grok.me (its summary gives 43,551; the report does not reconcile the two).

The team loaded each app’s first page once, without signing in, saved a copy and analyzed it offline. 1,993 apps (5.3%) returned HTTP 401. For the rest, a model flagged pages that looked private and staff checked the flagged ones by hand; a manual review of a random sample produced the 650-800 estimate. Claroc puts roughly 1 in 10 open apps in the “sensitive, internal or personal” bucket and about 2% at high or critical. It says it did not submit forms, call server functions or use any credential it saw, and that it withheld every hostname and app title.

Claroc contrasts this with ChatGPT’s app sharing, where it found the default was “Only me” and hostnames include the account username two levels deep. It also points back to 2025, when more than 370,000 shared Grok conversations turned up in Google search results. Sharing links that double as public addresses is a repeat problem for this product line; an earlier Grok Build release was caught uploading full git repositories.

What was exposed

The 24 staff-built apps included a new-hire onboarding plan for SpaceXSI’s enterprise sales team listing internal systems and chat channels, a sales territory map covering 594 strategic accounts and their pipeline, eight X advertising proposals and decks (one addressed to a US federal agency and marked confidential), four live advertiser account boards with campaign spend, seven campaign reports for advertisers in Brazil, Japan, Korea and Thailand, and two copies of an X brand safety playbook.

Claroc identified 30 other organizations and named none. Twenty-six have more than 1,000 employees and six are in the Fortune 500. Examples from the report:

• A hospital group’s staff event app with a searchable roster of more than 3,500 employees.
• An ICU briefing for a single patient, with labs, imaging and ventilator status.
• A fire department’s live shift board with names, badge numbers and duty hours.
• A trucking firm’s recruiting list of more than 1,000 drivers with legal names and personal email addresses.
• A contractor timesheet app whose page script contained 18 employee accounts with plain-text passwords, admins included.

That last one shows a second failure layered on the first. Generated front-end code often ships its data, and sometimes its credentials, to the browser. An app like that leaks even if the page looks like a login screen.

The default, and the sign-in check that always passes

Claroc built two test apps with made-up data on a paid account. In the publish panel the three options were “Anyone with the link”, “Invited users” and “Only you”, with the first already selected. When it chose “Only you”, outsiders got a 401, and unpublishing took the address offline within seconds. The controls work. They are just not what a user gets by clicking through.

The second test app is the part developers should read closely. Claroc asked Grok for a team customer list with “Continue with Google” and “Continue with X” sign-in. The code Grok wrote adds whoever signs in to the team first and checks team membership afterward, so the check always passes. An outside Google account that was never invited could read every customer, edit one record and delete another. The first test app, a contact list with no sign-in, let an anonymous visitor add a row that the next visitor saw.

So there are two distinct problems. One is a product default. The other is that a model asked for “team access” produced authentication with no authorization, and nothing in the builder warned that an app with a database had no effective access control. The second problem will not be fixed by changing a radio button.

SpaceXSI’s response and the disclosure timeline

Claroc reported the onboarding plan and one advertising proposal to SpaceXSI on November 8, followed by a full report with four proposed fixes, and reported the remaining 22 staff apps on November 9. By publication on November 10, SpaceXSI had taken down the 24 staff apps and answered a reporter’s questions, but according to Claroc had not replied to the report itself or said it would notify other app owners. Claroc has started emailing affected organizations directly.

The company’s position, as Claroc summarizes it: apps are private until the creator shares them, publishing takes several deliberate steps including a disclaimer, and employee accounts default to “Only you”. Claroc’s answer is that extra clicks do not help when the access step arrives with “everyone” preselected, and that the employee default did not prevent 24 staff apps from being public. Both statements can be true. A default protects only the people who never change it, and staff sharing a sales deck with a colleague have an obvious reason to change it.

Claroc is also a vendor. It sells discovery and access controls for AI-built apps, and the report ends with a pitch. The counts come from unauthenticated page loads and a sampled manual review, so the 650-800 figure is an estimate. TeslaNorth’s coverage notes that the research covers Build mode in chat, not the separate Agent Dashboard launched October 1.

What to do if your team uses an AI app builder

Claroc asked SpaceXSI for four changes: serve shared apps on hard-to-guess paths under a single host so the link never becomes a DNS name, add an “everyone in my organization” option tied to the company email domain, make “Only you” the default and show who can open an app before it goes live, and warn at publish time when an app has a database and no sign-in.

Until builders do that, the checks fall to whoever owns the data:

1. Inventory. Find out which app builders employees use. Search passive DNS for those builders’ domains plus your company and product names, and open the hits in a private window.
2. Test access from outside. Sign in to each internal app with an account that was never invited. If it works, the app has a login page and no authorization.
3. Read what the page ships. View the scripts the app loads and search for names, emails, keys and passwords. Data embedded in a bundle is public regardless of the sign-in screen.
4. Unpublish orphans. Apps nobody owns should come down. On Grok, Claroc found unpublishing takes effect in seconds.
5. Put access in the prompt and then verify it. Ask for an invite list and a server-side membership check, then confirm the check runs before any write that grants membership.

Watch for whether SpaceXSI changes the default for paid accounts, whether it notifies the owners of the remaining open apps, and whether any of the hospital or public-sector exposures trigger breach notifications. Claroc’s first GhostShares report covered Meta’s Muse, and the series name suggests more builders are coming.