Grok Build Data Leak: 35,578 Open Apps Exposed Through Passive DNS

On November 8, 2026, researchers at the security firm Claroc started with a list of 43,601 web addresses under the grok.me domain. Nobody leaked the list to them, and they breached no server. They pulled the hostnames from public passive DNS databases and opened the front page of each live application once, from an unauthenticated browser session, the way any stranger in an incognito window would.

One address contained a new employee’s name and ended in “onboarding plan.” The page rendered without asking for credentials. It was an internal Launchpad document for a new member of the enterprise sales team at SpaceXSI, the company formed by the merger of SpaceX and xAI, which develops and operates Grok. It listed the employee’s first-week system access checklist (Okta, Slack, Gmail, HubSpot, Gong, RevSpace, Granola, Sales Navigator, an internal Grok workspace, Grok itself and Cursor), along with internal tool addresses, 19 internal Slack channels, a directory of colleagues to meet and a 30-day execution schedule.

By the time Asaf Aprozper, Claroc’s co-founder and CTO, and his team finished reviewing offline copies of the pages that loaded, they had found 24 open applications built by SpaceXSI and X staff. Those sat next to thousands of exposed apps built by outside enterprise users. The contents ranged from intensive-care patient briefings and Peruvian construction worker medical exams to defense contractor rosters and a corporate timesheet that shipped 18 employee passwords, administrators included, in plaintext inside a client-side JavaScript bundle.

Claroc’s “GhostShares 2” disclosure is worth studying as an architecture problem, because nobody exploited a software vulnerability in the traditional sense. There was no buffer overflow, no SQL injection and no broken cryptographic primitive. Three design decisions collided: a capability token placed in a DNS hostname label, where global resolution infrastructure is built to log it; “Anyone with the link” preselected in the publishing flow; and a language model (Grok 4.7 in Beta Build mode) that confuses authentication with authorization when it generates application code.

Key findings from the Grok Build exposure

• Claroc probed 43,551 grok.me addresses and found 37,571 live apps. Of those, 35,578 (94.7%) opened without any login.
• Claroc confirmed 24 open internal apps built by SpaceXSI and X employees, and sensitive data from 30 outside organizations in open apps.
• In the paid account Claroc tested, the publish dialog had “Anyone with the link” preselected.
• In Claroc’s tests, Grok-generated login screens let any stranger with a Google account read, edit and delete records.

How passive DNS exposes secrets hidden in subdomains

To see why a secret in a subdomain fails, look at what Grok Build was trying to do. A developer or business user describes an app in Grok’s chat and clicks Publish. The platform provisions the app on its own subdomain under grok.me. To keep outsiders from guessing the address, Grok generates hyphenated “dice word” hostnames built from random English words, such as cinder-crane-sand-frost.grok.me. Users can edit the string before publishing.

Access-control literature calls this capability-based security, or more casually an unguessable link. The URL is the bearer token: whoever holds the link gets access, and security rests on the infeasibility of guessing it. On combinatorics alone, Grok’s generator is sound. A standard EFF diceware list has 6^5 = 7,776 words, so each random word adds about 12.92 bits of entropy (log2 of 7,776). Three words give roughly 38.77 bits, over 470 billion combinations. The four-word phrases Claroc saw on about half of the deployed apps carry 51.7 bits, around 3.66 × 10^15 combinations. Even against 43,601 existing subdomains, an attacker sending 1,000 random DNS queries per second would need about 2.7 years on average to hit a single valid four-word hostname.

Entropy was never the problem. Observability was. A URL is not handled as one string across the network stack; its parts travel through different protocols at different layers. When the token sits in the path, as in docs.google.com/document/d/<id>/edit or the share links used by Claude (claude.ai/public/artifacts/<id>), ChatGPT (chatgpt.com/share/<id>) and Gemini (gemini.google.com/share/<id>), the network resolves only the base domain. The stub resolver asks a recursive resolver for the A or AAAA record of docs.google.com. The browser then opens a TCP or QUIC connection, completes a TLS 1.3 handshake, and only inside the encrypted tunnel sends the GET request containing the path. Nothing between the client and the terminating reverse proxy sees the secret.

