What Is Grok Bot? Separate Bots Are Not a Security Boundary

the chat assistant. The longer answer is a contradiction in xAI's own material. The launch page says Bots have their own computer. The documentation, published the same day, says all of your Bots share one persistent cloud computer — and that separate Bots should not be used as a security boundary.

Both statements are from xAI. Only one survives a security review. If you're evaluating Grok Bot for ops work, that gap is the evaluation; everything else is a pricing conversation. Each Bot gets a screen.

The account gets a machine. So: A browser session one Bot opened is available to every other Bot on that account. Sign a Bot into your CRM and every Bot you run can reach it. Isolation between users is strict — each user gets a dedicated microVM with its own kernel, memory, and virtual devices.

Isolation between Bots doesn't exist, by design. The product itself has described the arrangement as a real blast radius. The practical consequence for a mid-market team: "can we point it at our ERP?" resolves to "only with an account scoped to what you'd let every Bot on that account touch." That's a different question from the one most people think they're asking. When a Bot hits a login, a 2FA prompt, or a CAPTCHA, it hands the computer back to you.

You type the credential, hand control back, and the session persists — for every Bot on the account, from then on. This is also the genuine differentiator. API-first agents can only reach systems someone instrumented. A browser-driven agent reaches the legacy SaaS and admin panels nobody ever built a connector for.

That's real capability, and it comes with the obvious cost: the agent is only as reliable as a browser session on a site that may block automation, expire, or demand a human step at 3am. There's a review layer — an independent model evaluates shell commands, plugin calls, and automation writes before they run, and can allow, require approval, or deny. Treat it as a control on actions, not as isolation between agents. It doesn't change the shared-machine fact above.

Taken from the vendor's own documentation rather than from critics: Not on-prem. No deployment inside your own perimeter, no bring-your-own-image. Speed to value comes from zero setup: one message, one shared cloud computer, vendor-managed models, five minutes. The price is zero perimeter control.

You can't run it in your network, can't pin the model, can't isolate one Bot's credentials from another's. That's a reasonable trade for low-sensitivity ops, sales, and support work. It's the wrong trade when the workload needs its own perimeter — data that can't leave your region or VPC, a model you must pin for audit or cost reasons, credentials isolated per process rather than per user, or a system that only exists behind your VPN. Build in that case, and accept the other side of the trade: design and integration cost up front, you own operations, and a first version takes weeks rather than minutes.

The alternatives split along the same axis. Ecosystem agents from the big model vendors get you admin controls at a lower tier. Hosted agent platforms get you bring-your-own-model keys. Open-source agents run on your own hardware with your own keys, and you own patching and security forever.

None of them match the sign-into-anything-with-a-browser reach. Each wins on one axis Grok Bot gives up deliberately. Pick the axis that matches the workload, and check the current pricing page yourself — the plan structure moved once between the August launch and October, and it'll move again. Full breakdown — plan-by-plan access, the security control list, and alternatives compared: see the full guide https://teamvoy.com/blog/what-is-grok-bot/ Written by Zhanna Yuskevych, CPO at Teamvoy.

More engineering writing at https://teamvoy.com/blog