What is Grok Bot, and should you hand it real work?

Most agent products start by asking which APIs you have. Grok Bot starts somewhere else: it gives the agent a computer, has you sign that computer into your apps, and lets the agent click through websites that never shipped an API. That is the pitch in one sentence. It is also the security review in one sentence, which is why this post leans on the documentation more than the launch announcement.

What is Grok Bot?

Grok Bot is a hosted, always-on AI agent product from SpaceXAI - the name xAI announced in July 2026, months after SpaceX acquired it - launched in beta on August 11, 2026. The launch post calls it “your team of always-on agents”: Bots that sign into the tools you already use, work across apps and websites even where there is no clean API or MCP server, and come back only when something needs your approval.

The name says Grok, but the plumbing says Cursor. You sign in with a Cursor account, which meters usage and bills on-demand overage; the cloud computers run in Cursor’s cloud; and the official docs exist in two parallel copies, on docs.x.ai and cursor.com. Even the iOS app’s bundle identifier, co.anysphere.sand, names Anysphere, the company behind Cursor. SpaceX reported its acquisition of Anysphere complete on August 14, three days after Grok Bot launched.

Cursor also picks the model. There is no model picker, the docs say the serving mix can change, and no primary source names the model behind Grok Bot. Usage analytics show which model served each request, but only after the fact.

It ships as a desktop app for macOS, Windows, and Linux, with companion apps for iPhone, iPad, and Android. There is no documented web client, API, or SDK.

How does Grok Bot work?

Grok Bot works by giving your Bots one hosted Linux computer in Cursor’s cloud, where your signed-in sessions live and work continues after you close the laptop. Bots use plugins where a service has one and, everywhere else, the computer itself - its browser through computer use, plus its filesystem and terminal. Each Bot keeps its own memory and routines, but the computer belongs to your account, not to any single Bot.

Your Cursor account
  plugins and skills      account-wide, available to every Bot
  OAuth tokens            held on Cursor’s connector backend, never on the computer
  cloud computer          one Firecracker microVM per user, Linux, US-hosted
    browser sessions      shared by every Bot
    files and CLI creds   shared by every Bot
    screens               one per Bot, a work surface only
  Bot A                   its own memory and routines
  Bot B                   its own memory and routines
  Bot C                   its own memory and routines

That sketch is mine, drawn from the docs. SpaceXAI’s design post supplies the vocabulary: prompts can be run once, saved as skills, or triggered as routines; tools and skills are set per account; and the practical limits are roughly 50 Bots per account and six per group chat. Documented plugins include Gmail, Slack, Notion, and Google’s Drive, Docs, Sheets, Slides, and Calendar, and SpaceXAI has since announced connectors for X, Salesforce, HubSpot, Gong, and other go-to-market tools.

Routines and teach-by-demonstration

A routine runs a workflow for one Bot on a schedule, at least five minutes apart; after an event such as a Slack message or GitHub notification; or when its webhook receives a POST with a bearer key. Two details catch people out: a 200 response means the run started, not that it finished, and a “Test run” does real work, including changing files and calling connected tools. The “Teach a task” feature, still rolling out, records up to ten minutes of your visible screen activity, without microphone audio, and turns the demonstration into a draft skill you review before scheduling.

Sign-ins, approvals, and Bots that talk to each other

When a Bot hits a password, two-factor prompt, CAPTCHA, or payment step, it hands the computer to you; Cursor’s docs say the Bot does not type or see your password. But the session you just opened persists on the computer, and every one of your Bots can use it. Plugins are account-wide too, though their OAuth tokens stay on Cursor’s connector backend and are never stored on the computer.

Auto Review, which the docs describe as an independent review model, checks risky actions before they run and then allows the action, asks you, or blocks it. Those actions include shell commands, plugin calls, computer use, automation writes, and delegation to other agents. It only works when it is on: docs.x.ai says each member’s own setting remains the off switch, while cursor.com says Enterprise admins can lock it on. It does not review every side effect - memory writes and most settings changes fall outside it - and neither approving nor stopping undoes work already done.

