Every Grok Bot Shares One Computer. And Every Login on It.

SpaceXAI's marketing page says Grok Bots "have their own computer" and that "Bots share a computer of their own in the cloud." Its documentation says something else, in a sentence with no room to negotiate: "Every Bot on your account uses the same computer." Not one per bot. One per account.

The docs are the accurate document. They go on: "Browser cookies and signed-in sessions are shared. Files are visible to every Bot. Command-line credentials are shared." Each bot gets its own screen, and the docs pre-empt the obvious misread: "The screens are separate work surfaces, not separate security boundaries." Then, in case anyone was still hoping, "Do not use separate Bots as a security boundary." And: "Isolation is per user, not per Grok Bot."

Almost every launch thread repeated the marketing instead, including outlets writing that each bot gets its own cloud computer. Small error, large consequence. The org chart everyone drew in week one, a fleet of narrow specialist bots, reads as a set of compartments. It is not. It is one Linux box with one browser profile and several windows open on it.

What one computer actually means at your desk

Connect Gmail once and every bot on the account can reach it. Your sales bot and your finance bot share a cookie jar. A file one bot writes is readable by all of them. An API token you paste into the terminal for a data cleanup job is available to the bot doing competitor research on the open web, which is the bot most likely to read attacker-controlled text.

The mental model from Matt Van Horn's post-launch sweep is the right one:

Splitting work across eight bots buys clarity, not containment. Van Horn's instruction to operators is the whole post in one line: "Scope risk at the connection level, never by splitting bots. They share one VM and one credential pool."

Credit where SpaceXAI has earned it

This is not a careless vendor. The documentation is unusually candid, and the defaults are more conservative than the discourse around them.

All eight official reference bot roles are scoped to prepare work with the action step withheld. Sales Outbound explicitly does not send. Paid Media recommends, does not change. Expense Manager does not process reimbursements. Bug Reproduction is staging only, no production customer data. Product Performance makes no production changes. Eight for eight is a posture, not an accident of drafting.

The approval guidance is sensible too. Gate sending messages or invitations, publishing content, purchases and financial transfers, deleting or overwriting data, changing permissions, production changes, and accepting legal terms. There is an explicit warning to "avoid broad rules such as 'allow everything in the browser'." Passwords, verification codes, CAPTCHAs and payment confirmations require manual human entry through a takeover flow. Local computer access defaults to "Ask every time."

Practitioners landed in the same place on their own. Van Horn's third property: "Draft-and-approve by default. Queued emails, chat confirms before booking, approval before spending. Every workflow that people trust enough to keep running has a human gate at the money-or-send step." The screenshot everyone passed around had 36 LinkedIn drafts queued and zero sent. The product working as designed.

What is missing

Four gaps, all of them the kind a security team asks about in the first ten minutes. No SOC 2, ISO 27001, GDPR, HIPAA or FedRAMP claims appear anywhere in the documentation set. There is no dry-run mode, so a test run executes real actions against real accounts. Per-action audit trails are listed as "coming," which means today you reconstruct what a bot did from a chat transcript. And approvals are prose in a conversation rather than policy enforced by the platform, so your control is only as strong as how a model reads your sentence on a bad day.

Compare that with mature governance on the same capability. Anthropic's computer-use documentation advises "avoiding giving the model access to sensitive data, such as account login information, to prevent information theft." Claude Cowork gives enterprises an org-wide toggle, a network policy where no network access is the Enterprise default, a mandatory egress proxy the sandbox cannot bypass, and the option to require fresh approval on every permission-gated tool call. Those are controls an administrator sets, not requests a bot honors.

Anthropic is also honest about the limit, in a line worth taping to a wall: "Isolation limits where Claude's code runs. It doesn't limit what Claude reads or does."

The risk is not theoretical. In May 2026, before Bot shipped, a Grok-integrated wallet was drained of roughly $150,000 to $200,000 through a Morse-code prompt injection. A Reddit user on launch day called the sequel: "Incoming a lot of stories like bot send all my money to someone."

The pattern that holds

Run it deliberately and the product is genuinely good. Six rules cover it.

Give the bots their own identity. theshrike79 on Hacker News put it better than any policy doc: "If I were to give it the ability to send mail, it sure as [expletive] wouldn't be as me. It would have its own identity and account." Contained accounts, contained inboxes, contained calendars. Revocable in one click, legible in a log.

Scope by connection, not by bot. The bot boundary is cosmetic, the connection boundary is real. Every integration you attach is attached to all of them, so decide at attach time.

No payment rails. No saved cards, no wallet, no bank session left signed in.

Keep the gate at money-or-send. Draft-and-approve is the setting that survived first contact with real users.

Put persistent rules in the bot profile. Avi Chawla's point is a mechanism, not a preference: "never send external messages without approval" belongs in the profile, which persists, not the conversation, which is ephemeral. Keep local execution set to never allowed unless you need it.

Keep beta bots away from production. Van Horn again: "Keep beta bots off payments, production, and customer data until permission granularity and audit records are documented." Two of those three are still open.

None of this makes Grok Bot less useful. It makes the useful part the part you keep. The failure mode is not the technology. It is drawing an org chart and reading it as a network diagram.

Scope connections, not bots.

John Tan

Founder and CEO of nativefirst.ai. Embeds with scaling founders and CEOs to ship Level-3 agents and AI workflows in production.