# Grok app exposure reported

> Sharing and permissions require separate checks.

By BIGCHANGE.AI Editorial

Published: 2026-11-13T16:44:38.137Z
Updated: 2026-11-13T16:44:38.137Z
Canonical: https://bigchange.ai/blog/grok-built-apps-sharing-exposure-research

![Illustration of a person checking a sign-in screen.](https://bigchange.ai/api/media/file/sharing-v2.png)
AI-generated illustration for BIG CHANGE.

[Claroc's November 10 report](https://blog.claroc.io/ghostshares-grok-build-apps/) says 35,578 of 37,571 live Grok-built apps it discovered opened without signing in.

## The big change

- Claroc's count concerns discovered apps, not all Grok apps or sensitive records. It inspected first pages; write tests used only two apps it created with fictional data.
- A hostname can become discoverable through historical DNS records. A difficult-to-guess address therefore should not substitute for deciding who may access a resource.
- Authentication establishes identity; authorization determines permitted actions. A sign-in screen alone does not establish that someone belongs to the team whose records they are requesting.

## What the report establishes

Claroc describes passive-DNS discovery and some exposed personal/business information. It sells app-security services. In its team-list test, generated code enrolled whoever signed in before checking membership, allowing an uninvited account to change records.

According to Claroc, the provider told a reporter publishing requires deliberate steps and employee accounts default to owner-only. Claroc agrees publication is deliberate but found link access preselected in its account. It reports 24 staff apps removed, without establishing a general fix.

## Why finding an address is different from permission

The Internet Engineering Task Force's [DNS terminology](https://www.rfc-editor.org/rfc/rfc9499.html) explains passive DNS as storing responses from name servers. Some systems also collect queries, raising privacy concerns. Historical databases can answer when a name appeared and which records it had; they can also support searches using properties other than the name itself.

This describes a way to discover names, not a way to defeat an application's access checks. A historical record also does not, by itself, establish what information a website currently serves. Discovery and access need separate evidence. The terminology explains the mechanism; it does not independently verify this survey.

## Check actions as well as identity

[OWASP's authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) supplies a useful comparison: regular users and administrators may both authenticate successfully while legitimately having different permissions. It recommends denying access by default and validating permissions on every request. Checking most requests is insufficient because a missed check can expose a protected resource.

For a team application, translate that principle into an explicit list of users, resources and permitted operations. Reading a record and editing it are separate decisions. OWASP recommends tests against those intended permissions and periodic review after deployment, when privileges can gradually expand.

These are general engineering controls, not evidence that a particular generated app implements them.

## Sources

- [Claroc GhostShares 2](https://blog.claroc.io/ghostshares-grok-build-apps/) — Research and reported response.
- [OWASP authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) — Authorization principles.
- [RFC 9499](https://www.rfc-editor.org/rfc/rfc9499.html) — DNS terminology.