An internal sales map, a hospital staff roster and an intensive care patient’s clinical briefing were among the material left open in apps built with Grok. On November 10, security firm Claroc reported finding 35,578 live Grok Build apps that opened without sign-in. Many were harmless. Some exposed records their creators had good reason to keep private.
Grok’s Build mode can turn a prompt into working software and publish it from the same chat. If you use it to build something for work, check who can open the app before you put real data into it. The sharing choice applies to the project you actually built, whether it’s a timer for your desk or a tool your team uses to handle customer records.
What Claroc found in the open Grok apps
Claroc identified 43,601 hostnames under grok.me, the domain used to host the published apps, and tried 43,551 addresses. Of the 37,571 apps still online, 35,578 opened without sign-in and 1,993 returned HTTP 401, an error that indicates authentication is required. The 94.7% figure applies to the live apps Claroc found and tried. The total number of Grok projects is unknown.
Most of the open apps were games, calculators or landing pages. Claroc estimated that about one in ten contained sensitive or internal information, that roughly 650 to 800 held private data, and that about 2% contained material it rated high or critical in severity. The researchers used automated screening and manual review.
Staff at SpaceXSI, the company behind Grok, and at X created 24 of the open apps. They included a confidential onboarding plan, a sales territory map covering 594 accounts, advertising proposals and campaign reports. Elsewhere, researchers found a roster of more than 3,500 hospital employees, an ICU patient’s clinical briefing and a timesheet app that exposed 18 passwords in plain text. Those passwords were in the code the app sent to visitors’ browsers. The researchers documented public access. Whether anyone else collected the exposed material remains unknown.
Why an obscure Grok app link can become public
A published Grok app gets its own hostname under .grok.me. The name can look like a random string of words, which makes it easy to mistake an unfamiliar address for a private one. Browsers use the Domain Name System, or DNS, to look up the hostname. Those lookups can leave records that make names discoverable, even when the creator shares the link with only a few people. Claroc found app addresses in those records without receiving an invitation.
The path, the part of the address after the hostname, stays out of DNS. Even then, a link can be forwarded or indexed. If the app holds internal records, use an access setting that blocks anyone who lacks permission, even when they have the full address.
Why Google sign-in didn’t keep the test app private
Claroc built two test apps with made-up data to see what access controls Grok generated. One was a contact list. A visitor could add records without signing in. The other was a customer list intended for a four-person sales team. It included Google sign-in, but an account that had never been invited could still read, edit and delete customer records.
Google sign-in can verify who is using the app. That’s authentication. The app still needs to check whether that person belongs on the team and which records or functions they can use. That’s authorization, and it has to apply to the underlying data as well as the screen visitors see.
The researchers made changes only in their own two apps. They say they didn’t sign in to third-party apps, change their data or use any credentials they found. The study measured how many apps opened without sign-in. It leaves open how many of those apps also allowed visitors to change records.
What SpaceXSI says about Grok Build publishing
SpaceXSI says apps stay private until their creators choose to publish, and employee accounts start with “Only you” selected. Claroc agrees that creators have to publish deliberately. It found that the subsequent access screen in the paid account it tested already had “Anyone with the link” selected. A creator can go through several publishing steps and still leave that selection in place.
Claroc says it contacted SpaceXSI on November 8, reported 22 more staff apps on November 9 and published its findings on November 10. SpaceXSI took down all 24 staff-built apps. As of November 12, available reporting had yet to establish a platform-wide change to sharing defaults or confirm that the other exposed apps had been secured.
How to check who can access your Grok Build apps
Start by making a list of the apps you’ve published and the data each holds. If an app contains internal or personal information, choose “Only you” or “Invited users,” as appropriate. On an app you own or manage, open it in a private browser window while signed out and verify that both the page and the data it uses are blocked. For a team app, confirm that an account you haven’t invited is denied access even after signing in.
Review the JavaScript your app sends to visitors for hardcoded passwords or keys. Remove exposed credentials and revoke or rotate them as appropriate. Unpublish apps nobody uses. If private data was accessible, assess what was exposed and whether affected people or organizations need to be notified. Our guide to checking access controls and secrets in AI-generated software covers the same checks for other builders and small apps.
Before you put real employee or customer records into a new Grok app, publish it with sample data and confirm who can open it. Run the check again if you change the sharing settings or add features that handle private data.
More on AI cyber security:
Explore more from Popular AI:
Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast
If you've built an app with Grok Build or another AI app builder, have you ever checked whether strangers can access your app or its private data?