Grok Build Apps Exposed Confidential Data Through Default Sharing Settings
Researchers say thousands of apps built with SpaceXSI's Grok Build were publicly reachable because of insecure default sharing settings, and the company has fixed the issue.
According to TechRadar, Grok Build, an AI-powered coding agent built by SpaceXSI, has been found leaking a large amount of confidential information. The outlet attributes the problem to an apparent misconfiguration in how apps are published on the platform, which lets users create web applications with the tool.
TechRadar reports that researchers found Grok Build apps were widely exposed because of insecure default sharing settings and URLs that could be discovered by people who looked for them. The outlet says thousands of accessible apps contained sensitive business data, healthcare records, passwords and internal documents.
Ars Technica reports that a single researcher found 35,000 Grok Build apps that were open to anyone who looked for them. According to that outlet, some of the exposed material belonged to SpaceXSI itself.
TechRadar says SpaceXSI fixed the issue after it was disclosed. The reports do not say how long the apps were accessible, how many people viewed or copied the data, or whether any affected organizations have been notified.
The two accounts differ in emphasis. One focuses on the kinds of information at risk, while the other focuses on the sheer number of exposed apps.
Background
SpaceXSI was formed when SpaceX and xAI merged, according to TechRadar, and Grok Build is one of its products. The tool belongs to a growing category of AI coding agents, which let people describe an application in plain language and then generate code, host it and share it with others. Supporters say these tools open software creation to people without formal programming training. Critics note that the speed of generation can outpace the careful review that software normally receives.
A recurring problem in cloud computing is the gap between a setting that is convenient and one that is safe. Many platforms offer a link-sharing option that makes a resource accessible to anyone with the address, sometimes without a password. Such links are often described as unlisted, but that label is not a security control. If an address can be guessed, indexed by a search engine or found in a public source, it is effectively public. Security teams have spent years warning about exposed storage buckets and databases, many of which leaked data because they were left open by default rather than because attackers broke in.
The stakes rise when the data involves health records or login credentials. In many jurisdictions, including the United States, medical information is subject to strict handling rules, and exposure can trigger notification duties and legal consequences. Passwords expose not only the app that stored them but often other accounts where people reuse them. When an AI tool generates applications for users who may not understand deployment settings, the default configuration carries much of the responsibility for protecting the people whose information flows through it.
Why it matters
The episode goes beyond one company's product. AI tools promise to let anyone build and publish software quickly, and that promise depends on users trusting that the default settings will protect them. When an app built with a few prompts holds real business records or patient information, the person who clicked publish may not have known the data was reachable at all.
For businesses evaluating AI coding tools, the lesson is practical. Adopting such a platform means reviewing its sharing defaults, its access controls and its audit logs before building anything sensitive on it. For individuals, the episode is a reminder not to paste passwords or personal records into experimental apps, however polished the interface looks.
The story also raises a broader question about accountability. The company says it fixed the issue, but the platform designer, the user who published the app and the person who entered the data each played a role. Clear answers about who is responsible for secure defaults will shape how the next generation of AI-built software is regulated and trusted.
What to watch
Watch whether SpaceXSI publishes a fuller account of what went wrong, how long the exposure lasted and whether it found evidence that anyone other than the researcher accessed the data. Independent confirmation of the 35,000 figure would also help clarify the scale.
Pay attention to whether affected organizations and individuals are notified, particularly where healthcare records or passwords were involved. Also watch whether other AI app platforms audit their own sharing defaults, and whether any regulators or industry groups ask questions about how these tools handle sensitive data.
Viewpoints
Commentary from our columns: three angles on this story.
The Skeptic open questions and weak points
The most useful questions in this story are the ones the reports leave open. The company says the problem is fixed, but a fix is not the same as an accounting. We do not yet know how long these apps were reachable, whether logs show anyone else looking at them, or how many of the thousands of exposed records contained information that could be misused. Those gaps matter because the people whose data sat behind those links deserve to know what happened to it, not only that the door has been closed.
There is also a question about why a sharing setting that makes sensitive apps discoverable was the default at all. Convenience may explain it, but convenience is a choice, and it was made on behalf of users who may not have known the tradeoff. Before we accept that this was a one-time misconfiguration, it would be fair to ask how many other settings work the same way and who checked them before launch. Healthy skepticism here does not mean assuming bad intent. It means refusing to take a reassuring summary at face value until the details arrive.
The Builder the engineer's view
From an engineer's seat, the lesson is simple and uncomfortable: an unlisted link is not access control. Any system that generates applications and publishes them should default to private, require explicit authentication for anything that holds personal data, and make public sharing a deliberate step with clear warnings. Discoverable URLs are a design flaw, not a user error, because users cannot be expected to know which hidden parts of a platform are visible to strangers.
Teams building with generated code should also add guardrails of their own. Scanning for hardcoded passwords and exposed secrets before deployment catches a lot of trouble early. Access tests that try to reach an app while logged out can reveal exposure in minutes. Generated code also needs review, because a model can produce working software that quietly skips the protections a human would have added. The tools are getting faster at building things. The discipline that keeps those things safe has to keep pace, and right now it appears to be lagging.
The Rulebook privacy, safety and regulation
When health records and passwords appear in the same story, the regulatory questions multiply quickly. Who counts as the responsible party: the company that built the platform, the person who published the app, or the organization whose staff entered the data? Different legal frameworks answer that differently, and an AI coding platform sits in an unsettled space between a software vendor and a hosting provider. The answer will shape who must notify people, who faces penalties and what evidence regulators will expect.
Privacy also depends on what people reasonably understood when they used the tool. If the sharing setting was not clear, consent to public exposure was never really given. Good rules would require platforms to make visibility obvious, to default sensitive categories to private and to tell affected users promptly when something goes wrong. Those duties are easier to write than to enforce, but this episode shows why they matter. People who trusted a tool to hold their information deserve more than a quiet patch and a press statement.