Home › Answers › Grok Bot in a company

Grok Bot in your company: what IT, auditors and the GDPR will ask

Transparency. We maintain Cortex Gateway, an open-source access layer relevant to the fix below. Facts about Grok Bot are taken from xAI's announcement and its teams & enterprises documentation, checked 17 August 2026. This analysis rests on the published documentation — we have not hands-on tested the beta, and runtime details (credential storage, session handling, logging) could differ. Grok Bot is in beta and enterprise access is waitlisted — details will change; corrections welcome as a GitHub issue. Same series for Hermes Agent and OpenClaw. Cette page existe en français.

What Grok Bot is — and why the pitch is the risk

Grok Bot is a team of always-on agents, each working on a persistent cloud computer, available to SuperGrok Heavy, Cursor Ultra and Cursor Teams Premium subscribers. Its differentiator is precisely what makes governance hard: a bot navigates websites, clicks buttons and types into fields the way a human would, signing into the tools the employee already uses with the employee's own credentials — including "legacy enterprise software" with no clean API or MCP. It keeps working while the laptop is off, and bots can coordinate with each other in group chat.

Hermes and OpenClaw raise VPS questions because installers deploy them wrong. Grok Bot raises them as designed: the credential handling, the unsupervised execution and the cloud residency are the product. The questions below are therefore for IT and security leadership, not for installers.

What xAI got right — credit where due

• Per-member computers, which admins can inspect and remove; members can self-reset.
• Hardware keys survive: WebAuthn prompts are forwarded to the member's desktop app, so phishing-resistant factors are not simply broken.
• MCP done properly: Grok Bot inherits the team's existing MCP configuration and allowlist/denylist policy, and sign-in tokens for hosted MCP servers stay with the Cursor backend, not stored on the computer.
• Org-wide controls for Cursor Teams admins: disable Grok Bot entirely, toggle cloud-agent launching, scope team rules; Privacy Mode (Legacy) blocks Grok Bot outright.
• Training follows team privacy settings, same as Cursor's.

These are real controls. The findings below are what they do not yet cover — much of it stated by xAI's own documentation.

The audit grid, applied

The fifth row deserves emphasis because it is self-inflicted on day one: an organization enforcing device-trust either blocks the bots (and users route around IT), or punches an exception for a cloud VM it does not manage. Both outcomes appear in the next audit.

The shadow-IT multiplier

Everything above assumes the company knows the bots exist. Grok Bot is also sold through SuperGrok Heavy — a consumer subscription. An employee can create a bot on a personal account, hand it their work logins, and produce an always-on ghost worker IT has never heard of, exercising corporate credentials from an unmanaged VM. Enterprise onboarding is waitlisted; personal onboarding is not. Policy, detection (impossible-travel and datacenter-IP sign-in alerts) and an approved alternative are the only levers — a ban with no sanctioned path is how the personal-account version proliferates.

The GDPR angle

Everything the bot sees transits and persists on a US provider's cloud VM. Screens, documents, mailboxes — processing of employee and customer personal data on xAI/Cursor infrastructure, to inventory under Art. 30 and assess under Chapter V (transfers). The Grok Bot documentation we checked states nothing about data residency, a DPA, or SOC 2 for this product; until the enterprise tier ships terms, that absence is the answer to put in the DPIA.

"Durable storage is kept." Killing a bot deletes the VM but not its durable storage — a retention and erasure (Art. 5(1)(e), Art. 17) question with no documented deletion path yet.

Training follows team privacy settings — which means for personal-tier usage, whatever the individual's settings say. A DPIA for sanctioned use, and the assumption of unsanctioned use, are both warranted (Art. 35, Art. 32).

The fix: make the MCP lane the only lane for company data

The remarkable thing in xAI's documentation is that the governed path is already built in: Grok Bot follows your team's MCP policy — allowlists, denylists, shared MCP authentication with Cursor, hosted-server tokens kept off the VM. The browser-credential lane and the MCP lane coexist; governance means moving company data to the second:

• Expose company tools as MCP servers behind one OAuth 2.1 gateway — a ~120-line contract per app, or an integration backend for third-party APIs. Allowlist the gateway in the team MCP policy; denylist the rest.
• Each employee's bot then acts on a scoped, per-user OAuth grant, not their passwords: least privilege becomes scopes, and bot actions become distinguishable from human ones — the attribution the "coming" audit view cannot provide.
• Every call writes one attributable audit line on your infrastructure — no waiting on a vendor roadmap for A.8.15.
• Revocation returns to one act: cut the grant, and the bot's access to every backend dies with it — no password-rotation hunt, regardless of what the durable storage kept.

To be clear about our interest: any spec-compliant OAuth 2.1 MCP gateway provides this lane — we compare the open-source options honestly, and Cortex is the one we maintain. The architecture is the recommendation; the product is a choice.

What remains in the browser lane — legacy tools with no API — remains ungoverned by construction; that residue is a risk-acceptance decision to write down, not a detail to discover in an incident. The controls-to-frameworks mapping is on AI agent compliance controls; the threat-model side on MCP security best practices.

FAQ