Commands on your own machine sit behind a separate “Execution on Local Computer” setting that asks every time by default. The docs recommend “Never” unless a Bot needs local files, and so do I.

Bots can also message each other asynchronously in group chats, which is how SpaceXAI says its own staff run several Bots under a chief-of-staff Bot. Every one of those messages costs usage, as the pricing section shows.

Is Grok Bot the same as @grok on X?

No. @grok is the automated reply account people tag on X; Grok Bot is the agent product. The mix-up is understandable, since xAI’s own grok-prompts repository on GitHub describes the @grok reply prompt as the prompt for the Grok bot on X. None of the 18 Grok Bot pages on docs.x.ai mention @grok, and those docs mention X only as an X Premium+ usage link. Separately, an August 29 SpaceXAI post added an X connector, an X plugin, and free X API credits for paid Grok Bot users.

The distinction matters because the incidents behind @grok’s headlines - the May 2025 “white genocide” replies xAI blamed on an unauthorized system prompt change, antisemitic posts in July 2025, and sexualized edits of real people’s photos that xAI restricted on January 14, 2026 - involve the X chatbot, not this product.

How much does Grok Bot cost, and who can get it?

Grok Bot is not sold on its own: it comes with paid Cursor plans from $20 a month, SuperGrok, SuperGrok Plus, or SuperGrok Heavy (from $30 a month), or a linked X Premium+ subscription, and there is no permanent free tier. Its usage is a separate allowance that does not count against your existing Grok or Cursor usage.

The eligible plans have already changed more than once. On launch day only SuperGrok Heavy, Cursor Ultra, and Cursor Teams Premium qualified; access widened to seven plans on August 26; SpaceXAI announced Enterprise availability on September 3; and the live launch post has since been edited to show the wider list with no update notice.

Grok’s Free and SuperGrok Lite plans and Cursor’s free Hobby plan do not include Grok Bot, and buying through the iOS app costs more. Individuals get a one-time trial instead: a usage credit with a seven-day window that never converts to a paid plan. Do not confuse it with an App Store introductory offer, which renews as a paid subscription unless you cancel.

How usage is metered

Every paid route includes a weekly usage grant, and no tier publishes its size. When the grant runs out, work continues as on-demand usage billed through Cursor if you enabled it, counted against a monthly on-demand limit that a running Bot may finish past; otherwise it stops until the reset. Grants do not stack: with both a Cursor plan and a SuperGrok subscription, you get whichever grant is larger. A SuperGrok or X Premium+ link is permanent and cannot be moved to another Cursor account, and there is no spend cap specific to Grok Bot beyond that account-level on-demand limit.

Budget for agents talking to agents. In one Cursor forum thread, specialist Bots messaging each other pushed a user’s weekly usage to 100%, and staff confirmed that every Bot-to-Bot message runs a turn that counts toward the allowance, suggesting one agent with subagents instead. Reviewer Tommaso Nervegna calls limit burn the most documented complaint about the product.

What do enterprises get that smaller teams do not?

Almost all of the governance. Network allowlists, audit logs, Action Recording, SCIM, and an organization-wide switch for Grok Bot are Enterprise-only. SpaceXAI announced Enterprise availability on September 3, 2026, after an earlier rollout through Cursor account teams, and made Grok Bot free for Grok and Cursor Enterprise customers for two weeks - roughly until September 17, since no end date was given.

The left column is the default for self-serve Cursor teams: Grok Bot on for everyone, open network access, public template sharing allowed, and no admin record of what Bots did beyond each member’s own chat transcript. The riskiest configuration is the one you get by doing nothing. Enterprise starts close to that too, with allow-all network access and Action Recording off until an admin changes them. Some SpaceXAI pages also lag behind the enterprise launch - the x.ai/bot FAQ still points to a waitlist - and how a Grok-only Enterprise customer without Cursor turns it on is not documented.

