Grok Bot for Teams and Enterprise admins: rollout checklist, admin controls, and safe defaults (unofficial guide)

The short answer

On a self-serve Cursor Teams plan, Grok Bot is on by default for every member, with no admin switch to turn it off. On Enterprise, an admin turns it on from the Grok Bot page of the Cursor dashboard and can limit it to specific groups. Members never see that page.

Before members start, the official docs recommend a short baseline: audit which connectors your team allows, set Execution on Local Computer to Never allow unless Bots need to act on member machines, turn off Cloud Agent delegation if you don't need it, and keep public template sharing off. Enterprise teams should also set Network Controls, turn on Enforce Auto-review, and add team Auto-review rules.

This guide is independent and unofficial. It isn't affiliated with or endorsed by xAI, Grok, or Cursor. Admin settings change often, so check the linked docs before you rely on any one control.

Who gets Grok Bot on Teams and Enterprise

Per the official Teams and Enterprises page: individuals get Grok Bot with every paid Cursor plan or an individual SuperGrok link. On Teams it's included, every member has access, and usage follows each seat's allowance. On Enterprise, you enable it for your team from the dashboard.

Two things keep it off even on Teams: Privacy Mode (Legacy) and a legacy request-based plan. The docs say Privacy Mode (Legacy) "blocks Grok Bot entirely," so move off it first.

Several controls are Enterprise only and don't appear for self-serve Teams at all: the organization-wide enable switch, SCIM, Network Controls, Team Setup, Team Secrets, Allow Local Egress Routing, Allow Sudo on Bot Computers, Action Recording, Enforce Auto-review, Auto-review rules, audit logs, OpenTelemetry Export, group settings, and bulk computer management. If your security review needs any of those, you need Enterprise.

There's no separate Grok Bot spend cap today. Per the docs FAQ, account-level on-demand controls apply, and the per-product split is on the dashboard usage page.

Pre-rollout checklist

1. Move off Privacy Mode (Legacy). Check it in Team Settings. You're prompted to change it before enabling.

2. Audit your connector policy. Grok Bot inherits your team's Cursor connector policy, and there's no separate Grok Bot connector list. Any connector you permit is available to every Bot a member runs. Set it in your Team Marketplace on the dashboard's Plugins & MCPs page. The MCP allowlist is Enterprise only.

3. Write a few Team Rules. Rules scoped to Grok Bot are always required, so members can't turn them off. The docs suggest keeping them short and few, like "never move company data to personal accounts."

4. Clear your network path. If member devices sit behind Zscaler or another TLS-inspecting proxy, allow Cursor's domains, including the nested *.*.cursorvm.com pattern, and exempt them from inspection. If your company restricts services by source IP, plan for Cursor's static egress IPs.

5. Decide how members sign in to company tools from the Bot's computer. Members sign in with their Cursor account, so your existing SSO and (on Enterprise) SCIM setup carries over. A device-aware sign-in policy in your identity provider gates sign-in, not the hosted computer itself.

6. Invite people. Admins on either plan can use Invite Team on the Grok Bot page. Existing Cursor users get an email with a download link, and new users get a team invitation that also points them to Grok Bot. To push the apps with your own device management tools, see the docs' Deploy Grok Bot to your organization page.

How it works, in one paragraph for your security reviewer

Grok Bot runs in Cursor's cloud. Each user's work runs on a dedicated Firecracker microVM with hardware-level separation, so one user can't reach another's computer. The desktop and mobile apps are thin clients for chat, review, and approvals. A Bot has no access by default and uses only the accounts and plugins the user or team grants. OAuth tokens stay on Cursor's connector backend, and Bots call tools without receiving them. Sensitive actions go through approval, checked by an independent review model called Auto Review. With Privacy Mode on, the docs say customer data isn't used for training.

The boundary to explain to members: all of one user's Bots share that user's one computer. The docs say Bots "isolate personalities and workspaces, not compute." A login or file on the computer is available to every Bot that person runs. When a workload needs its own computer and credentials, give it its own Cursor user.

Admin controls on Teams and Enterprise

These are on both plans, mostly on the Grok Bot page of the Cursor dashboard:

Team Rules: required guidance every member's Bots follow, scoped to Cursor, Grok Bot, or both.

Cloud Agents: allows or blocks Bots delegating coding tasks to Cursor Cloud Agents. On by default. Turn it off if your team doesn't need delegation.

