Grok Bot lets you create many Bots. The vendor documentation is clear that they all share one cloud computer. This guide maps where the real boundary sits and what to do about it.
Basis of this analysis. This guide is written from xAI's and Cursor's published Grok Bot documentation (read October 2026) and a Cursor forum thread. HexTyx has not tested Grok Bot, and HexTyx is a security vendor. Where a recommendation is ours rather than the vendor's, we say so.
Grok Bot is xAI's "AI teammate" product, launched in beta in August 2026 and distributed through Cursor. You can create several Bots, give each a name and a job, and let them work in the background on a computer. The security question that matters is not how many Bots you have. It is what they have in common.
The vendor documentation answers it directly. On xAI's approvals, security and privacy page: "All of your Bots share one cloud computer assigned to your user account." Files, browser sessions and command-line credentials on that computer "are available across your Bot roster." And the sentence worth remembering: "Do not use separate Bots as a security boundary."
This article maps what that means in practice. Related deep dives in this series cover the shared workspace, prompt injection, credentials and a comparison with Meta Muse.
The documented isolation sits around the user, not around each Bot.
| Layer | What the documentation says | What it means |
|---|---|---|
| Between users | Each user gets a dedicated Firecracker microVM with its own kernel, memory and virtual devices | A strong boundary between people |
| Bot identity | A Bot has no identity of its own and cannot hold more access than the signed-in member | A Bot is an extension of you, not a separate principal |
| Between one user's Bots | "Within one user, every Bot shares that computer" | No boundary. A login or file is available to every Bot |
| Connector tokens | Connector tokens stay on Cursor's backend, not on the computer | Tokens are kept out of the Bot's reach, but the connector's authority is still usable |
This is a sensible design for a personal assistant. It is a weak fit for the mental model that "my finance Bot is separate from my web-research Bot."
Naming a Bot "Finance" and instructing it never to touch the browser does not create a control. A name and a system prompt change behavior, not reach. If the research Bot reads a hostile web page and is steered, it inherits whatever the computer holds: the signed-in browser, files from the other Bots, command-line credentials.
We call this the Personality Isolation Fallacy: treating separate personas as separate security principals. The documentation says the same thing in fewer words. If you need real separation, the vendor's own guidance is to give the workload its own Cursor user, which gets its own computer and its own logins.
Launch copy describes Bots as having "their own computer." The documentation says they share one. A Cursor forum thread opened in August 2026 shows users running into this, specifically that all Bots share one Chrome session. In October a Cursor staff member confirmed all Bots share one browser session and said the team is working on per-Bot sessions.
We are not suggesting anything improper. Beta products evolve, and the docs are clear. The practical point is that a buyer who skims the launch page may assume a boundary the architecture does not provide. Read the security pages, not the landing page.
Several of the strongest controls are plan-gated. This changes the risk picture for individuals and small teams.
If you are on a plan without those controls, the layers that remain are the per-user microVM, approvals and your own discipline. Plan accordingly.
The documentation lists the controls that "don't depend on any model's judgment": network policy, per-action approvals and per-user isolation. That is the right framing. Defenses that depend on a model reading hostile content correctly "reduce, but don't eliminate, risk," in the vendor's own words. For the full picture of how outside content steers an agent, see indirect prompt injection.
The boundary that holds under compromise is the one that does not require the agent to behave. In an architecture where every Bot shares one computer, the only such boundaries are the ones outside the Bot: the user boundary, the approval step, and (on Enterprise) the network policy.
HexTyx has not tested Grok Bot. We have tested 28 domain apps with synthetic data and live LLM agents. One result is relevant to the "label is not a boundary" point. In our Relay app, a forged admin_worker handoff was accepted by the receiving agent until we added a signature gate. An identity that is only claimed in text is not an identity. The same logic applies to a Bot's name or persona.
These are HexTyx recommendations, not vendor guidance.
For the structure of this kind of analysis, see AI agent blast radius and AI agent permissions.
Not "which Bot did this?" but "if any one Bot were steered by hostile content, what could it reach, and what could it do with it?" If the answer is "everything this user can reach," that is your blast radius, and it is the same for one Bot or ten.
Run the free playground scanner against your AI application, or read the other guides in this series.