Hosting, network, and compliance

Everything runs on Cursor-hosted computers in the United States today, with no on-premises or bring-your-own-image option, and Cursor’s security page says its US-only data residency program does not cover Grok Bot by default. Outbound traffic normally leaves through static egress IP ranges shared by all Grok Bot customers, with no dedicated per-customer IPs. Members can route a computer’s traffic through their own desktop instead, unless an Enterprise admin turns off “Allow Local Egress”, and Enterprise teams can install their own networking client, such as Tailscale or Cloudflare Tunnel, through Team Setup.

On compliance, Grok Bot’s security docs say Anysphere holds ISO/IEC 27001 and 42001 certifications from Schellman with Grok Bot in the current scope. Cursor’s help center claims SOC 2 Type II, but no Grok Bot page says whether that covers Grok Bot. Team docs say Privacy Mode keeps customer data out of training; I found no stated training default for individual accounts. And deleting a Bot does not delete its computer files or browser sessions.

How secure is Grok Bot?

Secure enough for work where one person’s access is an acceptable blast radius, and not designed to isolate your Bots from each other. The documentation is candid about that. The marketing is not.

Marketing copy versus the docs

SpaceXAI’s enterprise post says “Each Bot runs on its own computer in the cloud,” and the launch post says “Bots have their own computer” while also saying they “share a computer of their own.” The docs have said otherwise since launch day: Bots share one computer, including its cookies and signed-in sessions, its files, and its command-line credentials. They put it bluntly: “Do not use separate Bots as a security boundary.” Isolation is per user, in a dedicated Firecracker microVM, and if a workload needs separate credentials, the docs say to give it a separate Cursor user.

Whose identity is a Bot using?

Yours. A Bot has no identity or credentials of its own: it acts as the signed-in member, with that person’s access and no more. The one exception is team-managed connectors, which may use team or service-account credentials. Five Bots on one account are one principal, not five. Analyst Chris DePuy argues the shared computer contradicts the agentic-AI guidance CISA and allied agencies released in May 2026, which advises against broad or unrestricted access.

The Grok Bot identity-provider guide also asks for a trade-off your identity team should own. The Bot’s computer is not device-managed, so the Okta instructions have admins add a sign-in rule for company apps opened on that computer that accepts a password plus a second factor, without requiring a phishing-resistant one. That rule does not cover signing in to Grok Bot itself, and the guide offers synced passkeys as the stronger option.

On prompt injection, the docs mark outside content as untrusted and layer on Auto Review (when enforcement is on), Enterprise network policy, approvals, and per-user isolation, while conceding that these controls reduce the risk rather than eliminate it. I could not find any discussion of the two routes I would test first: injected instructions persisting through a Bot’s memory, which Auto Review does not check, and Bot-to-Bot messages.

Security writer Ken Huang argues Grok Bot fits Simon Willison’s lethal trifecta of private data, untrusted content, and external communication. The shared computer sharpens that, because a Bot that reads a poisoned page holds the same sessions as all the others.

Where the two official doc sites disagree

The docs.x.ai and cursor.com copies give different answers to questions a security review will ask, so test the behavior rather than trusting either page.

On revocation, follow Cursor’s version: remove the member or their group access and revoke their identity-provider sessions. Apply the same caution to shared templates. A share link is public, and SpaceXAI’s third-party bot terms say it does not verify or guarantee a template’s safety, so read a template’s skills and routines before a Bot running as you executes them.

What should you connect to Grok Bot, and what should stay off it?

Connect only accounts you would let any of your Bots use as you, and keep anything irreversible behind approval. Because every Bot shares your sessions, the real question is what everything signed in on that account can reach. This is how I would set it up:

