Grok-built apps leak company secrets, including from Musk's own firm

What happened

On November 10, 2026, security firm Claroc published an investigation called "GhostShares." It looks at Build mode in Grok, the AI chatbot from SpaceXSI. That's the company's name since SpaceX merged with Elon Musk's AI company xAI. In Build mode, you describe in the chat what kind of app you want. Grok turns that into a working web application, and you can publish it from the same chat window. This is known as "vibe coding": software built from plain-language instructions, without writing any code yourself.

Claroc tracked down tens of thousands of these published apps. The vast majority opened without any login at all. Some of them held confidential business data, personnel records and even health data. SpaceXSI itself was among those affected: employees of SpaceXSI and X had built 24 of the open apps.

How Build mode came about

SpaceXSI introduced Build mode as an early beta in July 2026. According to androidheadlines.com, it was first available only to SuperGrok Heavy subscribers on grok.com and in the iOS and Android apps. Grok shows a working preview right in the chat, and you can tweak layout, features and logic with text prompts. You can build websites, calculators, task planners, games and live dashboards that pull real data through connectors. Finished projects can be published under a grok.me address or a custom domain. This puts Grok up against tools like Google AI Studio, Anthropic's Claude Artifacts and OpenAI's ChatGPT Codex. Its main selling point is that there's nothing to install or set up.

How the researchers found the apps

The core of the problem is how addresses are assigned. Every published app gets its own hostname following the pattern name.grok.me. When you visit one of these addresses, your browser triggers a DNS lookup. DNS is the internet's "phone book": it translates names into server addresses. Passive DNS databases collect these lookups and make them searchable. So even addresses made of four random words end up in these directories sooner or later, as soon as someone uses them.

According to Ars Technica, Grok does try to randomize the addresses so that only people who were given the link know them. But this design choice completely defeats that protection. If the random identifier sat in the URL path, after the slash, it wouldn't be exposed through DNS. Claroc notes, though, that search engines and link scanners could still leak it.

Using standard subdomain enumeration methods, Claroc found 43,601 names under grok.me. Of those, 37,571 apps were still online at the time of testing. For each one, the researchers loaded only the first page, once, without logging in, and analyzed saved copies offline. The results:

Most of the open apps were harmless: games, landing pages, calculators. To find the sensitive cases, Claroc had an AI model flag suspicious pages, checked the hits by hand and validated the model against a random sample.

What was in the open apps

Among the apps from SpaceXSI and X employees, Claroc found:

• an onboarding plan marked confidential for a new member of the enterprise sales team,
• a sales territory map with 594 strategic customer accounts, including the sales pipeline,
• eight advertising proposals, media plans and pitch decks from X, one of them addressed to a US federal agency and marked confidential,
• an overview of advertising clients tracking progress toward a $1.6 million sales target.

According to Ars Technica, internal system addresses of sales tools were also visible. Claroc wrote:

"We were shocked. The company that makes Grok had its own internal material open to anyone with the link – and nobody ever gave us that link. If the sales team had bought a tool for this, it would sit behind the company login, accessible only to the team. Built with AI, it went online open to anyone with the link."

On top of that came internal data from 30 other organizations. 26 of them have more than 1,000 employees, and six are Fortune 500 companies. Among the cases Claroc confirmed by hand:

• a searchable directory of more than 3,500 employees of a hospital group,
• an intensive care unit briefing with a patient's lab results, imaging and ventilation status,
• a live shift board from a fire department with firefighters' names and badge numbers,
• a contractor's timesheet app with 18 user accounts and their passwords in plaintext, including admin accounts. The passwords sat in the script code that every browser downloads when it loads the page.

Ars Technica also cites medical test results and galley checklists from a cruise line as further examples.

The tests: when AI-generated login code fails

To check write access and permissions, Claroc built two apps of its own using made-up data. In the paid account, nothing went public until you clicked "Publish." But in the sharing dialog that followed, "Anyone with the link" was preselected. You had to pick the alternatives, "Invited users" and "Only you," yourself.

Test 1: a contact list with a database and no login. An entry the researchers added from a logged-out incognito window was visible to the next visitor. So strangers could not only read data but write it too.

Test 2: a customer list for a four-person sales team. Grok added sign-in buttons for Google and X. But the generated code first registered everyone who signed in as a team member and only then checked membership. That check always passed. An uninvited Google account could see every customer, edit one entry and delete another. In security terms: authentication (who are you?) worked, authorization (are you allowed to do this?) didn't.

Claroc stresses that it demonstrated these write and permission flaws only on its own apps. It didn't log into anyone else's apps, submit forms or change anything. The built-in protections worked when switched on: with "Only you," an outsider got an HTTP 401 error ("unauthorized") for both the page and the data function. After unpublishing, the second app went offline within seconds.

Disclosure and SpaceXSI's response

Claroc reported the onboarding plan and one advertising proposal to SpaceXSI on November 8, 2026, along with its figures, the two test apps and four suggested fixes. The remaining employee apps followed on November 9. According to Ars Technica, there was no response. A Claroc representative then publicly tagged Elon Musk and Grok manager Matt Palmer on X. On Monday evening, all 24 apps were still reachable. Only a few hours after a press inquiry from Ars Technica did SpaceXSI take them down. They now show "app not found." Open apps from other users stayed online.

SpaceXSI told the press that apps stay private until their creators share them, that publishing takes several steps, and that employee accounts default to "Only you." Claroc counters that "Anyone with the link" was preselected in a regular paid account. And despite that supposed default, the employees' apps were public.

Claroc proposes four changes:

1. Shared apps on hard-to-guess paths under a single host instead of separate subdomains,
2. Sharing that can be restricted to an organization's domain,
3. "Only you" as the default, plus a clear display of who can open the app before publishing,
4. Warnings for apps that have a database but no login, and an automatically created invite list whenever the prompt mentions a team.

Because SpaceXSI didn't commit to notifying affected app owners, Claroc is contacting them itself. By publication, three organizations had received an email. The report doesn't name hostnames, app titles or links. Claroc plans to delete the saved copies once everyone affected has been notified.

Analysis

This case shows a typical weakness of vibe coding. If you have an app built through a chat, you often don't know where the data lives or who can see it. Many people never consider that a "secret" link isn't access control. But the responsibility doesn't lie with users alone. Two platform decisions made the problem much worse: public sharing as the default, and a separate subdomain for every app, which lets anyone list the apps en masse. There's also a more fundamental issue. The test shows that AI-generated security code can look plausible and still fail to protect anything. A login on its own doesn't keep strangers out.

For SpaceXSI, the case is embarrassing because its own employees were affected, and the company only acted once the press started asking questions. It remains to be seen whether SpaceXSI will change its defaults and address structure, and whether the other affected parties will learn that their data was exposed. The figures for apps with private data are Claroc's estimate, so the full scale hasn't been independently confirmed, though the examples were verified by hand. If you use Grok Build or similar tools, check the sharing settings of your published apps, set any app with sensitive data to "Only you" or "Invited users," and change any exposed passwords immediately.