The Grok Bot trust model is documented and unusually blunt: all of your Bots share one persistent cloud computer, they share files, browser sessions, and app logins, and each Bot having its own screen does not give it a separate security boundary. Credentials you enter at an auth wall persist on that machine until site or session expiry or revocation and are available to every Bot on the account, including ones created later; xAI documents no per-Bot revocation. As of 22 August 2026 no published SOC 2, ISO 27001, GDPR, or HIPAA claim was found in the documentation set, nor a retention period, data residency option, or encryption specification of xAI’s own; compliance defers to Cursor’s terms. There is no queryable organisation-wide audit view, only per-Bot transcripts and the twenty most recent routine records reported by Daily Dose of Data Science and unconfirmed by xAI, with an audit view described as coming. There is no dry-run mode, so a test run performs real work. Deleting a Bot does not remove the shared files or sessions. Cursor Legacy Privacy Mode blocks the product entirely, enterprise access is a waitlist, and linking a Grok account to a Cursor account is permanent and cannot be moved.
- No boundary between Bots, by documentation. "Treat a login or file placed on the computer as available to all of your Bots."
- No published SOC 2, ISO 27001, GDPR, or HIPAA claim found in the documentation set, and no published retention period or residency option.
- No queryable organisation-wide audit view. Per-Bot transcripts plus the last twenty routine records, reported by Daily Dose of Data Science and unconfirmed by xAI. An audit view is described as coming, twice.
- No dry-run mode. A test run navigates real sites, changes real files, and calls real tools. An approval cannot reverse it.
- Deleting a Bot leaves the shared files and sessions behind, reportedly requiring six manual sign-out steps.
- Compliance defers to Cursor’s terms, Grok Bot runs on Cursor’s infrastructure, and Cursor Legacy Privacy Mode blocks it outright.
- Linking your Grok account to a Cursor account is permanent. Cursor’s docs: you cannot unlink it and cannot move it to a different account.
The one sentence that decides most of this
Before any certification question, there is an architecture question, and xAI answers it directly. From docs.x.ai/grok-bot/overview, retrieved 22 August 2026:
- "The computer is isolated to your account, not to an individual Bot."
- "All of your Bots use the same persistent cloud computer. They share files, browser sessions, and app logins, which makes handoffs possible."
- "Each Bot gets its own screen on that computer, so several Bots can use browser and desktop tools in parallel without getting separate security boundaries."
- "Treat a login or file placed on the computer as available to all of your Bots."
Read that as a security statement rather than a feature description and it says: the account is the only trust boundary in the product. Not the Bot, not the task, not the thread. Everything you authorise is available to any Bot until site or session expiry or revocation, including Bots that do not exist yet; xAI documents no per-Bot revocation.
This is worth stressing because several currently ranking pages state the opposite. At least one comparison table presents "a dedicated cloud computer per bot" as a product feature. It is not, and the primary source is one click away.
What happens to a credential you give it
The credential-handling design has a good half and a consequential half, and they are usually described only as the good half.
The good half: you do not send the password through chat; xAI says the Bot hands control to you. When a Bot reaches an authentication wall it pauses and hands control of the machine to you. You type the password, the second factor, or the CAPTCHA yourself, on that machine. That is better than the common alternative and it deserves the credit.
The consequential half: what remains afterwards is an authenticated browser session living on a shared machine, inherited by every Bot on the account, with no documented per-Bot revocation and no documented expiry of its own beyond whatever the site enforces.
| Question | Answer |
|---|---|
| How is the password entered? | You do not send it through chat; xAI says Bot hands control to you so you can type it on the machine |
| Does the session persist after the task? | Yes, on the shared computer |
| Can other Bots use that session? | Yes. "Available to all of your Bots" |
| Can Bots created later use it? | Yes. The machine is per account, not per Bot |
| Can I revoke it for one Bot only? | No such control is documented |
| Does deleting the Bot remove it? | No. Shared files and sessions survive the Bot |
| Is there a credential inventory view? | None documented |
What the compliance documentation does not say
This section is a list of absences, which is an awkward thing to source. The basis is a review of the Grok Bot documentation set and the launch materials on 22 August 2026, corroborated by an independent teardown published on 12 August that reached the same conclusions. If any of these have since been published, the documentation is the place to check, and this page carries its date at the top for exactly that reason.
| Question | Documented answer |
|---|---|
| SOC 2 Type II? | No claim in the documentation set |
| ISO 27001? | No claim |
| GDPR posture? | No claim |
| HIPAA? | No claim |
| Data retention period? | Not published |
| Data residency option? | Not published |
| Encryption specification? | None of xAI’s own |
| Whose terms govern? | Cursor's. Compliance defers to them rather than a separate xAI agreement |
| Sub-processor list? | Not published for Grok Bot specifically |
| Enterprise agreement? | Waitlist only |
| Whose infrastructure runs it? | Cursor’s, not xAI’s |
| Can the account link be undone? | No. Permanent, and not movable |
It is also worth knowing whose machines these are. Grok Bot runs on Cursor’s infrastructure, not xAI’s. So the shared computer holding your credentials sits with the company SpaceX bought, under a deal announced on 16 June 2026 that did not close until 14 to 15 August, three to four days after the product launched. For a due-diligence exercise that is the entity to ask about, and it is not the one on the box.
Two of the rows above carry more weight than the rest. Residency, because it is the one with no workaround: an organisation with a contractual obligation about where customer data may be processed cannot satisfy it with a product that publishes no answer, no matter how much it likes the agents. That is the substance behind the objection raised on the launch thread, that companies outside the United States are unlikely to be comfortable giving SpaceXAI access to all their files and data.
And whose terms govern, because it surprises people. You are buying an xAI product, and the compliance conversation is with Cursor. Practically that also means a Cursor account setting can remove the product: Cursor Legacy Privacy Mode blocks Grok Bot entirely, since data storage is mandatory. If your organisation adopted Cursor on the condition that mode stayed on, the security review is already over.
There is no queryable organisation-wide audit view
For a product whose agents act inside your accounts, this is the gap that matters most, and it is not subtle. The documentation describes an audit view as coming, in two separate places. What exists on 22 August 2026 is:
- Per-Bot chat transcripts. Readable one Bot at a time, not queryable across an account or an organisation.
- The twenty most recent routine records. Reported by Daily Dose of Data Science; unconfirmed by xAI. Not twenty per routine per day. Twenty.
- No org-wide view, no export, no retention guarantee, and no documented way to answer "what did any Bot do on 14 August".
A twenty-record window also interacts badly with the feature the product is proudest of. Scheduled routines are the reason to buy an always-on agent, and a busy account running several routines a day exhausts the entire retained history inside a week. The more you use the headline feature, the less of it you can reconstruct.
There is no dry run, and an approval cannot undo one
Most tools that can act on your behalf offer a rehearsal: a plan you inspect before it runs, a diff you approve, a simulation flag. Grok Bot does not. The documentation is explicit that a test run performs real work, and that it can navigate websites, change files, and call connected tools.
Say that back in operational terms. Testing the routine that sends the weekly supplier email sends the weekly supplier email. Testing the one that updates the CRM updates the CRM. Testing the one that files the expense files the expense.
Approvals are prose, not policy
You can write "never send external messages without approval" into a Bot’s brief, and it will generally be respected. It is an instruction interpreted by a model, not a rule enforced by the platform. An Auto Review feature exists and is a model judging another model’s output, with per-device storage. Neither is a control you can demonstrate to an auditor.
An approval gate is upstream, not a rollback
Approving or declining stops the next action. It does nothing about the previous one. There is no undo for an action already taken on a live account.
The blast radius is the account, not the task
Because every Bot holds every session, an action taken in error is taken with whichever credential the machine happens to hold, not with a scoped permission attached to that task.
Deleting a Bot does not clean up
Offboarding is the part of any agent product that gets designed last, and it shows here. Deleting a Bot removes the Bot. It does not remove the shared files it wrote or the browser sessions it opened, because those belong to the machine and the machine belongs to the account. Independent reporting describes the cleanup as roughly six manual sign-out steps.
That matters in two ordinary situations. When an experiment ends, the credentials it collected are still live on a machine now being used for something else. And when a person leaves a team, deleting their Bots does not revoke what those Bots were signed into.
- Keep your own credential inventory. Write down every account you sign the machine into, because the product does not show you one.
- Sign out deliberately, service by service, when a Bot or an experiment ends. Deletion is not offboarding.
- Rotate on the service side. The reliable revocation for a session on somebody else’s machine is revoking it at the service, not deleting the agent.
- Prefer a fresh account over a fresh Bot when the trust level genuinely changes. The account is the boundary, so it is also the unit of disposal.
Prompt injection and the accountability sink
Two objections came up repeatedly on the launch thread and both are structural to the category rather than to this implementation. They still have to be answered by anyone approving it.
Prompt injection. An agent that browses the open web on a machine holding all your logins is reading untrusted text with the ability to act. As one commenter framed it: "Are you all comfortable with the idea of agents running non stop with access to all your accounts?… get hijacked via prompt injection." (dgellow) A long subthread rejected the argument that injection is largely solved, on the grounds that near-solved is not a useful category here: "having a system that fails every 40 attempts is outright catastrophic." (stymaar) Grok Bot’s architecture raises the stakes of a successful injection rather than the odds of one, because there is no per-Bot boundary to contain it.
The accountability sink. This one is underrated and gets to something a certification would not fix. A Bot does not act with an identity of its own. It acts inside your authenticated session, as you. Another commenter put the consequence sharply: "Grok bot snags your credentials and then pretends to be you whilst surfing the web. If it uses your account to post on X, is it adhering to X terms of service?" (SilverBirch)
Neither of these is an argument that always-on agents are unusable. It is an argument that the controls have to exist somewhere, and today they do not exist in the product, so they have to exist in how you scope the credentials and which work you allow near it.
Questions to put to xAI before you sign
If you are running the procurement conversation, these are the ones with no published answer as of 22 August 2026. Ask them in writing.
- What is the data retention period for files, browser sessions, and transcripts on the shared computer, and is it configurable?
- Where is the cloud computer physically located, and is a residency region selectable?
- Is there a SOC 2 Type II report, an ISO 27001 certificate, or a signed DPA available under NDA?
- When does the audit view ship, what does it record, how long is it retained, and can it be exported?
- What is the mechanism to revoke a single authenticated session without deleting the account?
- Is there any roadmap for isolating Bots from one another, or is one account per trust level the intended model?
- What is the incident process if a Bot is successfully prompt-injected while holding live sessions?
- Which entity is the data controller, xAI or Anysphere, and which terms actually govern, given that Grok Bot runs on Cursor’s infrastructure?
- Is there any process at all to unlink or move a Grok-to-Cursor account link, given the documentation says it is permanent?
- What is the weekly token allowance, in numbers, and is a spend cap on the roadmap?
The architecture that answers this differently
Every item on this page traces back to one decision: the work runs on a machine somebody else operates, holding credentials on your behalf, with the account as the only boundary. There is a different shape available, and it is worth stating what it does and does not fix.
If the agents run on hardware you already own, under logins you already hold, then residency is wherever your machine is, retention is your disk, the credential inventory is your own keychain, and the audit trail is your shell history and your git log. Nothing about that requires a vendor to publish a policy, because no third party is holding anything.
| Concern | Grok Bot | Agents on your own hardware |
|---|---|---|
| Where the work runs | A cloud VM xAI operates | A machine you own |
| Isolation between agents | None, by documentation | A git worktree per session |
| Who holds the credentials | The shared cloud machine | Your own keychain and CLI logins |
| Data residency | Not published | Wherever your machine is |
| Retention | Not published | Your disk, your policy |
| Audit trail | Transcripts plus 20 routine records | Your shell history, git log, and spend ledger |
| Gate before a write | Prose in a brief | A plan you approve before the agent writes |
| Spend cap | None | Weekly caps on the organization plan |
| Model choice | None. Undisclosed router | You pick, per session |
| Zero setup | Yes | No. You install and authenticate it |
The last row is the honest cost of the alternative and it should not be buried. Running your own machine is work: it has to be installed, authenticated, and awake. If nobody at your organisation will own that, a rented computer is the right answer and the questions above become the ones to press the vendor on.
Questions people ask
Is Grok Bot secure?
The credential handover is well designed: you do not send the password through chat; xAI says the Bot hands control to you. The trust model around it is coarse. All of your Bots share one cloud computer, the documentation states that separate Bots do not give separate security boundaries, and any login you enter is available to every Bot on the account, including ones created later. Whether that is secure enough depends entirely on what you sign it into.
Is Grok Bot SOC 2 compliant?
No published SOC 2, ISO 27001, GDPR, or HIPAA claim was found in the Grok Bot documentation set as of 22 August 2026. No retention period or data residency option is published, and compliance defers to Cursor’s terms rather than a separate xAI agreement. Enterprise access is a waitlist rather than a purchasable plan.
Does Grok Bot have an audit log?
There is no queryable organisation-wide audit view. The documentation describes an audit view as coming, in two places. What exists today is per-Bot chat transcripts, readable one Bot at a time, plus the twenty most recent routine records reported by Daily Dose of Data Science and unconfirmed by xAI. There is no export and no documented retention guarantee.
Can I isolate one Grok Bot from another?
No. The documentation states that all Bots share one persistent cloud computer, that they share files, browser sessions, and app logins, and that each Bot getting its own screen does not give it a separate security boundary. If you need isolation between two workloads, you need two accounts with two subscriptions.
Where does Grok Bot store my data?
On the persistent cloud computer attached to your account, and xAI does not publish where that is, how long anything is retained, or whether a residency region can be selected. For an organisation with a contractual obligation about processing location, that absence is the answer, and there is no configuration that changes it.
Can I test a Grok Bot routine without it doing anything real?
No. There is no dry-run mode. The documentation states that a test run performs real work: it navigates websites, changes files, and calls connected tools. Rehearsing an email send sends the email, and an approval prompt cannot reverse an action that has already happened.
What happens when I delete a Grok Bot?
The Bot goes. The shared files it wrote and the browser sessions it opened stay, because those belong to the account’s machine rather than to the Bot, with cleanup reported as roughly six manual sign-out steps. Deleting a Bot is not offboarding: revoke sessions at each service and keep your own inventory of what the machine has been signed into.
Can I undo the link between my Grok and Cursor accounts?
No. Cursor’s documentation states the link is permanent once created, that you cannot unlink a Grok account from a Cursor account, and that you cannot move a link to a different Cursor account. For a security review that is a governance question as much as a technical one: a personal subscription linked to a corporate account stays linked after the person leaves, and a later reorganisation cannot move existing links.
Whose infrastructure does Grok Bot actually run on?
Cursor’s, not xAI’s. That matters for due diligence because the entity operating the shared machine that holds your credentials is not the one whose name is on the product. SpaceX’s acquisition of Cursor’s maker, Anysphere, was announced on 16 June 2026 and closed on 14 to 15 August 2026, three to four days after Grok Bot launched.
Why is Grok Bot blocked in my organisation?
The most likely reason is Cursor Legacy Privacy Mode, which blocks Grok Bot entirely because the product requires data storage. Since every access path runs through a Cursor account, a Cursor-side policy decision can remove the product regardless of which xAI or Cursor plan you hold.
Sources
Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.
- Grok Bot overview, docs.x.ai the shared cloud computer, per-Bot screens, memory, routines, connectors, credential handover
- Grok Bot get started, docs.x.ai eligible plans, Cursor sign-in requirement, platform downloads, first-run steps
- eesel AI: Grok Bot review metering behaviour, compliance gaps, no dry run, audit view described as coming
- Daily Dose of Data Science Grok Bot numeric ceilings reported by Daily Dose of Data Science; unconfirmed by xAI: 50 Bots, 50 routines, 20 run records, 10-minute demonstration cap, 2 to 6 Bots per group chat
- Hacker News: the Grok Bot launch thread launch-week reception, trust and prompt-injection objections, the Linux download report
- xAI: Introducing Grok Bot launch date, beta status, positioning, enterprise waitlist
- Cursor pricing which Cursor tiers carry Grok Bot, and the Teams seat price