Agent Email: lets members claim an agent email address and lets their Bots read and send mail from it. Off by default, and members get no email tools until you turn it on. Turning it off later removes the email tools and stops email routines.

Public template sharing: controls whether members can publish Bot templates outside your team. When it's off, Cursor enforces team-only sharing on its servers, "including for templates that are already public." Enterprise starts with it off; other teams start with it allowed.

Execution on Local Computer: caps what Bots can do on a member's own machine through the desktop app. Choose Always allow (the default, which leaves it to each member, whose own setting defaults to asking), Ask every time, or Never allow. A member's stricter setting still applies.

Connector policy: inherited from your Team Marketplace. A blocked connector shows up for members as Disabled by team admin. Pushing connectors to members, mandatory or default-on, isn't available.

Enterprise-only controls

Enable Grok Bot and Manage Group Access: the organization-wide switch. Turning it off blocks every member without deleting their computers.

Network Controls: three modes, Allow All Network Access, Defaults + Team Allowlist, or Team Allowlist Only. Teams without a policy default to allow-all. Groups can carry their own policy, and Lock for All Groups applies the team policy to everyone.

Enforce Auto-review and Auto-review rules: Enforce stops members from turning Auto-review off. Team Ask first and Allow automatically rules apply on top of each member's own rules, members can see but not edit them, and Ask first wins on conflict. Turn on enforcement before you rely on the rules.

Team Setup and Team Secrets: install scripts that run on every team computer, with secrets passed to those scripts as environment variables. Limits are up to 100 secrets per team, 32 KB per value, and 96 KB total. Team Secrets only reach your scripts, not the Bots directly, and they're separate from secrets members store on a Bot.

Allow Local Egress Routing and Allow Sudo on Bot Computers: both on by default. Turning off egress routing stops active routes within five minutes. A sudo change needs existing computers restarted.

Action Recording and OpenTelemetry Export: Action Recording logs what Bots did as sanitized metadata (tool calls, approval decisions, shell commands, browser navigations, routine runs, and more), without message bodies or tool arguments. You receive it through OpenTelemetry Export, tagged cursor.surface=grok_bot. Conversation content export is a separate opt-in that also streams prompts, responses, and, if you turn on Tool I/O, hosted connector arguments and results.

Audit logs: admin, security, and Grok Bot control-plane events, such as Bot creation, access changes, Team Setup manifests, MCP authentication, Slack links, and routines.

Manage Bot Computers: organization admins can recreate or terminate many members' computers at once, and Terminate Inactive Computers can do it after 30 days without use (off by default). Neither removes access. To remove access, remove the member or turn off Grok Bot for their group, and revoke their sessions in your identity provider.

Group settings: a group's Grok Bot tab can only widen the team baseline, never tighten it, and a member in several groups gets the most permissive result. Network is the exception, where a member of several groups gets the most restrictive policy. So tighten on the Grok Bot page and widen per group.

Most of this is also scriptable through Cursor's Admin API, except Team Secrets, which are dashboard only.

Managing Team Bots as an admin

A Team Bot is one Bot a member owns and shares with your Cursor team. Each person's chat with it is private, and the owner can't read it. Per Cursor's help center, a reply uses the Grok Bot usage of the person it's answering, and a connected account always acts as that person, so one teammate's connection is never used for someone else.

Admins manage them from the Grok Bot page of the Cursor dashboard under Team Bots, then Manage Team Bots. Access shows who can use each Team Bot, and you can change it there. Auto-add puts a Bot in members' sidebars for the whole team or chosen groups, and those members can't hide it.

If a Team Bot is added to Slack and the row says Awaiting admin approval, a Slack workspace admin has to approve the app. Each teammate also links their Slack account under Settings, General, Team Bots.

For how members create, publish, and share Team Bots, see our guide to sharing a Bot with template links and Team Bots.

A sensible first week (our suggestion)

Day 1: apply the baseline below, then pick three to five volunteers rather than the whole company.

Days 2 to 4: have them start with read-only tasks and drafts, which the docs recommend for new roles: research, a morning briefing, meeting prep, and inbox triage that drafts but never sends.

Day 5: publish one Team Bot that answers questions from your internal docs, and auto-add it for the pilot group. Review what got approved and denied, and on Enterprise, what Action Recording shows.

Then widen access by group, and write down which tasks stay behind approval: sending external email, payments, production changes, and accepting legal terms are the docs' own Ask first examples.