Grok Bot Enterprise has no documented ownership handoff

By Elena Vasquez

Deleting one employee’s Grok Bot data can permanently erase shared Bots that teammates still use, according to SpaceXSI’s computers documentation. A review of SpaceXSI’s Grok Bot Enterprise documentation found no way to transfer a Bot’s ownership when its creator leaves. That gap puts company-funded automation at risk.

SpaceXSI still labels Grok Bot a beta. It says Bots run on their own cloud computers, sign into the tools a team already uses, and finish jobs while people are busy elsewhere. Those capabilities could shift valuable institutional knowledge from staff accounts into reusable software. The ownership problem begins when the account does not outlive the employee.

The source frames this through a hypothetical enterprise with 10,000 employees. Staff spend real hours, on company time and at company expense, teaching Bots to take over parts of their jobs. If someone leaves, is let go, or is promoted, the company should pass that investment to a successor. Rebuilding it from scratch would waste the original work.

The review put the question to Grok, then checked every part of the answer against SpaceXSI’s documentation. The docs answer some access and cleanup needs. They do not describe an ownership handoff to a successor, a company-controlled owner, or another mechanism that carries the same Bot, memory, and workflows into a new person’s account.

How does Grok Bot share work today?

SpaceXSI’s Shared Bots documentation divides Bots into two forms: “a Bot is either personal or shared.” A shared Bot reaches the team “the way you’d share a doc,” and sharing “doesn’t make a copy.” Each user’s chats remain private. The Bot can still save what it learns for the whole team.

That gives employers a way to retain operational knowledge, but it does not, by itself, settle who controls the underlying asset or who inherits it. A shared Bot can become a repository for company processes without exposing individual conversations. Its durable owner still matters when employees change roles.

Who controls a shared Bot?

Roles provide partial continuity. The owner can add Collaborators, who chat with the Bot, or Managers, who can “also change how it works: its instructions, skills, memory, and apps.” Owners and Managers can edit plugins, secrets, skills, files, and share settings. Managers therefore have a practical route to maintain a role-critical Bot when duties change, provided employers give more than one person the appropriate role.

SpaceXSI’s teams and enterprises guide adds another layer of control. Its Manage Shared Bots section in the Cursor dashboard lets administrators change who can use each shared Bot, add it automatically to members’ sidebars, or delete it. Administrative deletion removes the Bot for the whole team and removes its Slack app. The action cannot be undone.

The owner controls the app, while administrators control access through Manage Shared Bots. SpaceXSI’s Bots documentation says only the Bot owner can delete a shared Bot from the app. More important for succession, none of the pages reviewed in SpaceXSI’s documentation explain how to move a shared Bot’s ownership itself to another employee’s account.

SpaceXSI’s Bots documentation also says, “A personal Bot’s memory is yours, and only you can change it.” That rule makes a personal Bot a poor home for company workflows that must survive staffing changes. The reviewed pages offer no documented transfer from one personal owner to another.

Templates offer a limited substitute. SpaceXSI says a template creates a copy on the recipient’s account. The recipient never receives “your computer, logins, or conversation history.” That copy can help a successor start quickly, but it does not carry the original Bot’s memory or accumulated team learning. It is a fresh setup, not a transfer of the shared asset.

What happens when an employee leaves?

SpaceXSI’s computers documentation describes two Enterprise-only tools for departures. Recreate and Terminate preserve a departing member’s durable disk, so the member’s Bots, files, and logins can return. Neither command revokes access. They support recovery, not offboarding.

For access removal, SpaceXSI tells administrators to remove the member from the team or disable access through Manage Group Access. They must also revoke the employee’s sessions in the identity provider. The docs treat those as three separate controls. An organization can stop a departing worker’s access without deleting every Bot.

The severe option is Delete All Grok Bot Data. SpaceXSI says it “permanently deletes a member’s Bots, conversations, memory, routines, and computer across every team they belong to,” including “shared Bots that teammates use, connected apps, email inboxes, and files.” The command cannot be undone.

That scope creates a direct offboarding hazard. If a role-critical shared Bot lives under one employee’s account, running Delete All Grok Bot Data during departure erases the Bot that colleagues still depend on.

The same command also reaches connected apps, inboxes, and files across every team the member joined. A security cleanup can therefore destroy a business asset at the same time. The feature that removes a former employee’s traces can also remove institutional knowledge the company spent months building.

What can companies do with today’s tools?

With today’s documented tools, the source recommends four workarounds. None delivers a true ownership handoff, but each reduces the chance that a departure erases work the company funded.

• Build role-critical work as shared Bots, not personal ones. SpaceXSI’s Shared Bots documentation makes team learning available without copying the Bot, while each user’s chats stay private.
• Add people who share the role, and their managers, as Managers. That group can maintain instructions, skills, memory, apps, plugins, secrets, files, and share settings under the documented permissions.
• Keep team-only templates of key Bots. A successor can spin up a fresh copy quickly, but memory and conversation history do not come with it.
• Check who owns a shared Bot before running Delete All Grok Bot Data for a departing employee. The source says this check can keep an offboarding command from erasing a Bot the team still uses.

These steps trade certainty for labor. A shared Bot reduces the risk tied to one account, and several Managers reduce dependence on a single custodian. A template still forces the company to rebuild learned context. The ownership check cannot prevent a departing employee from owning the team’s only role-critical Bot.

What must Grok Bot add next?

The source’s author is explicit that this is a policy view, not a SpaceXSI announcement. Businesses should control and own the Grok Bot assets they pay for, rather than leave them with the employee who created them. The work uses company time and expense. Its skills, memory, and workflows should follow the role, not one person’s account.

Shared Bots, Manager roles, and admin controls point toward that outcome. The missing piece is a clear way for the company to take over a Bot and hand it to the next person in the role, with its memory and workflows intact. Until SpaceXSI documents that path, enterprises must treat ownership as an unresolved operational risk.

Grok Bot remains in beta, according to SpaceXSI. That timing leaves room for the ownership handoff large organizations need. The source expects that feature to help businesses trust Grok Bot with more work. Until it arrives, users must separate shared access from durable ownership themselves.