The Take — Grok wrote the auth check, so Grok owns it

By tomorrow this story will have been filed under "bad default." Tens of thousands of apps built with Grok, 94.7 percent readable by anyone, so flip the share setting to private and move on. I think that is the smaller half of the leak, and the half that costs nothing to say. The part that should worry a CTO is buried in the second app Claroc Research built for itself: the researcher picked the responsible-looking option — sign in with Google — and Grok wrote a membership check that could never fail.

SpaceXSI can argue about a dropdown. It cannot argue about code it generated, because the code is the product.

What the numbers actually say

Claroc tried 43,551 addresses under grok.me, where Grok's Build mode publishes what people make, according to its GhostShares 2 report. Of the 37,571 still online, 35,578 — 94.7 percent — opened for anyone in an incognito window with no sign-in; only 1,993 returned the 401 that "Only you" or "Invited users" should produce. Twenty-four of the open apps belonged to SpaceXSI and X staff. All 24 were live on Monday evening; they began disappearing within hours of Ars Technica emailing questions, Ars reported. The other roughly 35,000, built by everyone else, are still out there.

As our morning brief laid out, the haul runs from an ICU briefing with a patient's labs and ventilator status to a timesheet whose script held 18 employee accounts, admins included, with plaintext passwords. Claroc puts the count of apps with genuinely private data at 650 to 800, about two percent at high or critical severity.

Two design decisions got it there. The share dialog: on Claroc's paid test account, "Anyone with the link" was already selected. And the address: every app gets <name>.grok.me, about half of them four random words. Random words are not a secret, because the first time anyone opens the link the lookup lands in a commercial passive DNS database, and one pattern search returns the list. Claroc did not guess. It queried.

The setting works. That is the indictment.

Here is the detail that turns a disclosure argument into a design one. When Claroc switched its first test app to "Only you," the app answered 401 to a stranger on both the page and its data function. When it unpublished the second, the address went offline within seconds. Grok's platform can say no at the edge, before any generated code runs — and it does, when a human tells it to.

So the enforcement point already exists. SpaceXSI routes the decision through a dialog, then hands the actual authorisation to the model. That is the second app's failure, and it is not cosmetic. The builder asked for a customer list for a four-person sales team. Grok added Google and X sign-in buttons on its own, and wrote an app that adds whoever signs in to the team, then checks whether they are on the team. The check passes by construction. An outside Google account that had never been invited read every customer record, changed one and deleted another.

That is a security posture, not a bug. The one builder in this story who chose the careful path was still exposed, because the option labelled "sign in" was enforced by code the builder could not read and the vendor did not verify. SpaceXSI's defence — apps are private until the creator shares them, publishing takes several deliberate clicks — is true and irrelevant to that app. Grok shipped a lock that opens when you turn the handle.

And defaults decay. SpaceXSI says employee accounts start at "Only you," stricter than Lovable; it still had 24 staff apps open. Friction is not enforcement, and a default is a setting someone has to keep choosing each time the app changes — Claroc cites an enterprise with 500 AI-built apps, each rewritten by the next prompt. A default that survived zero prompts inside the company that ships the product is not a control.

The case for SpaceXSI, fairly stated

The counter-argument is stronger than most coverage admits. The headline number oversells the harm: most of those 35,578 apps are pomodoro timers and quizzes, and Claroc's own estimate of apps holding private data is under three percent. Publishing to the open web is also normal for app hosting — GitHub Pages, Netlify and a public storage bucket all serve to anyone with the URL, and nobody asks those hosts to divine which pages were meant to be private. Lovable, Bolt and Replit use the same per-app subdomain scheme, so the same DNS records expose them too, as Claroc says itself. If that is the industry norm, singling out Grok looks like singling out the company with the worst-behaved users.

Both sides are selling something: Claroc sells security tooling for AI-built apps, and SpaceXSI answered press questions after quietly taking its own 24 apps down.

The strongest version of the counter is that this is a disclosure problem, not an architecture problem: rewrite the dialog so it says "anyone on the internet can open this and edit the records inside," and most of those 35,578 would have been private. Two weeks of copy.

Why the take still holds

Because the dialog fix does not touch the second app. A builder who picked Google sign-in got a broken membership check, and better wording on a dropdown does nothing about generated authorisation code. That is the part SpaceXSI owns in a way it does not own a user's decision: it wrote the code, it presented the lock, and it never tested whether the lock closed.

Three facts make "user responsibility" untenable. The person building an ICU briefing is a clinician, not a developer; "you chose to share it" is a claim about a decision that person had no way to evaluate. The link was never private, because the address lands in DNS the first time anyone opens it, so "anyone with the link" always meant anyone. And the correct pattern already exists next door: ChatGPT-built apps start at "Only me" and carry the account name in the hostname, so a name found in DNS still resolves to an app only its owner can open, while Claude artifacts, ChatGPT share links and Gemini keep the randomness in the URL path where DNS never sees it. When your competitors' default is private and enforced above the app, "we gave users the option" is not a defence.

Look, too, at what was in the open apps: 3,784 worker medical exams at a Peruvian construction firm, a Tesla scorecard naming 22 technicians with their bonus status, the margins on roughly 4,000 vehicle-transport orders. Not embarrassing browser tabs — the operational core of businesses, published by people who thought they were sharing an app.

What would change my mind

Show me a measured sample — a hundred team apps Grok generates today, tested by a standard harness — where the membership check is correct, or where the check is enforced server-side instead of written into the generated script. That makes Claroc's ordering bug a one-off rather than a pattern, and the argument collapses to disclosure, which is where SpaceXSI wants it.

Or let a data protection authority rule that a host of user-published apps is a mere conduit, with liability entirely on the builder. I would still think the design is wrong, but I would stop calling it the vendor's obligation.

What convinces me least is that nobody measures the other six hosts and this stays a Grok story. There is a version of this that works — Google Play opened a private lane for apps that never go public last month, the same idea at the distribution layer. What the builders lack is the boring part: an access list the platform holds, a membership check the next prompt cannot rewrite, and a publish gate that refuses to ship a script containing plaintext passwords.

SpaceXSI fixed 24 apps in an afternoon. It could have fixed the class instead.

If your team builds apps with AI, do you know which ones a stranger can open right now — or would you rather not find out? Write to us via our contact page.