Grok Build team apps: check who gets admitted after sign-in

If you published a Grok Build app for a private team, check whether an uninvited account can become a member simply by signing in. Temporarily restrict access to an internal app while you review that decision. A successful Google login should establish a person's identity; your app still needs a separate decision about whether that person may see or change the team's records.

Claroc reports that its own generated team app added visitors to the team before checking membership. An uninvited Google account could then read, edit and delete customer records. The researchers demonstrated writes only on their own apps. This does not establish that every Grok app has the same flaw. Original research and test scope.

The useful response is an admission test for your particular app. The proposed checks below use a disposable copy with made-up records and accounts you control. VAS has not run them against Grok, your app or any third-party deployment.

Restrict the app before investigating its login flow

Claroc observed public link sharing preselected in its account. It also reports that choosing Only you blocked both a test app's page and data function, while unpublishing another test app took its address offline. The report attributes a different employee-account default to SpaceXSI. These observations are account-specific; check the controls available to you now. Sharing settings and containment observations.

For an internal customer list, roster or planning tool, first record which app you are changing and who owns it. Save its current access setting and intended audience without copying customer records into a support ticket. Then choose the available restriction that matches the immediate need: owner-only access during investigation, or taking the app offline if you cannot establish who can reach its data.

Coordinate that decision with the people using the tool. A restricted sales app may interrupt work; the owner should know the interruption is deliberate and how to report a legitimate access problem. Avoid solving that problem by reopening the app to everyone before the admission check is complete.

Treat a privacy-setting change as containment. It does not show whether earlier visitors saw information, whether records were changed, or whether the generated membership logic is correct. Keep those questions as separate work items, each with an owner.

Find the step that makes someone a member

Give your maintainer one precise question: Can ordinary sign-in create the membership that the next authorization check relies on?

Ask them to trace the first login through the generated application, starting with the identity returned by the sign-in provider and ending with the first customer-list request. The review should identify where the app creates a user profile, where it creates a team membership, and where it checks permission for a record operation. These are different decisions even when an AI builder places them in one function.

Creating a basic user profile may be appropriate for a newly authenticated person. Creating a membership in a private team needs its own authority, such as an invitation issued by someone permitted to invite. If the application adds every successful login to that team and then asks whether the account belongs to it, the check cannot reject the newly added stranger.

Write down the intended rule in plain language before requesting a code change. For example: “A verified invitation to Team Cedar allows this account to join Team Cedar as a viewer. Signing in without that invitation does not create a team membership.” Team Cedar is a synthetic example, not a team found in the research.

A useful request to the app maintainer is:

Review the path from sign-in to the first record request. Keep identity creation separate from team admission. Identify every operation that creates membership, the authority it requires, and the server-side check used before reading or changing team records. Propose the change and test it with disposable accounts and data.

Review the result rather than accepting a generated explanation that says “authentication added.” The change needs to address the admission decision that produced the failure.

Test four identities against the same fixture

Create a disposable customer record containing an unmistakable fake marker, such as CEDAR-TEST-ONLY. Use no copied customer names, contact details or passwords. Prepare the following identities and expected outcomes before testing:

These outcomes describe the example policy. If your app has editors rather than viewers, add an invited editor row with the permitted operations explicitly listed. Do not make every legitimate tester an administrator; that would leave the read-only role untested.

For each identity, check the record operation as well as the page. A login screen or hidden button is one observation. Whether the app's server returns the fake record or accepts a change is another. Have the maintainer use the application's normal requests in an isolated test environment, and keep all attempted writes limited to that fixture.

After the uninvited account signs in, inspect the test membership state through the maintainer's authorized tooling. The expected result is no membership in the private team. A denied page followed by an unexpected membership row is still a reason to stop and review the flow.

Then try the same account again with a fresh session. This catches a fix that only blocks the first screen while a previously created membership silently admits the account on its next visit. Start with a clean synthetic account when repeating the test so old state does not disguise the result.

Make the invitation carry a deliberate decision

An invitation should answer more than whether someone can click a link. For your app, specify which team it admits the person to, which role it grants, who can issue it, and when it stops being usable. Decide how the accepted identity is matched to the invitation and how the app handles an attempted acceptance by a different account.

Turn those decisions into a small set of additional fixture cases. An expired invitation should not create membership. An invitation revoked by its issuer should not work. Accepting a viewer invitation should not grant editor rights. Signing out and returning should not let the user choose a different team or upgrade the role.

If your workflow allows a whole organization to join without individual invitations, document the separate eligibility rule and who maintains it. Do not quietly substitute “any Google account” for “a member of our organization.” Test an account outside the allowed group and one whose membership has been removed.

Apply authorization before returning data or accepting a modification. The same intended rule needs to cover list, detail, search, export and mutation operations that your app actually offers. Build a short operation list from the real app rather than assuming that protecting its landing page covers every feature.

Remove accidental access without losing the recovery trail

Fixing admission logic does not decide what to do with memberships created under the old rule. Ask the authorized app owner to review that history separately. Preserve the records needed for investigation, distinguish expected members from accounts requiring review, and record why an access grant is retained or removed. Avoid a bulk deletion based only on an unfamiliar display name.

For any account removed during cleanup, repeat the removed-member fixture with the relevant session behavior. The closure question is whether the app still returns team data or allows a record change, not merely whether the name disappeared from an admin list.

If the owner identifies exposed information or unexpected modifications, preserve the available application and access records and involve the person responsible for incident response. Do not use a successful repair test as evidence that earlier access never happened. Also do not infer theft merely because an app had an overly broad setting; exposure and observed misuse require different evidence.

Reopen only against recorded outcomes

Before restoring the intended sharing setting, retain a concise acceptance record: app and deployment identifier, tested policy, fixture identities, operations attempted, expected outcomes, actual outcomes, and the person responsible for the change. The record should contain fake markers and results, not sensitive customer payloads.

Keep the blocked stranger and removed member in the regression checks for future changes to sign-in, invitations or team creation. An AI-generated edit that makes onboarding easier should trigger the same admission review before it reaches a private production app.

The original report describes staff-app takedowns without establishing remediation of every other customer's app. It gives no universal fixed version for this generated-code behavior. That is why owners still need to check their own access decisions; it is not a claim that those reported exposures remain live today. Response and remaining scope.

The source establishes a reported failure and the researchers' limited experiments. It does not establish your app's current settings, whether your records were accessed, or whether a proposed repair works. Recheck the primary report and current platform controls at publication, and have the app owner validate the acceptance plan before using it.