On November 10, the security research company Claroc published a report. Under the domain grok.me, they used common subdomain enumeration methods to find 43,601 application names, and then opened each homepage one by one, all without logging in.
43,551 addresses responded, 37,571 are still online, of which 35,578 (94.7%) can be opened without logging in. Only 1,993 (5.3%) returned HTTP 401.
On the same day, Microsoft Research released another study: by altering fewer than 10 neurons in a model that are usually almost inactive, without retraining, one can plant a backdoor in an agent built on top of it; the trigger can be as ordinary as a date, for example, when the clock passes midnight in 2027.
Two messages half a world apart point to the same thing: the boundary of the enterprise asset ledger has been stretched outward by two rings this year—one ring is the systems employees built themselves, and the other is the model files themselves.
1. The default value of the publish button is the enterprise's exposure surface
First, let's clarify the definitions. The figures in this study narrow down layer by layer, and each layer has a different meaning:
| Caliber hierarchy | Quantity | Meaning |
|---|---|---|
| Subdomain discovery | 43,601 | Common subdomain enumeration lists the application names under grok.me |
| Try to access | 43,551 | Load the homepage one by one, without logging in throughout |
| Still online | 37,571 | Has a normal response |
| Can be opened without logging in | 35,578 (94.7%) | Anyone who gets the link can view it |
| Login required | 1,993 (5.3%) | Return HTTP 401, indicating that "Only me" or "Invited users" is set |
What really matters is not the total number, but what is inside. Among the opened applications, 24 were built by employees of SpaceXSI (formerly xAI) and X themselves: a new-employee onboarding plan marked "Confidential"; a sales territory and pipeline map covering 594 strategic customers; 8 advertising proposals and media plans (one of which was sent to a U.S. federal agency and marked Confidential); 4 advertiser account dashboards (one of which was tracking a $1.6 million sales target); 7 campaign reports for Brazil, Japan, South Korea, and Thailand; and 2 brand safety manuals.
In addition to these two companies, 30 other identifiable organizations placed internal data in public applications: 26 have more than 1,000 employees, and 6 are Fortune 500 companies; 18 are in the United States, and 12 are distributed across 11 other countries. By industry, construction and real estate had the most with 7, followed by energy and utilities with 5, and the rest were scattered across technology, healthcare, transportation, travel, defense, manufacturing, and automotive finance.
Claroc's estimation approach is: about one-tenth of public apps contain sensitive materials, internal business data, or personal data, and about 2% are severe enough to be rated "high" or "critical"; after sample correction using model flags plus manual review, apps containing private data number approximately 650 to 800.
Among 37,571 online Grok apps, the proportion that can be opened without logging in (Claroc Research, 2026-11-10)
SpaceXSI's response is: employee accounts default to "self only"; publishing requires clicking publish, selecting an address, clicking publish again, choosing between "self only" and "anyone with the link", accepting the legal notice, and finally clicking publish one more time.
Claroc did not deny these steps, but rebutted another point: in the paid account they used, by the time they reached that step, "Anyone with the link" was already selected. And the strongest counterevidence lies with SpaceXSI itself—the company says employee apps are private by default, yet the 24 apps built by its own employees remained public until they were taken down after the report was issued.
A few more clicks
It’s an operational burden, not access control. The end of the path has already been set to "everyone"; those who complete every step will still be public.
Default private
It is a security policy. To make it public, it must be actively changed; whoever changes it knows what they are doing and leaves a traceable action.
II. These apps are doing real work and can't be banned
In the samples Claroc manually confirmed, several things are very concrete: a searchable activity roster for more than 3,500 employees at a hospital group; a briefing on intensive care patients, including lab tests, imaging, and ventilator status; a cruise ship kitchen inspection checklist listing crew members' names and employee IDs; a fire department duty board showing each firefighter's name, badge number, and shift duration; a driver recruitment list of more than 1,000 people at a freight company, including legal names and personal email addresses; and a contractor timesheet, with plaintext passwords for 18 accounts, including the administrator's, stored in a script file.
These are not toys. They replace exactly the functions that procurement software should have provided: sales pipelines, scheduling, rosters, inspection checklists, and time tracking. The only difference is that employees generate these in a chat window within minutes, and publish them in that same window—no installation, no approval, and without going through any IT gate.
Purchased software
Company login, role division, admins can see who has access, there is offboarding reclamation, and there is a decommissioning process. Slow, but these are its features.
AI-generated applications
A link. Whoever has the link can view it; the author is often the business owner, and after they leave, the app still exists, but no one knows it exists.
Shadow IT in the past had a natural ceiling: installing software required permissions, servers, and domain names, and IT could see it at gateways and on endpoints. Now that ceiling is gone. Generation happens in the browser, data is stored on the service provider's side, and a single link in the address bar is everything.
What is more troublesome is drift. In the author's next prompt, they add a table, a login, and a share link; an app that was harmless yesterday is holding customer records today. The example Claroc gives is: an app that stores data but requires no login—any visitor can not only view it, but also modify and delete it.
A ban is not a strategy; there are three things that can be executed.
Discovery: Perform subdomain enumeration on the company domain and the default domains of commonly used AI website-building services, viewing only homepages without logging in, to form an inventory. Defaults: New applications are private by default; those containing customer data must use company login. Exit: When the author leaves or the project ends, the application must be handed over or taken offline, rather than left there waiting to be discovered.
3. Model files are also assets, and are even harder to trace
That Microsoft Research study called Lazarus is worth reading through in full for its technical details, because it turns "models" from a kind of service into a file that must be managed as an inventory item.
- Scale of the change: fewer than 10 dormant neurons, no retraining needed, only inference-level compute — any machine that can run this model can modify its weights.
- Concealment: The model passes standard evaluations as usual, and behaves completely normally, until the trigger word appears. The trigger word can be a date, such as midnight in 2027.
- Consequence: Midway through an ordinary task, the agent outputs a command that downloads and runs the attacker's code, executing it with the permissions it has been granted.
- Prerequisite: write permission is required for the model's checkpoint. One compromised account, one pipeline, or one storage bucket is enough.
The researchers themselves wrote a sentence worth copying into any model procurement review: This is not a reason to oppose open weights. An attack only requires write access; models developed in-house by enterprises are equally exposed; what truly determines the risk is the integrity and provenance of the weights.
Detection has a hard constraint: to reliably discover modifications, one must diff it against the original unmodified weights. So "where did this file come from" is not a compliance paperwork question, but a prerequisite for whether detection is possible. Frontier agents can discover anomalous weight modifications through observation, but researchers also admit that weight scanning is currently not a routine action.
The vendor-side response is to lock down provenance: when Microsoft Foundry integrates open-weight models, it binds the model to the original publisher and scans containers separately; at the same time, it is doing weight scanning, model signing, and tamper-proof auditing. This approach is the same as the traditional software supply chain—first prove provenance, then discuss behavior.
If an enterprise cannot answer "where did this model file come from, who changed it, and when it was changed," then it is not an asset — it is an exposure.
One incidental detail: the researchers say that Claude Code figured out most of this attack on its own. The same set of tools is both helping enterprises build systems and helping attackers find openings.
IV. Add three categories of objects to the ledger and add a retirement path
Traditional software asset inventories answer only one question: what did I buy, how many copies did I buy, and when does it expire. This year, they must answer at least two more: what have my people built, and where do my models come from.
| Object | Where is it recorded now? | What to record | Responsibility Role |
|---|---|---|---|
| Applications generated by employees using AI | Usually no one remembers | Publish domain, author, data classification, access method, last active time | Business Owner + IT |
| Model files (open-source weights and fine-tuning) | Model directory or cloud drive | Source and publisher, file hash, license, fine-tuning records, deployment location | Platform / Algorithm |
| Data fed to the application | All business systems | Classification and grading, whether personal information is included, retention period, and deletion method | Data Owner |
The third line is most easily mistaken for "someone is already managing it." But shadow app data often isn't in any business system—it sits in the website builder service provider's database; the company has no backup and no deletion credentials; during offboarding handover, it cannot be handed over, nor can it be deleted cleanly.
Three actions for the CIO:
- First scan the externally reachable surface once, focusing only on the homepage. The scope includes company domains and the default domains of commonly used AI website-building services; throughout the entire process, do not log in, do not submit forms, and do not call APIs. This step does not solve any problems, but it turns "whether we have anything like this" from a guess into a checklist.
- Write private-by-default into the usage guidelines, rather than writing "prohibit use." Require selecting "only myself or invited users" before publishing; apps containing customer data, employee information, medical and financial information must use company login; when the author leaves, trigger handover or takedown. Prohibition will only push usage to more hidden places.
- When a model is entered into the ledger, three things must be recorded.For open-source weights, record the source and hash; for self-developed fine-tuning, record the training data and output hash; before each deployment, run a diff against the original weights. This also applies to every weight file downloaded from the open-source community.
The asset ledger is about "what I bought." Starting this year, it must also answer "what my people have created and where my models come from." The first question can be checked against purchase orders; the latter two can only rely on institutional rules.
Go back to those 35,578 links. They were not breached; they were built—inside each one, someone was earnestly doing their own job. What is really missing is not security awareness, but a default value that takes effect at the moment of "publishing," and a checklist that still has someone to take it over at the moment of "leaving."
Sources: Claroc Research, "GhostShares 2: Grok Apps Exposed xAI's Business Secrets and People's Private Data" (2026-11-10, including 43,601 subdomains, 43,551 attempted addresses, 37,571 online, 35,578 without login, 1,993 HTTP 401s, 24 SpaceXSI/X employee apps, distribution across 30 organizations, an estimate of 650–800 apps containing private data, and SpaceXSI's response); Microsoft Research, "Lazare, veni foras: Reprogramming Dormant Neurons to Backdoor AI Agents" (2026-11-10, including fewer than 10 dormant neurons, no training required, date-triggered, requiring only inference compute, and an explanation of weight diff and Foundry source binding); AI Soda's Chinese retelling of the two studies in "Daily AI Hotspots November 13" (2026-11-13).
Scope note: The app counts, organizational distribution, and proportion of sensitive data are all cited from the Claroc report. Its method was subdomain enumeration followed by loading each homepage individually and accessing without login, with model-based flagging plus manual review and sampling correction; these are researcher estimates rather than a full audit. SpaceXSI's "default to self only, publishing requires multiple steps" is its statement to the media, while Claroc's "paid accounts default to anyone with the link already selected" is the researchers' test result on their own accounts; the two sides' statements are presented side by side. The Lazarus attack chain and detection conditions are cited from the original Microsoft Research text; as of the original publication, the researchers said they had not found any actual exploitation cases, and this statement reflects the researchers' position.
