Scoop: Grok Bot ships dormant shared rooms for tasking other users' agents

RUNTIMEWIRE INVESTIGATION — Scoop

Original reporting by RuntimeWire, based on reverse engineering, testing, public records.

Why it matters

Shared rooms would turn private AI workers into cross-account collaborators, creating a new authorization boundary around code, logs, files and local-computer tools.

Reporting record

RuntimeWire found an unannounced sharing system in Grok Bot 0.16.0. The interface could create shared rooms, invite another user, require owner approval and allow participants to add bots, although SpaceXAI's servers prevented RuntimeWire's account from activating the feature.

SpaceXAI and Cursor did not respond to questions sent before RuntimeWire's 10 a.m. CT deadline. Late responses will be added.

The clearest interface is a dialog labeled "Share Tony." It tells the Bot's owner:

Sharing creates a room with you and Tony. Send the link below to another Grok Bot user; they join only after you approve their request.

The shipped client also contains a "New shared room" flow that lets an owner start with one or more agents and invite people afterward. The interface says each participant may add only agents belonging to their own account.

That design extends collaboration across both people and AI workers. A participant could ask an agent owned by someone else to inspect code, check logs or run diagnostic commands inside the environment available to that agent. The final response would return to the shared room while tool execution and tool output remain on the agent owner's side, according to the implementation.

Cross-account sharing was unavailable to RuntimeWire's test account. After exposing the completed interfaces and attempting to create a room with one local Bot, the host returned: "Sharing isn't enabled for your account." No room, invitation or cross-account connection was created.

Owner approvals and expiring invitations

The client includes completed interfaces for sharing an agent, creating and joining rooms, adding and removing agents, removing people, typing indicators and expiring invitation links. Join requests can appear as pending, approved, denied, invalid or rate-limited.

Invitations use sand://join/... links. The dormant join flow tells the recipient that the room's host must approve the request before access is granted. Owners can also revoke access after a participant joins.

Grok Bot's experiment registry describes the feature under the name sand_multiplayer. The rollout is disabled by default and covers share links for individual agents, owner-approved access grants, a shared transcript for each agent, cross-user group chats and backend authorization checks on sharing operations.

The desktop host contains client contracts for creating rooms from an agent, generating invitation links, joining rooms, approving requests, adding and removing agents, leaving rooms and sending cross-user messages. Those contracts establish what the shipped client expects from Grok Bot's services. They do not establish that every corresponding production endpoint is active.

The cross-user system goes beyond the group chats described in Grok Bot's current public materials. Those materials cover conversations containing multiple Bots, including mentions, threads, reactions and agent-to-agent handoffs. The shipped Windows code adds people from separate accounts and gives each person control over which of their agents enters the room.

Scoped computer work across accounts

The most consequential part of the implementation is the runner used when one participant tasks another participant's Bot.

For those turns, the code can offer shell commands and structured file reads on the Bot's cloud computer. It can also offer shell commands and file reads on the owner's local computer, plus read-only screenshots, when the local-execution connection and the owner's approval policy permit them.

The code is designed to permit scoped computer work during cross-user turns. It does not give another participant unrestricted control of the Bot owner's computer.

A system prompt included in the package tells the Bot that diagnostic and debugging requests from another room participant are expected. It also instructs the Bot to reject requests involving credentials, private conversations, stored memory, destructive operations or account actions.

A separate kill switch can restrict shared-room turns to text responses, disabling the computer tools for that interaction. Local commands remain subject to Grok Bot's existing connection and execution-approval controls.

RuntimeWire could not independently test those boundaries because the account gate blocked creation of a shared room. The available evidence comes from shipped application code and prompts rather than a live multi-account execution. The enforcement therefore remains unverified under real cross-user conditions.

The privacy boundary in the shipped code

Grok Bot creates a separate context for the shared room instead of passing an agent's private one-to-one conversation state into the cross-user turn.

The runner denies shared-room access to private memory stores, web sessions, connectors, subagents, account-action tools and saved workflow recipes. Only speaker names and a bounded amount of room message text are serialized for a remote agent's turn.

Tool calls and their output are designed to remain within the agent owner's environment. The agent sends its final text back to the room through a SendMessage action, making that response visible to the participants.

These are implemented safeguards in the 0.16.0 client, rather than audited privacy guarantees. The central security question is whether the production authorization layer consistently binds each room request, agent identity and tool invocation to the correct owner and approval state. A failure at that boundary could expose resources from one user's execution environment to another user's prompt.

RuntimeWire's test preserved the account gate

RuntimeWire inspected Grok Bot's Windows Electron package and its included source maps, located the sand_multiplayer display condition and traced the cross-user sharing implementation.

The test changed only the renderer's local display check to expose interfaces already shipped in the package. RuntimeWire left the host feature flag, authentication, permissions and backend behavior unchanged. The host rejected room creation at the account gate.

The inspection created no shared room, invitation or multi-account session. It also did not bypass Grok Bot's authorization controls.

SpaceXAI introduced Grok Bot in early beta on August 11th as an AI worker that signs into tools and completes jobs on its own computer. The product uses Cursor's authentication and infrastructure, and access is tied to eligible Grok and Cursor subscription plans.

The hidden collaboration layer points to a broader use for that infrastructure: turning individually configured Bots into workers that can accept tasks from people outside the owner's account. The owner-approval flow and separate room context show how Grok Bot is attempting to contain that access. A launch date for cross-account rooms does not appear in the package, and the implementation could change before SpaceXAI enables it.