What happened
TeslaNorth’s November 10 article reports findings from security firm Claroc about applications published from Grok Build, the chat-based mode for building software. Claroc says 35,578 apps opened without sign-in. It estimates that 650 to 800 of them contained private data, while noting that most of the apps it identified were ordinary games, calculators and websites. The article describes this as a risk associated with publishing settings, not a claim that every app or every Grok Build project was exposed.
Among the apps Claroc says it found were 24 belonging to SpaceXSI and X staff. The article says these included sales material and that the apps were taken down after disclosure. It does not describe those 24 as representative of all exposed apps, and the estimate of private-data apps is presented as Claroc’s assessment. The report therefore points to a potential access-control problem at meaningful scale, while the published account does not establish that all identified information was accessed or misused.
Claroc says its paid account had “Anyone with the link” preselected during publishing. In that mode, the article says, anyone holding the link could open the app. It also makes an important distinction: the apps did not become public automatically; creators still had to publish them. Claroc reportedly found faulty team-access checks in its own test app. The firm said it did not modify other users’ apps to reach that result.
TeslaNorth also relays a response from SpaceXSI: publishing requires several steps, and employee accounts default to “Only you.” Claroc reproduced that response in its report, according to the article. The researchers recommend private-by-default sharing and organization-based access. In their tests, selecting “Only you” successfully blocked outsiders. The article separately describes Grok’s Agent Dashboard, introduced October 1, as an interface for coordinating multiple coding agents with parallel tasks and separate Git worktrees; Claroc’s investigation, however, concerned apps published from chat-based Build mode, not that dashboard.
What the archive adds
New Runtime’s earlier coverage found a related access-control problem in Lovable-built apps: a security firm’s scan found Supabase-backed projects returning records without authentication, including sensitive information (earlier note, November 4). This Grok Build report is a new event, not a new finding about the same apps. Both cases put the boundary between an interface that appears usable and data that is genuinely protected in focus.
Trend signal
This is adjacent to New Runtime’s interest in agent-ready software, but does not yet establish the pattern that software exposes compact, permissioned capabilities for agents. The report concerns publication and access settings for user-built apps, rather than a general capability interface. This does not yet fit a pattern New Runtime tracks.
Why now
TeslaNorth places the report amid the expansion of Grok’s software-building tools, but does not establish that this expansion caused the access settings Claroc observed. The timing makes the practical question immediate for teams experimenting with AI-generated internal tools: before treating a working prototype as shareable software, confirm its publication mode and the permissions protecting its data.
Connections to other events
The Lovable case covered in New Runtime’s earlier note involved unauthenticated database records in some projects. Claroc’s Grok Build findings are distinct: the reported route to exposure involved published apps and their sharing or access checks. Together, the cases raise a useful review question for teams adopting different AI-building products: where is authorization enforced, and can someone verify that it blocks access to the underlying information as well as the visible app?
Why it matters
AI-generated software can shorten the path from an idea to a usable interface. That speed also means a prototype may be published before a team has treated it like a production system. Claroc’s findings, as reported by TeslaNorth, show why “there is a login screen” is not a sufficient security review: the sharing mode may still allow link-based access, or team checks may not behave as expected.
For builders, the response is not to assume that every app made with an AI tool is unsafe. It is to add a deliberate access review to the handoff from creation to sharing. Confirm who can open the app, test with an account outside the intended organization, and check that the data service rejects unauthorized requests too. Keep private or sensitive data out of an app until that boundary has been tested. These steps apply to AI-generated tools and ordinary web applications alike; the report makes the cost of skipping them especially visible in a fast-build workflow.
Limits and uncertainty
The figures and findings are Claroc’s, as relayed by TeslaNorth; this account does not independently verify the scan, the estimated 650–800 apps containing private data, or the exact scope of exposed information. It does not establish how many people accessed the apps, whether anyone obtained or misused data, or whether every reported issue has since been resolved. Claroc says the 24 SpaceXSI and X apps were taken down after disclosure, but the article gives no broader remediation count. Claroc’s paid-account publishing default and its test-app access-check finding also do not, by themselves, prove that every user or app had the same configuration.
Skill to build now
Before sharing an AI-built app, test its access boundary from a separate, unauthenticated browser session and from an account outside the intended team. Verify both the page and its underlying data requests; then select the most restrictive sharing option and repeat the test. Do not load sensitive data until unauthorized access fails in practice.
Reader takeaway
Treat publication and authorization as separate steps from building the interface. A link that works for the creator may be available to a much wider audience, and a visible login is not proof that the data behind it is protected. Test the actual boundary before putting private information into an AI-built app or sharing it with colleagues.