Grok Build Shipped a Public Default, and Every Builder Should Read the Publish Screen

A security firm spent a few days opening links to apps that people built with Grok Build. It did not have to guess passwords. Of 37,571 live apps it tested, 35,578 opened to anyone with the link, no sign in required (the deep dive, Unite.AI). Inside were a hospital roster of more than 3,500 employees, an intensive care briefing with one patient's labs and ventilator status, a fire department shift board, and a contractor timesheet holding 18 employee account records with plaintext passwords, including admin accounts.

Image: xAI, via Grok Build on web and mobile

Every headline about this story will say security breach. The more useful sentence is that a publish screen shipped with the wrong default.

What actually happened

Claroc, the security firm behind the report, did not break into anything. It enumerated names under grok.me, opened the first page of each app from the public internet, and saved copies to review offline. Published apps get their own address, and because the random part of that address sits in the subdomain, ordinary DNS lookups expose it to passive DNS services that anyone can search.

Claroc found 43,601 distinct grok.me hostnames using common subdomain discovery. Of the apps still live when it tested, 94.7 percent opened without authentication. Only 1,993 returned a 401, which are the ones set to "Only you" or "Invited users."

It also built two test apps to see what the default experience does. In a contact list with no login, a stranger in a signed out window added an entry the next visitor could see. In a customer list meant for a four person sales team, an uninvited Google account signed in, read, changed, and deleted records, because the generated code enrolled whoever signed in before it checked team membership. Claroc tested only its own apps, so it cannot say whether any exposed app allowed edits.

SpaceXSI, formerly xAI, told a reporter that apps stay private until a creator shares them and that employee accounts default to "Only you." Yet 24 of its own staff apps were open, including an enterprise sales onboarding plan, a territory map covering 594 accounts, and X advertising proposals. Those came down within hours of reporters asking. Most other exposed apps stayed online.

The sharpest detail comes from the comparison Claroc drew itself: ChatGPT's builder kept new apps set to "Only me" until the researcher changed the setting. Cursor says apps stay private until their creator shares them. One defaults closed, the other defaulted to "Anyone with the link" and expected a non technical creator to notice.

The design angle nobody is covering

This is a permissions design failure, not a hacker story. And permissions design is design work.

Read the publish flow as an interface. Someone describes an app in a chat window and gets something working. They are proud of it. They hit Publish. At that moment they get a choice: anyone with the link, invited users, or only me. Two of those three choices require the creator to understand sharing models, invite lists, and who is in their organization. The third requires nothing.

Whichever option is preselected is the product's actual policy, no matter what the settings documentation says. That is the whole lesson, and it applies to every builder shipping a share button this year.

There is a second design failure stacked on top: the address scheme. Grok puts the random words in front of the domain, so the identifier leaks through DNS the moment anyone opens the app. Google puts the random string in the path, where DNS never sees it. Two products, two lines of configuration, wildly different exposure. Nobody in that standup thought they were making a security decision, but they were.

A third one is quieter. Claroc's write test failed because generated auth code checked whether a visitor was signed in, not whether they belonged. An app can look finished, pass a visual review, and still be missing the sentence that says who is allowed in.

My position

I am not going to pretend this is a Grok-specific sin, and I am not going to enjoy it. Lovable and Replit also publish each app at its own address. Every AI builder that turns a prompt into a deployed app in one sitting has the same temptation, which is to remove every step between an excited creator and a live link.

But that is exactly why the default has to carry the weight. The people using these tools in 2026 include a nurse practitioner building an internal tracker, a marketing coordinator building a client portal, and a founder testing a directory of leads. None of them are thinking about passive DNS. It is not their job. It is ours.

Shipping "Anyone with the link" as the preselected option is a design decision that quietly outsources security review to the least qualified person in the room. Preselecting "Only you" costs a creator one extra click and saves an industry a news cycle.

What I would do if I ran this launch

1. Default to private and make the public option the one you have to reach for.
2. Show the blast radius before publish. One line is enough: "Anyone with this link can open this app. It reads from a database with 340 records." If the app has a database and no sign in, say so plainly.
3. Put the identifier in the path, never the subdomain. You lose nothing and DNS stops leaking your app list.
4. Generate the invite list when a prompt describes a team. If someone asks for a tool "for my team," the model knows there are team members. Build the list.
5. Test the permission logic in the preview. A green checkmark for "sign in works" is not the same as "only the right people get in."

What designers and builders should do this week

Open every app, prototype, and staging link you have shipped in the last six months and check three things: does it load without a login, does it read from a database, does anyone actually verify who you are. That is a twenty minute audit and it will find something.

If you are designing a share flow right now, borrow the pattern that works: one clear sentence about who can open this, a preview of the link as a stranger would see it, and a default that fails closed. Same rule that has applied to seat belts, fire doors, and every form you have ever designed: the safe path has to be the easy path.

If you want a builder that treats deployment as part of the product rather than an afterthought, Base44 remains my first recommendation for designers, because the publishing step is a deliberate step, not a reflex. Whichever tool you use, the audit above is yours to run.

The takeaway

An app being easy to ship and easy to find should never be the same setting. Grok Build learned that in the most public way available. Every builder, and every designer working on one, gets to learn it cheaper. Ask who your default protects, and if the answer is anyone with the link, you have not finished designing the flow yet.