Grok Bot Gives Every Agent Its Own Computer and Asks for Your Passwords

xAI launched Grok Bot in early beta on 11 August, and the pitch is the one everybody has been circling for two years: a team of always-on agents, each with its own cloud computer, that sign into the tools you already use and finish multi-step work while you are somewhere else.

The demos are good. The capability is real. And buried in the documentation is a sentence that should determine how you use it, which is that all of your Bots share one persistent cloud computer and separate Bots should never be treated as a security boundary.

I want to take both halves of that seriously, because the reflexive reactions in both directions are wrong.

What it actually does

Each Bot gets a persistent environment with a browser, a filesystem, and a terminal. Persistent is the important word. Unlike a computer-use agent that spins up, does a task, and disappears, a Grok Bot's environment carries state across sessions. It stays logged in. Files it downloaded last week are still there. Whatever it configured stays configured.

That solves a genuine problem. The single most tedious failure of browser-driving agents has been re-authenticating on every run, which is why so many of them get 80% of the way through a task and stop at a login wall. An agent that stays signed in can actually finish a multi-day piece of work.

It signs into your tools with your credentials, which is how it reaches systems that have no API worth using. This is the same trade that every computer-use agent makes, and it is why they can automate the vendor portal your finance team hates and an API-based agent cannot.

The context is worth noting too. xAI is now part of SpaceX, which absorbed it in February and closed its $60 billion acquisition of Cursor on 15 August, four days after this launch. Grok Bot arrives as part of a much larger developer-tooling play, not as a standalone product experiment.

The sentence that matters

Here is the thing I would put in front of anyone about to pilot this.

xAI's own documentation says that all your Bots share one persistent cloud computer, and that separate Bots should not be treated as a security boundary.

Read what that means operationally. If you create a Bot for handling invoices and a Bot for browsing supplier sites, they share browser cookies, files, and command-line credentials. The invoice Bot's access to your accounting system is reachable from the session in which the other Bot read an attacker-controlled webpage.

That is not a criticism of xAI for saying it. It is the opposite: publishing that clearly, in beta, is more honest than a vendor implying isolation that does not exist. Plenty of agent products have exactly this property and do not say so.

But it collapses the mental model most people will bring. The product presents Bots as separate teammates, and separate teammates imply separate access. They are not separate. They are one machine with several personas, and your blast radius is the union of everything all of them can reach.

The second documented detail compounds it: there is no sandbox. The docs are explicit that a test run does real work. It navigates real websites, modifies real files, and calls real connected tools. There is no dry run to build confidence with.

The compliance gap

Reviewers going through the documentation have not found a SOC 2, ISO 27001, GDPR, or HIPAA claim anywhere in it. There is no stated retention period, no data residency option, and no encryption specification. Credential handling and sandboxing are pointed at separate documentation rather than being specified up front.

For an early beta, that is not scandalous. For a system you are about to hand your production credentials to, it is decisive, and it makes the decision easy rather than hard. If you are in a regulated industry, this is not a question you need to take to your compliance function, because there is nothing for them to assess yet.

Where it is genuinely useful right now

I do not want the security section to read as a dismissal, because the capability is ahead of anything I have used and there is real work it can do today.

Use it where the credentials are disposable. A Bot with its own accounts on external services, not your corporate SSO, doing research, monitoring, competitive tracking, or data gathering from public sources. If those credentials leak, you rotate accounts nobody else depends on.

Use it where the output is reviewed before it matters. Drafting, gathering, summarising into a document a human reads before anything happens. The persistence advantage still applies and the blast radius is bounded by the review step.

Use it for personal productivity rather than production process. There is a genuine difference between one person delegating their own browsing to an agent with their own accounts, and a company routing an operational process through it. The first is a reasonable early-beta use. The second is not, yet.

What I would not do is give it credentials to a system where an unwanted action is expensive or irreversible. Not because Grok Bot is careless, but because the documented architecture says the isolation you would be relying on is not there.

The pricing question

Grok Bot cannot be bought on its own. Access requires SuperGrok Heavy at around $300 a month, Cursor Ultra at around $200, or Cursor Teams Premium at roughly $120 per seat.

Two observations about that.

For an individual, $300 a month for an always-on agent is easy arithmetic if it saves a few hours. It plainly can.

For a team evaluating this as infrastructure, per-seat pricing on an agent product is a slightly odd shape, for the reason per-seat pricing is disappearing everywhere else: if the agent works, you need fewer seats. Bundling it behind subscriptions that were sold for something else makes it hard to know what the agent itself costs, which makes it hard to compare against alternatives or to model at scale.

I read the bundling as a distribution decision during beta rather than a considered price, and I would expect it to change.

How I would run a pilot

If you want to evaluate this properly rather than either adopting it or dismissing it, the shape I would use:

One Bot, not several, because separate Bots are not separate anyway and pretending otherwise builds a false model in your team's head.

Fresh accounts on external services, created for this purpose, with no reuse of corporate credentials and no SSO. Assume anything it touches is compromised and check whether you still care.

A task with a reviewed output and no direct write path into anything you run. Research, monitoring, drafting.

Two weeks, with a log of what it completed unassisted, what it got stuck on, and what it did that you did not expect. That third column is the interesting one and it is the one nobody keeps.

Then decide. You will have a real read on the capability without having bet anything on a security model that its own vendor says is not a boundary.

The wider point

Grok Bot is the clearest example yet of a pattern I expect to become normal: agents with persistent environments and real credentials, doing work through the same interfaces people use. That is a genuinely more capable shape than API-only agents, because most enterprise software still has no API worth automating against.

It also concentrates risk in a way the industry has not worked out how to handle. Persistent state plus real credentials plus untrusted input is the exact combination that makes prompt injection consequential rather than embarrassing. The answer will eventually be per-agent isolation with scoped, short-lived credentials, which is where the rest of the agent world is heading. Grok Bot is not there yet and says so.

Treat it as an early look at where this goes, use it where the credentials are cheap, and check back when the isolation model is documented.

We spend a lot of time on the boring end of this: per-agent identity, scoped credentials, and working out what an agent could actually destroy before it gets the keys. If you are piloting always-on agents and want that done properly, get in touch.