• Start read-heavy: queue monitoring, public-web research, and drafts a person reviews before anything is sent.
• Put every send, spend, and signature behind a “Require Approval” rule, which wins when rules conflict.
• Keep password managers, admin consoles, payment accounts, and production cloud credentials off the computer.
• Set Execution on Local Computer to Never, and keep secrets out of Team Setup manifests, which are plain text.
• Give a workload that needs its own credentials its own Cursor user, not just its own Bot.
• Test routines against disposable data, because a Test run does real work.
• Offboard by removing access and revoking identity-provider sessions, not by terminating a computer.

How does Grok Bot compare with OpenClaw and other agents?

Grok Bot sits at the hosted end: Cursor runs the computer and keeps your signed-in sessions, where OpenClaw and Hermes Agent can keep both on hardware you control. The dividing line is custody: whose computer does the work, and who holds the logins while it runs.

Against OpenClaw, you trade custody for convenience: OpenClaw keeps state and credentials on your hardware and makes hardening your job, while Grok Bot does the hosting and keeps your sessions on Cursor’s disks. Hermes Agent can sit on the same side of that line as OpenClaw when you self-host it, though Nous also sells hosted Hermes Cloud, and it is moving toward the same multi-bot idea, with default-on group chats of bots since its August 31 release. Against Claude Managed Agents, the difference is cost visibility: a published hourly rate plus tokens, versus a weekly allowance of unpublished size. There are companion posts on OpenClaw and Claude Managed Agents.

What do SpaceXAI’s numbers actually prove?

Less than they appear to. SpaceXAI says thousands of organizations adopted Grok Bot within its first weeks, naming Legora, Supermicro, and ServiceTitan, but gives no absolute count - and in the same post, the number of Bots created still reads as a bracketed placeholder, “[millions]”. None of this measures whether Bots complete tasks correctly, and I found no independent benchmark that does.

The most detailed claim is SpaceXAI’s procurement case study: an internal Bot with access to Slack, Notion, Drive, Gmail, Hex, and Ramp mapped about 125 vendors and found more than $100,000 in savings, by SpaceXAI’s own count. Treat that figure as unproven. The design is the part worth copying - the Bot needed explicit approval before it could spend money, accept terms, or send anything to a vendor. By contrast, the launch post features a SpaceXAI salesperson saying they let a Bot run without checking its work. That is a testimonial, not a control.

Independent reviewers are more useful. Claire Vo liked connecting four Gmail accounts and seven Slack workspaces; Dan McAteer ran a support Bot that checked Freshdesk through the browser every fifteen minutes. Both flagged what you cannot choose, starting with the model, which only shows up afterward in usage analytics. The Cursor forum shows early operational edges too, such as a computer stuck in a partial reset that staff said needed manual recovery on their side.

Who should use Grok Bot, and who should wait?

Use it if three things are true: your work lives in web apps that never got a decent API, such as sales operations, support triage, vendor research, or recurring reporting; you already pay for an eligible Cursor or SuperGrok plan; and one person’s access is an acceptable blast radius. Leave on-demand billing off until you know how fast it spends.

Wait if any of these apply:

• You need isolation or separate credentials per agent, not per user.
• Your data must stay outside the United States or inside your own perimeter.
• You need a predictable bill or a hard Grok Bot spend cap.
• You run a self-serve Cursor team and need an off switch or an action log.
• You need a documented API, or guaranteed control over which model sees your data (the Enterprise model allowlist says enforcement is not guaranteed).

What should you ask of any always-on agent?

Ask where trust sits. A team of agents sharing one computer and one set of logins is one principal with several prompts, so whatever vendor you pick, the questions are the same: whose credentials does it act with, what can it reach once signed in, which actions need a human, what gets logged, and what happens when you revoke it. Grok Bot’s docs answer most of them; the gaps I found are memory and Bot-to-Bot messages as injection paths, and which model does the work.

Grok Bot is five weeks old and moving fast: its eligibility list was rewritten in place, its FAQs lag behind the product, and its marketing and docs still disagree. Date every claim you rely on, including mine. Mapping a product’s answers onto a real workflow, and building the boundaries it leaves out, is the work we do at Sentient Arc.