Grok Bot Gives Each Team Member a Persistent AI Workspace

Grok Bot is being set up for teams as more than a chat assistant. Each member receives one dedicated managed Linux virtual machine, and every Bot that member creates shares its files, browser sign-ins and permissions. The result is a persistent AI workspace that can research, browse, use connected tools and, with permission, act on the employee’s local computer. The key boundary is the member, not the individual Bot.

The service uses a member’s Cursor account, carrying over existing Cursor single sign-on and team membership. Members can use it through Cursor’s macOS and Windows desktop apps or its iOS app. Self-serve teams can access it on Standard and Premium seats with a weekly usage allowance; enterprise access is still rolling out through account teams.

One workspace for a roster of specialists

A Bot has its own name, job, conversation and working context that can develop over time. It can retain stable preferences, facts and work summaries, although the product documentation advises keeping changing facts in authoritative source systems. Accounts can hold up to 50 Bots and group chats combined, and Bots can exchange context through direct messages, group chats and shared files.

That design supports a collection of focused roles rather than one general helper. Users can set each Bot’s profile, enabled skills and routines, then use group chats when a handoff needs to remain visible. But separating roles does not separate their underlying environment: shared computer files and sign-ins can remain after a Bot is deleted.

Controls carry over, but action review is still evolving

Bots can connect through plugins and MCP servers, browse the web from their virtual machine and sign in to services in its browser. They can also run commands, read files and move files on a member’s local machine when the member permits it. The first local action requests consent; later actions pass through Auto-review, which displays the exact command for approval.

Team-level Cursor settings for privacy mode, MCP configuration and team rules apply to Grok Bot. Administrators can disable MCP commands globally, set server allowlists or denylists, and control whether members add their own servers. Hosted MCP sign-in tokens stay in Cursor’s backend rather than on the virtual machine, according to the documentation.

Three deployment constraints to plan around

• Privacy Mode (Legacy) blocks Grok Bot entirely; other team privacy and data-training settings govern members while they are on the team.
• The virtual machines use static internet egress IP addresses, so organizations that restrict services by source IP may need to update allowlists.
• The Linux virtual machine does not natively support device-trust agents such as Okta FastPass, though hardware security-key prompts can be forwarded through the desktop app.

The enterprise product is not fully instrumented yet

The product does not offer members or administrators a model picker. It routes requests to a fixed set of models for each product surface, uses automatic failover, and bills based on the model that actually served the request. Organizations with contractual limits on data subprocessors are told to consult their account team before deploying it.

Two controls are explicitly unfinished: Grok Bot has no product-specific spend cap, and an audit view of Bot actions is still planned rather than available. A team-level ceiling for local execution is also described as coming soon. Those limits matter most for organizations weighing broad access to a persistent workspace against the ability to constrain and reconstruct its actions at scale.