Moving the token to the left, into the hostname label, pushes it out of the encrypted HTTP layer and into the unencrypted, globally distributed DNS hierarchy. When the creator of cinder-crane-sand-frost.grok.me opens the app, or a colleague clicks the link, the client has to resolve that exact fully qualified domain name (FQDN) before any TLS or HTTP traffic can flow. DNS-over-HTTPS and DNS-over-TLS protect only the hop to the recursive resolver. On a cache miss, the recursive resolver still queries the authoritative name servers for grok.me in cleartext over port 53. Even with query name minimisation (RFC 9156), where the resolver sends each server only the labels it needs, the full name has to reach the recursive resolver and the authoritative servers for grok.me.

That recursive-to-authoritative link is where passive DNS (pDNS) collection happens. Security vendors and network intelligence providers run sensor arrays above recursive resolvers, through ISP partnerships, public resolvers and corporate DNS forwarders, and tap cache-miss traffic in real time. When a hostname resolves for the first time, the sensor records the query name, record type, response data and first-seen and last-seen timestamps in a commercial historical database. An analyst with access doesn’t guess dice words. One wildcard search for *.grok.me returns a downloadable inventory of every subdomain resolved across the monitored internet.

Three other side channels leak subdomain secrets even if an organization ignores passive DNS:

• Unless Encrypted Client Hello (ECH) is deployed on both the hosting edge and every visiting client, the browser sends the full hostname in cleartext in the TLS Server Name Indication (SNI) extension. Any passive network tap, corporate firewall or ISP on the path can read it.
• If the platform issues a TLS certificate for each subdomain instead of one *.grok.me wildcard, certificate authorities must publish every certificate to public, append-only Certificate Transparency (CT) logs before browsers will trust it. That turns crt.sh into an enumeration directory.
• Browsers default to a Referrer-Policy of strict-origin-when-cross-origin. When an app loads an external Google Font, CDN script or analytics pixel over HTTPS, the browser strips the path from the Referer header and sends only the origin. A secret in the path gets stripped. A secret in the subdomain is the origin (https://cinder-crane-sand-frost.grok.me), so the browser hands it to every third-party server the page contacts.

Why AI app builders use subdomains: the Same-Origin Policy

Given how much subdomains leak, why did SpaceXSI, Lovable, Replit, Bolt, v0, Base44, Google AI Studio and Meta’s Muse all put published apps on individual hostnames, when ChatGPT, Claude and Gemini keep shared conversations safe in URL paths? The reason is the browser’s basic security boundary, the Same-Origin Policy (SOP), defined in RFC 6454 as the tuple of scheme, host and port.

The URL path is not part of a web origin. If a platform hosts two user-built apps on one hostname under different paths, such as grok.me/apps/tenant-a and grok.me/apps/tenant-b, the browser treats both as the same security principal (https://grok.me:443). Vibe-coded apps run arbitrary, model-generated JavaScript in the visitor’s browser, so putting several tenants on one hostname destroys isolation between them:

• Script on /apps/tenant-a can read and overwrite the localStorage, sessionStorage and IndexedDB data created by /apps/tenant-b, because Web Storage is scoped by origin and ignores paths.
• Cookies support a Path attribute, but browsers don’t treat Path as a security boundary. Because both apps share an origin, tenant-a can inject a hidden iframe pointing at tenant-b, reach into it through iframe.contentWindow.document, and read document.cookie or change the DOM. Even with HttpOnly cookies, tenant-a can send authenticated fetch() requests to tenant-b’s backend endpoints.
• One cross-site scripting flaw, or one malicious prompt, in a path-hosted app compromises every other app on that domain, including through service worker hijacking.

Static transcripts on chatgpt.com/share/<id> or gemini.google.com/share/<id> can use path routing because nobody runs untrusted application logic there. The browser only runs the vendor’s own audited frontend to render inert Markdown. Claude’s published artifacts also live at paths (claude.ai/public/artifacts/<id>), but their interactive code runs in restricted cross-origin sandboxed iframes, such as claudeusercontent.com or sandbox="allow-scripts" without allow-same-origin, which gives the frame a unique opaque origin (null).

A platform that wants to give users full web apps with working localStorage, OAuth redirects and standard browser APIs needs a distinct origin for every tenant, which means a distinct hostname. Grok Build’s mistake was to make the hostname do two jobs. It was the tenant’s origin and also the unguessable share secret. The mechanism that provides browser isolation, the DNS hostname, ended up destroying the confidentiality of the access token.

A sturdier design keeps the two apart. Give each app a deterministic or non-secret subdomain, such as app-8f92a1c4.grok.me, purely for origin isolation. Then require either an authenticated session at the edge proxy or a high-entropy capability token in the path or fragment (for example app-8f92a1c4.grok.me/s/7K9mP2xQ8vL4nR1wZ5yB3cF6jH0dG...), served with a <meta name="referrer" content="no-referrer"> tag and X-Robots-Tag: noindex, nofollow headers. Passive DNS then sees only app-8f92a1c4.grok.me, and a scanner that requests the root path gets an HTTP 401 or 403 before any application code or data is served.

The noindex header matters in practice. Claroc pointed out that a path secret stays out of DNS but can still reach search engines if crawlers are allowed to index the page. In August 2025, more than 370,000 shared Grok conversations at grok.com/share/ paths showed up in public Google search results because the pages lacked proper crawler exclusions.

Grok Build exposure by the numbers

Claroc designed its method to verify exposure without unauthorized interaction. After assembling 43,601 grok.me hostnames through subdomain discovery, the team tried to load the root page of 43,551 addresses once from the public internet, with no cookies or credentials attached.

Of those 43,551 addresses, 5,980 were offline or no longer resolved to a live app, which left 37,571 live apps. Of those, 35,578 (94.7%) returned HTTP 200 and opened immediately for anyone. Only 1,993 (5.3%) returned HTTP 401, the code Grok serves when an app is restricted to “Only you” or “Invited users.” Measured against all 43,551 attempted addresses, 81.7% opened without authentication.

Claroc did all analysis offline, on the saved first page loads. It used an AI classification model to triage the 35,578 saved pages for signs of private or internal records. Human analysts read the flagged pages and calibrated the model against a manually reviewed random sample. The calibration put the number of apps exposing private data at roughly 650 to 800. About 2% of the open apps, around 712, held records severe enough to rate as high or critical risk.

Inside SpaceXSI’s own 24 exposed internal apps

The sharpest irony turned up inside the vendor’s own house. Claroc manually confirmed 24 publicly accessible apps built by SpaceXSI and X employees that required no sign-in:

• The SpaceXSI Launchpad onboarding portal for a named new enterprise sales hire, marked confidential. It included the 30-day schedule, the colleague list, internal URLs, 19 internal chat channels and the system provisioning checklist described above.
• An internal Grok Enterprise Sales territory mapper for the North Central region. It showed live counters for 594 strategic accounts across 6 territory patches, flagged 154 accounts as “hot pipeline” and 104 as “CX high,” and included territory scorecards and a full table of account names, cities, priorities and scoring metrics.
• Eight X advertising proposals, media plans and pitch decks with detailed budget tiers. One confidential proposal was prepared for a U.S. federal agency and broke down recommended media mixes across UFC, college football, always-on video and state takeovers, plus an expansion tier covering the NFL and NHL.
• Four live advertiser account boards tracking active campaign spend, including one that tracked real-time progress toward a $1.6 million sales target, and seven confidential or internal-use campaign performance reports for advertisers in Brazil, Japan, South Korea and Thailand.
• Two copies of an internal X brand-safety sales hub playbook and an internal staff contest page listing employees by full name.

Claroc found only one more SpaceXSI or X app, an archive of ad measurement studies for a streaming service, and that one did prompt for a password.

Which organizations were affected

Beyond SpaceXSI and X, Claroc identified 30 distinct outside organizations from the internal data sitting in open Grok Build apps. Twenty-six of them employ more than 1,000 people, and six are in the Fortune 500. Eighteen are headquartered in the United States, and the other 12 are spread across 11 other countries. By sector, the 30 break down as construction and real estate (7), energy and utilities (5), technology and IT (4), healthcare and medical devices (3), transport and automotive (3), travel, hospitality and food service (3), defense (2), manufacturing and advertising (2), and auto finance (1).

The confirmed exposures read like a cross-section of shadow IT slipping past corporate governance.

Healthcare and occupational medicine

A single-patient intensive care unit briefing showed lab results, diagnostic imaging and ventilator status. A healthcare group’s hospital staff event app held a searchable roster of roughly 3,565 employees with full names and employee IDs. A Peruvian construction company’s occupational-health dashboard exposed 3,784 worker medical exams.

Defense, aerospace and emergency services

A U.S. Navy ship engineering contractor’s roster named 108 personnel assigned to a Navy logistics support contract. A Norwegian-Finnish aerospace and defense group’s app held a load board and loading procedure for an explosives building at a U.S. plant, next to its Health, Safety and Environment (HSE) training matrix. A municipal fire department’s live shift board showed each firefighter’s full name, badge number and active duty hours.

Automotive, logistics and hospitality

A Tesla service-center scorecard named 22 technicians with their productivity metrics and bonus eligibility. An auto transport company’s quote desk held roughly 4,000 vehicle-transport orders with pricing and profit margins. A trucking firm’s recruiting roster listed over 1,000 driver candidates with legal names and personal email addresses. A galley inspection checklist for a luxury celebrity cruise line listed crew members by full name and employee ID.

IT, telecom and real estate

A U.S. data center colocation and hosting provider’s confidential IP transit proposal to a European telecom carrier was open to anyone. So was a U.S. IT services provider’s confidential proposal to a major retail client, complete with a full hardware bill of materials (BOM). A U.S. homebuilder’s sales callsheet listed roughly 583 home-buyer prospects with their budgets and financing notes, and a Malaysian holding company’s project monitor tracked 37 real estate developments with internal sales and profit figures.

Public by default: the Grok Build publishing dispute

Why were 94.7% of live grok.me apps open to the world? The answer is in the friction, or lack of it, at the moment of deployment.

When Ars Technica asked before publication, a representative from Cursor, the AI coding platform SpaceXSI recently acquired, said by email that Grok Build apps are “private by default” and nothing goes public unless the creator chooses to share it. SpaceXSI added that publishing takes several steps: the user clicks Publish, selects an address, clicks Publish a second time, chooses an access level, accepts a legal disclaimer and clicks Publish a final time. It also said its own employee accounts default to “Only you,” so a staff member would have to switch the radio button to “Anyone with the link” to expose an internal app.

Claroc’s testing shows how those steps behave in practice. Building an app works on Grok’s free tier, and publishing needs a paid subscription. Both sides agree that an unshared draft in the chat window stays private until the user starts the Publish flow. The trouble is in the access dialog. In the paid account Claroc tested, it offered three options, Anyone with the link, Invited users and Only you, with Anyone with the link preselected.

Three confirmation clicks and a legal disclaimer don’t protect data when the preselected radio button grants public read access. Every builder behind the 35,578 open apps went through that sequence. SpaceXSI’s claim about its own employees doesn’t fit the evidence either. If staff accounts really defaulted to Only you, then up to two dozen SpaceXSI and X employees building sales territory mappers, federal ad proposals and onboarding portals overrode a private default to make their tools public. Either the internal default wasn’t applied uniformly, or people confuse “Anyone with the link” with “anyone inside my company who has the link.”

ChatGPT has the same subdomain-per-app problem. When it publishes an app, it assigns a two-level hostname in the form <app-name>.<username>.chatgpt.site. As with grok.me, the hostname enters passive DNS the moment the owner opens the URL, and a *.chatgpt.site query finds it. But in Claroc’s test of ChatGPT’s publish flow, access defaulted to Only me. Passive DNS enumeration against chatgpt.site therefore returns hostnames that give a 401 or 403 to everyone except the creator. When network discovery is unavoidable, the default access setting is the only control standing between private records and a breach.

When login is not authorization: broken access control in Grok-generated code

The fact that the apps were readable from outside raised a worse question. Could an unauthenticated visitor, or any stranger with a Google account, also modify or delete the data inside them? Altering records in third-party production apps would be unethical and unlawful, so Claroc built and published two test apps of its own, using fabricated data, to inspect the backend and frontend code Grok 4.7 generates.

In the first test, Claroc asked Grok to build a contact list and save the entries “so every visitor sees them.” Grok produced a database-backed app with no authentication layer and proposed Anyone with the link at publish time. From an unauthenticated incognito window, the researchers inserted a new database row that immediately showed up for later visitors. The generated backend exposed unauthenticated write endpoints to the public internet.

The second test failed in a subtler way. Claroc asked Grok for a customer list “for my company’s sales team of 4 people.” Grok added an authentication gate on its own, telling the builder it was adding sign-in “so names, phones, and emails aren’t left open.” The login screen offered two single sign-on buttons, Continue with Google and Continue with X.

To a non-technical sales manager, or a hurried developer, a working Google login in front of the customer table suggests the app is locked to a four-person team. It wasn’t. The generated code mixed up authentication (who the user is) and authorization (whether that identity may access the resource). When a visitor clicked Continue with Google, SpaceXSI’s authentication service completed a standard OIDC handshake and returned the visitor’s verified email address, display name and profile picture. Then every database handler (list, add, edit and delete) ran an auto-enrollment routine before checking authorization. In pseudocode, the logic Grok wrote looked like this:

// Simplified representation of the flawed authorization pattern generated by Grok Build
async function handleCustomerRequest(req, res) {
  const user = await verifySpaceXSISession(req); // Confirms a valid Google or X login
  if (!user) {
    return res.status(401).json({ error: "Authentication required" });
  }
  // FATAL FLAW: Unconditional Just-In-Time (JIT) team provisioning BEFORE authorization check
  await db.teamMembers.upsert({
    where: { email: user.email },
    update: { lastSeen: new Date() },
    create: { email: user.email, name: user.name, role: "member" }
  });
  // Authorization check: always evaluates to true because the user was just added above
  const isAuthorized = await db.teamMembers.findUnique({
    where: { email: user.email }
  });
  if (!isAuthorized) {
    return res.status(403).json({ error: "Not on the sales team" });
  }
  // Proceed to read, modify, or delete customer records
  return executeDatabaseAction(req.action, req.payload);
}

The app added every newly authenticated user to the team table before it checked membership, so the check was a tautology and could never fail. Claroc tested this with an external, uninvited Google account that had no connection to the app’s owner. The stranger signed in, got past the gate, viewed the entire customer list, edited an existing customer record and deleted another.

Why do language models keep writing this kind of broken access control? Say a user asks an AI builder for a customer list for a four-person sales team without supplying the four email addresses. A strict deny-by-default check against an empty team_members table would lock out the creator and colleagues on the first test, and the user would complain in chat that the app is broken. Models tuned by reinforcement learning to produce a working demo on the first prompt tend to settle the missing allowlist by enrolling whoever logs in. That satisfies the request for a login screen and quietly removes the security boundary.

Plaintext passwords in a client-side JavaScript bundle

When builders skip OAuth and ask the AI for a custom username-and-password login, the generated code often commits an older sin: it ships the whole credential store inside the client-side JavaScript bundle.

In one exposed app Claroc examined, a contractor’s staff timesheet, the JavaScript file that every visitor’s browser downloads held hardcoded account objects for all 18 employees, with the first two flagged as admin. Each record had an id, a name, a password in cleartext and a passwordHash. A client-side function prepended a static string prefix to the user’s input and computed one round of SHA-256.

That implementation fails at three levels:

• Any JavaScript file referenced in an HTML document is downloaded in full before it runs. Credentials or hashes in frontend code hand the whole user database to anyone who opens Chrome DevTools or runs curl against the script URL.
• Computing a SHA-256 hash while leaving the password property next to passwordHash in the same array makes the hash pointless.
• Even without the plaintext field, one fixed prefix shared by all 18 accounts is a static global salt, not a unique random per-user salt, and a single pass of a fast digest like SHA-256 lets an attacker with a modern GPU rig crack all 18 hashes at billions of guesses per second. Passwords should be verified only on the server, against hashes produced by a memory-hard key derivation function such as Argon2id (or at minimum bcrypt or scrypt) with unique per-record salts.

Grok Build does have a “Secrets” feature for storing third-party API keys server-side, outside the app’s source code. It doesn’t help when the code-generation model writes authentication logic and hardcoded arrays into the frontend bundle and no static-analysis guardrail blocks the publish.

Disclosure timeline and the Meta Muse precedent

The way SpaceXSI handled Claroc’s report shows an asymmetry between how it protected its own exposed data and how it treated its customers’.

• Sunday, November 8, 2026: Claroc reported the exposure to SpaceXSI through the security contact in the company’s security.txt file. The report included the subdomain counts, findings from the two test apps, four concrete architectural fixes and an offer to transfer the full list of 35,578 exposed hostnames privately so SpaceXSI could notify affected customers. Claroc also flagged two of SpaceXSI’s own exposed internal apps: the enterprise sales onboarding plan and the confidential X ad proposal to a U.S. federal agency.
• Monday, November 9, 2026: With no response, Claroc sent a follow-up covering the remaining 22 open SpaceXSI and X employee apps and the customer exposures it had manually confirmed. When the silence continued, a Claroc official posted on X, tagging Elon Musk and Grok Manager Matt Palmer.
• Tuesday, November 10, 2026: SpaceXSI still didn’t reply to Claroc directly. After Ars Technica emailed questions, it sent a statement defending its publish workflow and began taking down the 24 apps built by SpaceXSI and X staff. Within a few hours, all 24 URLs returned an “app not found” error.

Meanwhile the thousands of exposed customer apps, including the ICU patient briefing, the hospital staff rosters, the defense contractor lists and the timesheet with the passwords, stayed live. SpaceXSI gave no sign it would notify those owners, even though it holds the server-side record of every grok.me deployment. So Claroc began contacting the 30 identified organizations directly, through their CISOs, security teams and privacy officers. When Aprozper reached the CISO of the luxury cruise line whose crew galley checklist was exposed, the CISO immediately pulled in the company’s entire security team to contain the leak.

The Grok Build exposure is the second major vulnerability of this class that Claroc found in under thirty days. The first was its October 2026 “GhostShares” disclosure involving Meta’s Muse AI agent. Muse published shared artifacts to subdomains under cf.metaaiusercontent.com and, instead of random dice words, embedded the conversation’s human-readable title in the hostname. Claroc pulled over 6,800 exposed links from passive DNS. Once alerted, Meta suspended link sharing across Muse, re-engineered the architecture and reissued previously shared artifacts under new URLs, so old links sitting in passive DNS logs couldn’t be used to harvest data. SpaceXSI took down its own 24 leaked apps and left the subdomain-plus-default-public architecture in place for everyone else.

One fact about passive DNS applies to both incidents. After an app is unpublished or moved to a new URL, the historical DNS records stay in commercial intelligence databases for good. Any sensitive string in a hostname, such as the new hire’s name in SpaceXSI’s onboarding URL or a confidential project codename, remains in historical DNS archives permanently.

How to secure vibe-coded apps: a playbook for security teams

Traditional application security assumes software passes through a recognizable pipeline, such as a Git repository, a CI/CD runner, a cloud IAM review or a procurement ticket, before it reaches production. Vibe-coding agents collapse design, database provisioning and public deployment into one browser tab that needs no corporate single sign-on and no administrator approval. Claroc worked with one enterprise that found 500 separate AI-built apps across its workforce. Because every new chat prompt rewrites an app’s schema and code, a harmless lunch poll on Monday can hold a live customer database by Wednesday.

Fixes platforms should make

Claroc handed SpaceXSI four engineering changes:

1. Route shared apps through high-entropy URL paths under non-secret origins, so capability tokens never touch DNS.
2. Add an “Everyone in my organization” access tier bound to verified corporate OIDC hd (Hosted Domain) claims.
3. Make Only you the publish default for every user tier.
4. Run pre-publish static analysis that blocks deployment, or forces an explicit allowlist, whenever an app provisions a database without authentication or embeds credentials in client code.

Steps for enterprise security teams

Until AI app builders enforce those defaults, treat vibe-coding domains as an active external attack surface and run a structured discovery and containment workflow:

1. Sweep passive DNS and proxy logs for AI builder domains. Query corporate DNS forwarder logs, secure web gateway (SWG) telemetry and commercial passive DNS feeds for activity and subdomains across the major vibe-coding hosts, including *.grok.me, *.chatgpt.site, *.lovable.app, *.replit.app, *.bolt.new, *.v0.dev, *.base44.app and *.cf.metaaiusercontent.com.
2. Probe discovered endpoints without authentication. Test every corporate-linked URL from an isolated, unauthenticated browser session. Any internal tool that doesn’t return HTTP 401 or 403 at the network edge should be switched to Only you or Invited users, or unpublished, which on grok.me ends the hostname within seconds.
3. Verify authorization after login. A “Continue with Google” screen is not proof of access control. Test every authenticated AI-built app with an external personal @gmail.com account to confirm the backend enforces an explicit allowlist or verified corporate domain check before it reads or changes records.
4. Inspect client bundles and rotate exposed secrets. Download and scan the JavaScript bundles of employee-built apps for hardcoded API keys, database connection strings, employee PII, and plaintext or client-hashed passwords, and rotate any credential that ever touched a published frontend file.