A security investigation has found that tens of thousands of applications created using Grok’s AI-powered app builder were accessible without a login, exposing sensitive personal information and confidential business records. The exposed material reportedly included hospital patient information, employee passwords stored in plaintext, and internal sales and advertising documents belonging to SpaceXSI and social media platform X.
The findings come from cybersecurity firm Claroc, which examined applications hosted on Grok’s grok.me domain. Its November 10 report said that 35,578 of the 37,571 active applications it tested were accessible without authentication. The investigation raises questions about the security defaults of AI-powered app builders and the risks of allowing employees to create and publish business applications without conventional IT oversight.
Nearly 95% of Tested Grok Apps Were Open Without Login
Claroc identified 43,601 potential Grok app addresses and found that 37,571 were still online when it conducted its investigation. Of those active applications, 35,578, or approximately 94.7%, opened without requiring users to sign in.
Not every publicly accessible application contained sensitive information. Many were reportedly simple tools, including calculators, games and landing pages. However, Claroc estimated that roughly one in ten open applications contained internal business or personal data.
The researchers further estimated that between 650 and 800 applications could have contained highly sensitive or critical information. This figure is an estimate based on the firm’s classification process and should not be treated as a confirmed count of individual data breaches.
The investigation identified exposures across several industries and organizations, including healthcare providers, contractors and businesses with large workforces.
| Investigation finding | Reported figure |
|---|---|
| Potential Grok app addresses identified | 43,601 |
| Applications still online | 37,571 |
| Apps accessible without login | 35,578 |
| Share accessible without authentication | 94.7% |
| Organizations with identifiable exposed data beyond SpaceXSI and X | 30 |
| SpaceXSI and X employee-created apps identified | 24 |
| Estimated apps containing highly sensitive data | 650–800 |
Patient Information and Employee Passwords Among Exposed Data
Some of the most concerning findings involved healthcare and employee information.
Claroc reported discovering an intensive care unit briefing containing a patient’s laboratory results, imaging information and ventilator status. Another exposed application contained a hospital group’s staff roster listing more than 3,500 employees.
The researchers also identified a fire department shift schedule containing employee names and badge numbers. In another case, a trucking company’s recruiting application reportedly exposed a list of more than 1,000 people, including personal email addresses.
One particularly serious discovery involved a contractor’s timesheet application. According to Claroc, its client-side code contained 18 user accounts with passwords stored in plaintext, including administrator credentials.
Plaintext passwords are a major security risk because they can be read directly from the exposed code without first being cracked. If those credentials are reused across other services, an attacker could potentially attempt to access additional systems.
The report does not establish that the exposed credentials were used by attackers or that every listed individual suffered identity theft. However, the availability of this information to unauthorized visitors creates potential risks involving account compromise, impersonation and targeted phishing.
SpaceXSI’s Own Internal Business Information Was Exposed
The investigation also found that the exposure affected applications created by employees of SpaceXSI and X.
Claroc identified 24 publicly accessible applications associated with the two organizations. These reportedly included confidential internal documents, advertising proposals and sales-related information.
One application contained an enterprise sales onboarding plan with internal system addresses, sales tools, employee information and references to 19 internal chat channels.
Another application reportedly displayed a sales territory map covering 594 strategic accounts, including information related to the company’s sales pipeline.
The researchers also found eight advertising proposals prepared for X. One proposal was reportedly marked confidential and addressed to a US federal agency. Other exposed material included advertiser account dashboards, campaign spending summaries and copies of an internal brand-safety playbook.
The findings are significant because they show that the risks were not limited to inexperienced users building small personal projects. Employees at the company behind Grok were also using the platform to create applications that contained internal business information.
Claroc said SpaceXSI removed the 24 employee-created applications after receiving its findings. However, the research firm said other exposed applications belonging to outside users and organizations had not been taken down at the time its report was published.
Why Were Grok-Built Applications Publicly Accessible?
Claroc attributed the exposure to a combination of publishing defaults, discoverable application addresses and weaknesses in AI-generated authentication logic.
Grok’s Build mode allows users to describe an application through a conversation and have the AI generate the code. Once the user publishes the project, it becomes available through an individual address hosted on the grok.me domain.
According to Claroc, the publishing interface it tested had the option labelled “Anyone with the link” selected by default. Users could choose more restrictive options, including “Only you” or access limited to invited users, but they needed to change the setting themselves.
This created a problem for users who assumed that an application created inside their account would remain private unless they deliberately configured it for public access.
The application’s individual subdomain also made it easier to discover. Claroc explained that passive DNS services collect records of domain lookups, allowing researchers and other customers of those services to identify application addresses without receiving links from their creators.
Consequently, relying on an obscure or unshared address was not sufficient protection for applications containing confidential information.
AI-Generated Login Systems Also Had Security Weaknesses
The investigation identified another issue beyond public sharing settings: applications generated by Grok could contain flawed authorization logic.
Claroc created two test applications using its own accounts and sample data. One was a contact-list application that lacked proper login controls, allowing anonymous visitors to add records.
The second application included Google and X sign-in options. However, the researchers said the generated code automatically added every authenticated visitor to the team before checking whether that person was authorized to access it.
As a result, an outside Google account could access the test application’s records and read, edit or delete information.
Claroc said it conducted write and delete tests only on applications created by its researchers, not on the applications belonging to affected organizations.
The finding highlights an important distinction between authentication and authorization. Authentication establishes who a user is, while authorization determines what that user is allowed to access. Adding a login button does not automatically make an application secure if its permission checks are incorrectly implemented.
AI-generated code can accelerate development, but it does not guarantee that security controls are correctly designed or configured.
What Did SpaceXSI Say?
SpaceXSI defended its publishing process by saying that applications remain private until their creators choose to share them. The company also said publishing involves multiple steps, including a legal notice, and that employee accounts default to the “Only you” access setting.
Claroc disputed the effectiveness of that explanation, arguing that the final publishing interface still presented “Anyone with the link” as the preselected option in its testing.
The research firm also pointed to the 24 employee-created applications it identified as evidence that internal information could become accessible despite the company’s stated employee privacy settings.
Claroc said it reported the findings to SpaceXSI on November 8 and provided additional details about employee applications the following day. It subsequently published its research and began contacting affected organizations directly.
The company had removed the 24 identified employee applications by the time of publication, according to Claroc. The status of other applications identified in the investigation remained a concern.
The Bigger Picture: AI App Builders Are Creating New Security Risks
The incident illustrates a growing challenge for organizations adopting AI-powered development tools. Employees can now build dashboards, databases, customer lists and operational applications by describing what they need in ordinary language.
That speed can improve productivity, but it also makes it easier for applications to appear outside established IT approval processes. A sales employee might create a customer dashboard, while a hospital worker could build a staff scheduling tool. If those applications store sensitive information, weak access controls can create significant security exposure.
The Grok findings also reflect wider concerns about AI-generated software. Similar security problems have been reported in applications built with other AI development platforms, including weaknesses involving database permissions and authentication.
Organizations therefore need to treat AI-generated applications like conventional software. They should maintain an inventory of applications created by employees, require private access by default, review permissions before publication and prevent passwords or sensitive credentials from being embedded in browser-accessible code.
Looking Ahead
The incident puts pressure on SpaceXSI to strengthen Grok’s application-publishing controls and improve the security of code generated through Build mode. Making private access the default, displaying clear warnings before public publication and improving automated checks for authentication and authorization weaknesses could reduce the likelihood of similar exposures.
For businesses and individuals who have used Grok to create applications, reviewing published projects and checking their access settings is an important immediate step. The broader lesson for the AI industry is that making software easier to build must also involve making it safer to publish, manage and operate.
SEO Title: Grok-Built Apps Expose Patient Data, Passwords and SpaceXSI Sales Records
Meta Description: A Claroc investigation found 35,578 Grok-built apps accessible without login, exposing patient information, plaintext passwords and confidential SpaceXSI business records.
URL Slug: grok-built-apps-expose-patient-data-passwords-spacexsi
Focus Keyphrase: Grok-built apps data exposure
Secondary Keywords: Grok security breach, SpaceXSI data exposure, Grok Build apps, AI app builder security, exposed patient data, plaintext passwords
Get the day’s top stories in your inbox
One concise email. No spam, unsubscribe anytime.
