Grok Bot approvals, security, and privacy

Sources

Set a boundary in the request

Tell the Bot what it may do and where it must stop. Official examples emphasize: draft and recommend first; do not send, publish, purchase, delete, change permissions, change production, or accept legal terms without approval.

Known: An approval controls the proposed action. It does not reverse work already completed.

Review an action

When approval is required, the conversation shows the proposed operation and inputs. Review target, scope, and values before approving.

• Desktop: Allow once · Deny · Always allow (can save a matching rule)
• iPhone / Android: Auto-review sheet — Allow · Deny · Always allow when a rule is proposed

Do not approve an action whose target or effect you cannot identify.

Auto Review

With Auto Review on, Grok Bot evaluates tool calls and computer actions before they run. Settings path per docs: Settings → General → Bot → Auto-review.

• Ask first rules always stop matching actions for you.
• Allow automatically rules let matching actions proceed only when automated review finds no other reason to stop.
• If both match, Ask first wins.
• Team-enforced rules (Enterprise) can appear locked; personal rules may only make behavior stricter.

Write narrow rules (e.g. ask first before external email). Avoid “allow everything in the browser.” Auto Review is model-based and complements — does not replace — least privilege and explicit boundaries.

Known vs unknown: Exact coverage of every side effect is limited (docs note examples like memory writes / some settings may not be reviewed). Treat as one layer among several.

Secrets and takeover

Passwords, passkeys, 2FA, CAPTCHAs, payment confirmations → take control of the computer; do not paste into ordinary chat. For supported connections, use the secure secret request (masked; excluded from transcript/model). Hardware security keys: product settings exist on some platforms (docs: default on for macOS/Windows; Linux not yet — verify live).

Shared-computer boundary

All of your Bots share one cloud computer. Files, browser sessions, and CLI credentials are available across your roster.

• Do not use separate Bots as a security boundary.
• Sign out when access should end; remove sensitive temp files; revoke connectors in the source service.
• Deleting a Bot does not remove shared-computer files or browser sessions.

Product framing for that shared computer is in What is Grok Bot?.

Sharing a Bot is not a security boundary

A public share link lets others copy configuration. It does not share your computer or logins. Still: no secrets, customer data, or internal URLs in a Bot you share. Adding accepts third-party bot terms (as-is; SpaceXAI does not verify/endorse/guarantee third-party bots).

Local computer

Separate from the cloud computer. Policy: Ask every time (default) · Always allow · Never allow. Docs recommend Never allow unless there is a specific reason. Team admins can cap the policy; stricter wins.

Privacy / account (known)

• Grok Bot requires cloud data storage; Legacy Privacy Mode is not supported (blocks Grok Bot).
• Privacy and training follow applicable Cursor account / team settings.
• Do not invent DPA or residency claims here — see official security / Privacy and Data Governance pages; Grok Bot computers run in the United States today per security docs (not the same as Cursor US-only residency by default).

Teams (article type — admin pointer)

From teams-and-enterprises and security:

• Teams: Grok Bot included; enabled by default for members (blocked by Legacy Privacy Mode / some legacy plans).
• Enterprise-only examples: org-wide enable switch, Network Controls, Team Setup, Enforce Auto-review + team rules, Action Recording, Audit logs, OpenTelemetry Export, SCIM, computer management for org admins, MCP allowlist.
• Self-serve Teams often do not see those panels (e.g. no destination allowlist → default allow-all without a policy).
• Recommended baseline themes: network policy where available, connector audit, enforce Auto-review before relying on team rules, cap local execution, disable Cloud Agent spawn if unused, keep public template sharing off unless intended.

A dedicated Teams page is planned later; this draft carries the Teams article-type coverage for first-run. No /learn/teams route is added in this pack.

Least privilege (official checklist themes)

Connect only needed tools · scoped service accounts where supported · start read-only / drafts · keep send/publish/purchase/delete/production behind approval · review connectors and routines · pause routines when sources change · keep source links / action logs for important decisions.

Clash flags

Stance and shop truth: How Botski fits as a third-party workshop.