Grok Bot Team Rollout: Take AI Teammates From One Inbox to the Whole Team

You have a personal Grok Bot. It answers questions, drafts messages, pulls metrics from your data warehouse, and keeps working when your laptop is closed. Now your team wants the same capability. The question is not whether to roll out Grok Bot to your team. The question is how to do it without creating a mess of shared credentials, unclear ownership, and conversations that leak context across the wrong boundaries.

A personal Bot helps one person. A team rollout fails when you copy personal habits to a team. Grok Bot gives teams specific building blocks: Team Bots that everyone talks to in private chats, each conversation acting with the asking person's own access for OAuth plugins, owners and managers who maintain shared setup, plugins and secrets and skills and files that apply across every conversation, Slack apps per Team Bot, and admin controls that let you set connector policy, execution rules, Auto-review enforcement, network boundaries, and audit what happened. Operators who get value roll out deliberately with an ownership map, a phased pilot, a written access model per plugin, Slack rules, and a review cadence with clear measures.

This playbook covers going from personal Bots to team infrastructure. You will learn why personal-Bot habits break at team scale, what to check before anyone gets a Team Bot, how to build an ownership map and choose the first shared job, how to model access for plugins and secrets, how to bring a Team Bot to Slack without leaking context, which admin controls to configure on Teams and Enterprise plans, how to track usage and audit what Bots did, a phased rollout plan with exit criteria for each phase, what to measure in a rollout scorecard, and how to handle offboarding and change control. We assume you already understand the foundations covered in the Grok Bot for operators playbook: give each Bot one clear job, the difference between skills and routines, Auto-review basics, and shared-computer hygiene for one person. This post is about the team.

Why Personal-Bot Habits Break at Team Scale

A personal Bot lives on your cloud computer. All of your Bots share one computer with a browser, filesystem, and terminal. Files, browser sessions, logins, and command-line credentials are shared across your Bots but isolated from other users. Screens are separate work surfaces, not security boundaries. The Bot's memory is about you. When you teach a skill, it applies to your conversations. When you set up a routine, it runs as you and reports in your chat.

A public template is a snapshot you share. Someone adds your template and gets a copy with the profile, description, skills, and routines you published. They do not get your computer, your logins, your conversation history, or your memory. The copy is maintained separately by each person.

A Team Bot is one Bot the whole team talks to. The owner sets it up once with plugins, secrets, skills, and files, then publishes it to the team. Teammates find it under New chat and talk to it in the Grok Bot app or Slack. Every conversation is private: each teammate gets their own chat, and the owner cannot read teammates' chats. The Bot acts as the person asking. An OAuth plugin uses the account of whoever is talking, so the Bot never lends one person's access to another. The owner and any managers maintain the setup, and changes reach everyone. Routines stay personal: they belong to whoever set them up, run as that person, and report in their chat. There is no routine that runs for the whole team. To share output, the routine posts the result somewhere shared, such as a Slack channel.

The differences matter operationally. A personal Bot with a broad plugin and your admin credentials is a risk you own. A Team Bot with the same setup is a risk the whole team owns, because every teammate can ask the Bot to use that plugin with those credentials. A skill you teach your personal Bot stays with you. A skill the owner or a manager saves to a Team Bot applies in every teammate's conversation. A routine you set up on your personal Bot runs on your computer and counts against your usage allowance. A routine you set up on a Team Bot is still yours: it runs as you, reports in your chat, and counts against your allowance.

Personal-Bot habits that work for one person break at team scale. Shared credentials become everyone's credentials. Unclear owners mean nobody maintains the Bot's skills or rotates secrets. Broad connectors mean every teammate can ask the Bot to act in systems that should be restricted. No plan for Slack channels means the Bot answers in threads where the whole channel can see context that should stay private. No usage tracking means you do not know who is asking what or whether the Bot is doing the job you designed it for.

Pre-Flight Checklist Before Anyone Gets a Team Bot

Before you create the first Team Bot, check your account and network configuration. These items determine whether Grok Bot will work for your team and whether you have inherited policies that will apply to every Bot.

First, move off Privacy Mode if your team is on the legacy version. Privacy Mode blocks Grok Bot entirely. On the Teams plan, Grok Bot is enabled by default for every member and there is no switch to turn it off. It stays off for teams on Privacy Mode (Legacy) or a legacy request-based plan. Enterprise plan requires an admin to turn Grok Bot on from the Grok Bot page of the Cursor dashboard and can limit access to specific groups with Manage Group Access. Turning it off blocks members without deleting their computers.

Second, plan for egress IP addresses if your company restricts access to internal services by source IP. Grok Bot computers share egress addresses. If you need static egress IPs for allowlisting, plan that before the rollout.

Third, clear your network gateway. If member devices sit behind a TLS-inspecting proxy such as Zscaler, allow Cursor's domains and exempt them from inspection before members connect.

Fourth, decide how members will sign in to company tools from the Bot's computer. The computer has a browser. The Bot hands login, two-factor authentication, and payment steps to the person rather than working around them. On Enterprise, SSO and SCIM carry over and identity setup is documented. Document this decision because it affects which plugins you choose and how you write skills.

Fifth, audit inherited policies. Team Rules apply to every member's Bots. The team's connector policy for Cursor also applies to Grok Bot; there is no separate Grok Bot connector list. On Enterprise, check whether you have team Auto-review rules or an MCP allowlist. These policies are inherited by every Bot, personal and Team Bot alike.

Sixth, check your plan's Grok Bot defaults. On Teams, Grok Bot is enabled by default for every member, and usage counts against each seat's allowance. On Enterprise, an admin must enable it. A separate Grok Bot spend cap is not available today; account-level on-demand controls apply, and you can see per-product usage split on the dashboard. Availability and controls can change, so check the current plans page before you roll out.

Seventh, invite your team if you have not already. Admins can bring members in with Invite Team on the Grok Bot page. SCIM-managed teams see only the existing-users option. Device management deployment is documented separately.

Build an Ownership Map Before You Create the First Team Bot

A Team Bot without a clear owner becomes nobody's responsibility. Skills drift, secrets expire, plugins pile up, and teammates do not know who to ask when the Bot gives a wrong answer. Before you create the first Team Bot, write down who owns it, who the managers are, who approves new plugins and secrets, and who reviews team memory.

The owner is the person who created the Team Bot or who published it from a personal Bot. The owner can change the Bot's profile, skills, plugins, secrets, and Slack app. The owner can publish, unpublish, and delete the Bot. Unpublishing removes access temporarily; chats and routines come back when the Bot is republished. Deleting removes the Bot for the whole team, including all teammates' chats and routines, and cannot be undone. Besides the owner, a team admin can delete a Team Bot from Manage Team Bots.

Managers are people the owner adds after publishing. A manager can change the setup: profile, skills, plugins, secrets, and Slack app. Managers cannot publish, unpublish, or delete. The documentation does not describe transferring ownership, so pick an owner who is likely to stay with the job, add at least one manager, and plan for the case where the owner leaves. Managers keep maintaining setup; publishing, unpublishing, and deleting stay with the owner; an admin can delete from Manage Team Bots; recreating the Bot under a new owner is the fallback.

Approvers are the people who will answer approval requests when a Bot asks for permission to take an action. In a one-on-one chat, the person talking can approve. In a Slack thread or group chat, approval cards do not appear in group conversations the way they do in a 1:1 chat, so do not count on an approval card to stop a channel conversation. Scope the Bot's shared plugins and secrets so anything it can do unattended is acceptable, and on Enterprise turn on Enforce Auto-review so the team requires it.

Plugin and secret approvers are the people who decide whether a new plugin or secret should be added to the Team Bot. This is a business decision, not a technical one. A plugin gives every teammate the ability to ask the Bot to act in that system. A secret gives the whole team access to whatever that credential can reach. Document who makes these decisions for each Team Bot.

Memory reviewers are the people who periodically ask the Team Bot what it remembers about the team and check whether any private information has been saved as team memory. Team memory is saved only when someone explicitly says the whole team should have it, and the Bot tells you when it saves something. Still, review it regularly.

Here is a sample ownership map for a hypothetical 18-person company with three Team Bots. This is an example, not a prescription. Your map will differ based on your team structure and the jobs you assign to Team Bots.

• Helpdesk Bot: Answers internal IT and HR questions from a knowledge base. Owner: IT lead. Managers: HR lead, office manager. Plugin approver: IT lead. Secret approver: IT lead. Memory reviewer: IT lead, monthly. Slack channels: #it-help, #hr-questions. Approval boundary: read-only and drafts in channels; anything that writes stays behind approval.

• Metrics Bot: Answers questions about revenue, usage, and pipeline from the data warehouse. Owner: finance lead. Managers: revenue operations lead. Plugin approver: finance lead and CEO. Secret approver: finance lead. Memory reviewer: finance lead, bi-weekly. Slack channels: #metrics, #leadership. Approval boundary: read-only and drafts in channels; anything that writes stays behind approval.

• Request Triage Bot: Reads inbound requests in a Slack channel, categorizes them, and posts a summary. Owner: customer success lead. Managers: support lead. Plugin approver: customer success lead. Secret approver: customer success lead. Memory reviewer: customer success lead, weekly. Slack channels: #customer-requests. Approval boundary: read-only and drafts in channels; anything that writes stays behind approval. Routine: customer success lead's routine posts summary every morning.

Write your ownership map in a shared document before you create the first Team Bot. Update it when you add a manager, change a plugin, or hand off ownership. This document is the source of truth when someone asks, "Who maintains this Bot?"

Choose the First Team Bot and Its One Shared Job

The first Team Bot should do one shared job that multiple people need and that does not require deep personal context. Good candidates from the documentation include answering metrics questions from a data warehouse, keeping documentation current as pull requests ship, triaging requests in a Slack channel, or running an internal helpdesk from a knowledge base. Bad candidates include personal assistants that read your email, manage your calendar, or draft messages from your own accounts. Keep personal assistants personal.

You have two ways to create a Team Bot. You can create a new one from scratch, or you can publish an existing personal Bot to the team. Creating new is straightforward: open New chat, choose Create new Team Bot, and the Bot will ask what the team needs and walk you through plugins, secrets, skills, and files. Until you publish, only you see it.

Publishing from a personal Bot is useful when you have already built and tested a Bot for yourself and want to share it. Go to the Share menu and choose Publish to Team. You will choose what the team copy gets: plugins, secrets, memories, skills, files, and routines. Memories you do not pick stay private. Routines only run for you; they do not transfer to the team. If you want the team to have a similar routine, a teammate will need to set up their own after the Bot is published.

In the Bot's details, set a description of up to 140 characters. Write it in the Bot's voice, as if the Bot is introducing itself. For example: "I answer questions about our Datadog alerts and link to runbooks." Or: "I triage customer requests in Slack and route them to the right person." This description appears when teammates browse Team Bots, so make it clear what the Bot does and does not do.

The setup cards you fill out during creation or publishing become the Bot's shared configuration. Plugins on a Team Bot are shared and used in every conversation without asking again. Secrets are available to the Bot in any teammate's conversation; the Bot and teammates never see the secret values, only [REDACTED] in output. Skills apply in every teammate's conversation. Files are shared reference material. Team memory is saved only when someone says the whole team should have it.

After you publish, teammates find the Bot under New chat, in the Team Bots section. You can also copy a link to the Bot and paste it in Slack or email. Teammates can pin the Bot, hide it, or set up their own routines. They cannot delete the Bot or change its setup unless you make them a manager.

The Access Model: Plugins, Secrets, and Personal Connectors

A Team Bot's access model determines who can do what in which systems. Get this wrong and you either give everyone admin access to production, or you lock the Bot down so tightly that it cannot do its job. The Grok Bot Team Bots documentation describes four types of access, and you need to understand all four.

First, OAuth plugins. When you add an OAuth plugin to a Team Bot, each teammate connects their own account the first time they ask the Bot to use that plugin. The Bot acts as the person asking. If you connect your GitHub account and I connect mine, the Bot reads your repositories when you ask and my repositories when I ask. The Bot never lends your access to me. This is the right model for plugins where each person should act with their own permissions, such as ticketing systems, code repositories, or project management tools.

Second, key or token plugins. When you add a plugin that uses an API key or token, you provide one credential, and the Bot uses that credential in every conversation with every teammate. This is the right model for read-only access to shared systems, such as a data warehouse, a monitoring dashboard, or a knowledge base. Use a scoped, read-only service account key. Do not use your personal admin key. The Bot can use every secret in any teammate's conversation, so treat a secret as access you are giving the whole team. You can add up to 25 secrets per Team Bot. If the Bot needs a secret that is missing, it will send a secret request in the owner's or a manager's chat.

Third, custom MCP Remote HTTPS connectors. A Remote HTTPS connector connects to a remote server over HTTPS. It can use the Bot's credential, the same for everyone, or it can use OAuth so each person connects their own account. The access model is the same as above: Bot's credential for shared read-only access, OAuth for per-person permissions. When a custom server needs secrets, the documentation recommends Remote HTTPS rather than a Command server.

Fourth, custom MCP Command connectors. A Command connector runs on whichever computer the conversation uses. In the owner's chat, it runs on the owner's computer. In a teammate's app chat or one-on-one Slack DM, it runs on that teammate's computer. In Slack channels, group DMs, and threads, it runs on one shared computer for that Team Bot. Command connectors must never hold credentials in their command line or arguments. If a Command connector needs a credential, rewrite it as a Remote HTTPS connector and use a secret.

Teammates can also bring their own connectors, called personal plugins. In a one-on-one chat, a personal plugin is used without asking. In shared conversations such as a Slack thread or group chat, the Bot asks first: Allow once, Always allow for this Bot, Always allow for all Team Bots, or Skip. The card goes to the person whose connector it is and says which account it will use. To undo remembered answers, go to Settings, General, Team Bots and choose Clear.

Here is a worked example for a hypothetical Metrics Bot. The team wants to answer questions about application performance and customer tickets. The performance data lives in a monitoring system with an API. Customer tickets live in a ticketing system where each person has their own account and permissions.

For the monitoring system, you create a read-only service account in the monitoring tool, generate an API key, and add it as a secret to the Metrics Bot. You install the monitoring plugin on the Team Bot and configure it to use that secret. Now every teammate can ask the Metrics Bot for performance metrics, and the Bot reads from the monitoring API using the read-only key. Nobody gets write access. Nobody sees the key value.

For the ticketing system, you install the ticketing plugin on the Team Bot but do not add a secret. The plugin uses OAuth. The first time a teammate asks the Metrics Bot a question that requires reading tickets, the Bot prompts them to connect their ticketing account. They sign in, grant access, and the Bot reads tickets they have permission to see. Another teammate connects their own account and sees their own tickets. Each request runs with the asking person's own permissions. In a Slack channel thread, remember that everyone in the thread can read the Bot's reply.

This access model is documented in the ownership map. For each plugin, write down whether it uses OAuth, a shared secret, or a custom connector, and what scope the credential has. For secrets, write down who created the service account, when the key expires, and who is responsible for rotating it. This documentation is the difference between a Team Bot you trust and a Team Bot you are afraid to use.

Skills, Files, and Team Memory as the Shared Playbook

A Team Bot's skills, files, and team memory are the shared playbook. Skills are repeatable how-tos: qualify a lead, triage an alert, write release notes, check a deployment. Files are reference material: playbooks, FAQs, schemas, lists of approved vendors, support macros. Team memory is context the whole team should have: the name of the new product, the launch date, the format for a weekly report. Together, these three things encode what the team knows and how the team works.

Skills apply in every teammate's conversation. Only the owner or a manager can save a team skill. When a teammate teaches the Bot a process, it stays in that person's private notes unless the owner or a manager explicitly saves it as a team skill. This is by design. A team skill is a commitment that this process applies to everyone. Do not save a skill until you have tested it in a few conversations and confirmed it works reliably.

Files are shared reference. The Bot can read .txt, .md, .markdown, .csv, .json, .yaml, and .yml files up to 256,000 characters per file. Use files for content that does not change often and that multiple teammates need. Examples: a knowledge base of support articles, a schema for the data warehouse, a list of runbooks, a glossary of internal terms, a set of approved message templates. Do not put credentials, customer data, or personal information in files. Files are shared with every teammate who talks to the Bot.

Team memory is saved only when someone explicitly says the whole team should have it, and the Bot tells you when it saves something. Use team memory for facts that apply to everyone and that change occasionally: the name of a new feature, the date of the next release, the format for a report, the contact for a vendor. Do not use team memory for personal preferences, private notes, or temporary context. Periodically ask the Bot what it remembers about the team and review the list. If something should not be there, tell the Bot to forget it.

Here is a sample file pack for a hypothetical Helpdesk Bot that answers internal IT and HR questions. This is an example; your file pack will differ based on the Bot's job.

• it-runbooks.md: A list of common IT issues and their solutions. Password reset, VPN setup, software installation, printer troubleshooting. Each runbook includes the steps to resolve the issue and the contact to escalate to if the steps do not work.

• hr-policies.md: Summaries of HR policies. Time off, expense reimbursement, remote work, equipment requests. Each summary includes the policy, the approval process, and a link to the full policy document.

• office-contacts.csv: A list of office contacts. IT lead, HR lead, office manager, building security, mail room. Each row includes the person's name, role, email, Slack handle, and phone number.

• faq.md: Frequently asked questions that do not fit in the other files. How to book a conference room, how to order business cards, how to submit a purchase request, how to report a security issue.

When you add files to a Team Bot, write a short note in the Bot's description or in a team skill that explains what the files contain and when to use them. For example: "I reference the IT runbooks and HR policies files to answer your questions. If I can't find the answer, I'll tell you who to contact."

The combination of skills, files, and team memory is the Bot's shared context. Maintain it deliberately. When a teammate asks a question and the Bot gives a wrong answer, check whether the answer is in a file, a skill, or team memory. If it is, update the content. If it is not, decide whether it should be. If the question is common and the answer is stable, add it. If the question is rare or the answer changes frequently, leave it out and let the Bot ask a human.

Bring the Team Bot to Slack Without Leaking Context

A published Team Bot can have its own Slack app. The app is named after the Bot and uses the Bot's avatar. The Bot posts as itself in Slack channels and DMs. This is powerful and risky. Powerful because teammates can ask questions in Slack without switching to the Grok Bot app. Risky because a Slack thread is visible to everyone in the channel, and the Bot's answers can leak context that should stay private.

To add the Team Bot to Slack, the Bot must be published first. The owner or a manager opens the Bot's details and chooses Bring to your team's Slack. When a manager adds it, the setup uses the owner's Slack connection, so the owner connects Slack first. They connect the Slack workspace, pick the workspace from the list, and the app is created and installed. The Bot sends a welcome DM in Slack. The owner or manager then invites the Bot to channels with /invite @BotName. The Slack admin approval flow may require an admin to approve the app before it can be installed. Some Slack workspaces have app-approval automations that auto-approve. If the app is awaiting admin approval, the owner or manager can check approval status, resubmit the request, or cancel it.

In Slack, the Bot behaves differently in DMs and channels. In a DM, the Bot answers every message. In a channel or group DM, the Bot answers only when someone @mentions it, then follows the thread. The Bot ignores top-level messages in a channel that do not mention it. If you want the Bot to read every message in a channel, set up a Slack channel listener routine. The routine runs as the person who set it up and counts against their usage allowance.

The Bot answers only people who have linked their Slack account to their Cursor account. Teammates link their account in Settings, General, Team Bots. If someone who has not linked their account @mentions the Bot in a channel, the Bot sends them a private Link Account button. They click it, link their account, and can then talk to the Bot. If someone linked to a Cursor account that is not on the Bot's team, the Bot tells them privately and does not answer.

Here is the critical part: where work runs. In the owner's chat, work runs on the owner's computer. In a teammate's app chat or one-on-one Slack DM, work runs on that teammate's computer. In Slack channels, group DMs, and threads, work runs on one shared computer for that Team Bot. Every channel conversation with that Bot shares that one computer, and the Bot's replies in a thread are visible to everyone in the channel. Do not share anything in a channel thread that should not be visible to everyone in that channel.

This means you need rules for what the Bot can do in Slack channels. Here are starting suggestions, framed as rules you write down and communicate to the team:

• The Bot may read from shared systems using read-only secrets in Slack channels.

• The Bot may not read from personal accounts or OAuth plugins in Slack channels unless the plugin is explicitly approved for channel use.

• The Bot may draft messages and post them for review in Slack channels, but may not send messages on behalf of a person without approval.

• The Bot may not open files, run commands, or browse websites in Slack channels that contain customer data, credentials, or personal information.

• If a question in a Slack channel requires personal context, the Bot should ask the person to continue the conversation in a DM.

Write these rules in the Bot's description or as a team skill. Test them in a private Slack channel with a few people before you invite the Bot to a public channel. When you find a case where the Bot leaks context, update the rules and teach the Bot the correct behavior.

You can remove the Bot from Slack at any time. Remove from Slack deletes the Slack app, but the Bot keeps working in the Grok Bot app. If you need to pause Slack access temporarily, unpublish the Team Bot. Teammates lose access in the app and in Slack. When you republish, access comes back.

Admin Controls: Teams vs Enterprise and a Baseline Configuration

Admin controls let you set boundaries for what Bots can do, which connectors they can use, which networks they can reach, and what approvals they need. The Grok Bot admin controls for teams and enterprises page documents every control. Some are available to team admins on both Teams and Enterprise plans. Others are Enterprise only. Availability and controls can change, so check the current documentation before you configure your baseline.

Controls Available on Teams and Enterprise

Team Rules are rules every member's Bots follow. You can scope a rule to Cursor, Grok Bot, or both. Rules applied to Grok Bot are always required; the member cannot turn them off. Keep rules short and few. Examples: "Never move company data to personal accounts." "Always cite sources when answering questions." Rules guide behavior; they do not enforce approvals. For approvals, use Auto-review rules on Enterprise.

Connector policy is inherited from the team's Cursor connector policy. There is no separate Grok Bot connector list. Any permitted connector is available to every Bot a member runs. A blocked connector shows "Disabled by team admin." Audit your connector policy before you enable Grok Bot. If a connector should not be available to Bots, block it. Pushing connectors to members as mandatory or default-on is not available today.

Execution on Local Computer controls whether Bots can run commands on a member's own machine. The options are Always allow, Ask every time, and Never allow. Always allow is the default and leaves the choice to the member, whose own default is to ask. The recommendation is Never allow unless Bots need access to member machines. Most Team Bots do not.

Cloud Agent delegation controls whether Bots can delegate coding tasks to Cloud Agents. This is on by default. If your team does not use Bots for coding tasks, turn it off.

Public template sharing controls whether members can publish templates outside the team. Enterprise teams start with public sharing off. Other teams start with it allowed. If you do not want members sharing templates publicly, turn this off.

Agent Email controls whether members can claim an agent email address and have Bots read and send email from it. This is off by default. Turn it on only if you have a specific use case for it.

Controls Available on Enterprise Only

The organization-wide enable switch lets an admin turn Grok Bot on or off for the whole team. When off, members cannot use Grok Bot, but their computers and data are not deleted. You can also limit access to specific groups with Manage Group Access.

Enforce Auto-review prevents members from turning Auto-review off. This is off by default. Team Auto-review rules apply only while Enforce Auto-review is on, so turn it on before you rely on them.

Auto-review rules are team-wide Ask first and Allow automatically rules. Members see them in Settings, General, Auto-review, but cannot edit them. Ask first rules win on conflict. Use Ask first rules for actions that need approval: production deployments, external email, payments, accepting legal terms. Keep Allow automatically rules narrow. The recommendation is to start with Ask first rules for anything consequential and widen only after you have data on what is safe to allow automatically.

Network Controls let you restrict which destinations team computers can reach. The options are Allow All Network Access, Defaults plus Team Allowlist, and Team Allowlist Only. Teams without a policy default to allow-all. Use a Team Allowlist to limit Bots to internal services, approved SaaS tools, and known-safe domains. This is one of the most important controls for Enterprise teams.

Team Setup lets you install scripts that run on every team computer. Team Secrets are for those scripts; you can add up to 100 secrets per team. Use Team Setup to install tools, configure environments, or set up access to internal services. Do not put credentials in the setup script itself; use Team Secrets.

Action Recording records what a Bot did: tool calls, the decision that allowed or refused the action, MCP calls, shell commands, browser navigations, messages sent, routine runs, and more. Metadata is sanitized. Action Recording is off by default. It is delivered via OpenTelemetry Export and does not appear on the Audit Log page. Turn it on if you need a detailed record of Bot actions for compliance or debugging.

Audit logs record admin, security, and auth events plus Grok Bot control-plane events: Bot creation, member access changes, Team Setup manifests, MCP authentication, Slack account links, routines, Team Bot events such as created, published, unpublished, deleted, and skill changes. Audit logs are available on Enterprise and are the primary tool for answering "who did what and when."

Manage Bot Computers is available on Enterprise only. Organization admins (team admin rights are not enough) can recreate or terminate the computers of many members at once. Recreate moves members to the latest image and Team Setup while keeping Bots, files, and logins. Terminate ends current work and keeps the durable disk. Terminate Inactive Computers can terminate after 30 days without use and is off by default. None of these actions remove access.

Group settings are available on Enterprise only. Groups come from Members > Groups, and you use the group's Grok Bot tab. Groups can only widen the team baseline, except for network controls. The recommendation is to tighten controls on the Grok Bot page and widen them per group as needed. For example, set Execution on Local Computer to Never allow on the Grok Bot page, then use a group for engineers who need local execution and set it to Ask every time for that group.

Recommended Baseline Configuration

Here is a recommended baseline configuration, adapted from the official documentation. This is a starting point; adjust based on your team's needs and risk tolerance.

For team admins on Teams and Enterprise: Audit your connector policy before enabling Grok Bot. Block any connector that should not be available to Bots. Set Execution on Local Computer to Never allow unless Bots need member machines. Disable Cloud Agent delegation if your team does not use Bots for coding tasks. Keep public template sharing off unless you have a reason to allow it. Write Team Rules that are short, clear, and few.

For Enterprise admins, add these: Configure Network Controls to limit Bots to internal services and approved SaaS tools. Turn on Enforce Auto-review before you rely on team Auto-review rules. Set Ask first rules for production deployments, external email, payments, and accepting legal terms. Keep Allow automatically rules narrow. Turn on Action Recording if you need detailed records of Bot actions. Review audit logs regularly. Gate sign-in to managed devices through your identity provider with SSO.

For members, communicate these practices: Never paste credentials into chat; use the masked secret request. Prefer Allow once over Always allow for accounts, money, and shared resources. Sign the Bot's browser into accounts sized to the task; sign out when not needed; use scoped service accounts. Start new roles with read-only tasks and draft outputs; keep sending, publishing, purchasing, deletion, and production changes behind approval. Review installed plugins and active routines regularly; pause a routine when its source system changes.

Manage Team Bots and Groups

On the Grok Bot page of the Cursor dashboard, admins see a Team Bots section with a Manage Team Bots button. This lets you choose who gets each Team Bot in their sidebar automatically. The options are All team, None, or specific groups. Members see Team Bots placed by the admin with a "Required by your admin" label. Admins can also delete a Team Bot from this page by typing the exact name. Deleting a Team Bot removes it for everyone, including all teammates' chats and routines, and removes the Slack app. This cannot be undone.

Use Manage Team Bots to control the default placement of Team Bots during a phased rollout. Start with None, then add the Bot to a pilot group. After the pilot succeeds, expand to more groups or All team. This gives you control over who sees the Bot without requiring teammates to search for it.

Usage and Cost Ownership

A teammate's usage of a Team Bot counts against their own allowance, not the owner's. When you ask a Team Bot a question in the app or Slack, your usage counter increments. When you set up a routine on a Team Bot, the routine runs as you and counts against your allowance. Slack messages that come from a linked teammate count against that teammate. Slack messages that come from an unlinked source, such as a Slack workflow or a bot posting to a channel, count against the owner of the Team Bot.

If a teammate runs out of usage allowance, the Bot tells them instead of using the owner's allowance. This is by design. That keeps everyone else's questions from draining the owner's allowance. If a teammate consistently runs out of usage, either their seat needs a higher allowance, or they are using the Bot for tasks that should be done another way.

There is no separate Grok Bot spend cap today. Account-level on-demand controls apply, and you can see per-product usage split on the dashboard. If you need to limit Grok Bot usage separately from Cursor usage, you will need to track it manually and communicate limits to the team. Availability and controls can change, so check the current plans page for updates.

Audit, Visibility, and Results Handoff

On Enterprise, audit logs record Team Bot control-plane events: created, published, unpublished, deleted, skill changes, Slack account links, routines, and member access changes. Action Recording, delivered via OpenTelemetry Export, records what Bots did: tool calls, decisions, MCP calls, shell commands, browser navigations, messages sent, and routine runs. Action Recording is off by default. Turn it on if you need detailed records for compliance, debugging, or understanding what Bots are doing.

Where rolled out, Conversation Insights on Enterprise provides an analytics dashboard that groups Bot conversations by Type of Work and Level of Automation. Use this to understand what teammates are asking Bots to do and where Bots are effective.

On self-serve Teams plans, you do not have audit logs or Action Recording. Instead, the owner or a manager reviews the Team Bot's configuration manually on a regular cadence. Check the list of plugins, secrets, skills, and files. Ask the Bot what it remembers about the team and review team memory. Check the list of active routines by asking teammates. This is lighter than Enterprise audit tools, but it is sufficient for a small team with a few Team Bots.

Regardless of plan, establish a pattern for how Bots hand off results. Ask the Bot for reviewable artifacts: a document with headings and source links, a spreadsheet with defined columns, a folder of screenshots and logs, a draft message not sent, a short recommendation with evidence. For consequential work, ask the Bot to separate facts found, assumptions made, actions completed, actions waiting for approval, and unresolved questions. The conversation should contain the final result or a clear link to the source or the file it produced. If a routine posts output to a Slack channel, the post should be self-contained or link to the source or the file it produced.

Preserve evidence. Ask the Bot to include source links, screenshots, timestamps with time zones, file names, and a concise action log. Ask the Bot to list what it could not verify. This makes it possible to review the Bot's work later and understand how it reached a conclusion.

The Phased Rollout Plan with Exit Criteria

A phased rollout gives you control, feedback, and the ability to fix problems before they reach the whole team. Here is a four-phase plan with exit criteria for each phase. Treat these as starting suggestions, not mandates. Your plan will differ based on your team size, the Bot's job, and your risk tolerance.

Phase 0: Pre-Flight and Policy

Complete the pre-flight checklist. Move off Privacy Mode if needed. Plan egress IPs. Clear your network gateway. Decide how members sign in to company tools from the Bot's computer. Audit inherited policies: Team Rules, connector policy, Auto-review rules, MCP allowlist. Configure the admin baseline: connector policy, Execution on Local Computer, Cloud Agent delegation, public template sharing, Network Controls on Enterprise, Enforce Auto-review on Enterprise, Ask first rules on Enterprise. Write the ownership map for the first Team Bot. Document the access model for each plugin. Write the Slack rules.

Exit criteria: Pre-flight checklist complete. Admin baseline configured. Ownership map written and shared. Access model documented. Slack rules written. One person designated as owner of the first Team Bot.

Phase 1: Pilot

Create one Team Bot for one shared job. Add plugins, secrets, skills, and files. Test the Bot in the owner's chat until it reliably does the job. Publish the Bot to the team, but do not add it to Slack yet. Publishing makes it findable by teammates under Team Bots, so tell the team it is in pilot and share the link with the pilot group. Invite a small pilot group, suggested size three to five people. Ask them to use the Bot in the app for a defined period, suggested length two weeks. Limit the Bot to read-only tasks and drafts; no sending, publishing, purchasing, deletion, or production changes without approval. Review the Bot's answers on a sample of conversations. Collect feedback from the pilot group. Update skills, files, and team memory based on feedback. Rotate or scope down any secrets that were too broad.

Exit criteria: The Bot answers questions accurately on a sample review. Pilot group reports the Bot is useful for the defined job. No credentials leaked. No unintended actions taken. Feedback incorporated into skills and files. Owner and pilot group agree the Bot is ready to expand.

Phase 2: Expand

Add the Team Bot to Slack. Invite it to one or two channels where the pilot group already works. Test Slack behavior: DMs, channel mentions, thread-following. Confirm that the Bot does not leak context in channel threads. Add one or two managers from the pilot group. Ask managers to review skills and files and suggest improvements. Use Manage Team Bots to add the Bot to the pilot group's sidebar automatically. Expand the pilot group to a larger set, suggested size eight to twelve people, or a whole functional team. Extend the trial period, suggested length four weeks. Continue limiting to read-only tasks and drafts. Review a larger sample of conversations. Check usage per teammate from the dashboard. Check active routines.

Exit criteria: The Bot works reliably in Slack without leaking context. Managers are maintaining skills and files. Usage is spread across the expanded group, not concentrated in one or two people. Accuracy remains high on sample review. No new issues reported. Expanded group agrees the Bot is ready for the whole team.

Phase 3: Team-Wide

Use Manage Team Bots to add the Bot to All team or to all relevant groups. Announce the Bot in a team meeting or Slack post. Link to the ownership map and access model. Remind the team of the Slack rules. Invite the Bot to more Slack channels as needed. Consider adding more Team Bots for other shared jobs, one at a time. For each new Team Bot, repeat Phase 1 and Phase 2 before going team-wide. Establish a change control process: who can add plugins, who can save skills, how often secrets are rotated, how often team memory is reviewed. Establish an offboarding process: what happens when the owner leaves, when a manager leaves, when a teammate leaves.

Exit criteria: The Bot is available to the whole team. Usage is steady and spread across multiple people. Accuracy is high. Change control process is documented and followed. Offboarding process is documented. Team reports the Bot is useful and not causing problems.

What to Measure: A Rollout Scorecard

You cannot improve what you do not measure. A rollout scorecard tracks whether the Team Bot is doing its job and whether the team is using it correctly. Do not invent benchmarks or promise numbers. Instead, define a scorecard with qualitative and operational measures, then track them over time. Here are starting suggestions for what to measure.

Questions answered without a human handoff. Count how many questions the Bot answered completely versus how many required escalation to a person. A high handoff rate means the Bot does not have the right skills, files, or plugins.

Accuracy on a sample review. Each week, the owner or a manager reviews a sample of conversations and checks whether the Bot's answers were correct. Define correct as: factually accurate, cited sources, followed team rules, did not leak context. Track the percentage of correct answers over time.

Corrections that become team skills. When the Bot gives a wrong answer and someone teaches it the right answer, count how many of those corrections become team skills. A low rate means the Bot is not learning from mistakes.

Approval requests and denials. Count how many times the Bot asked for approval and how many times approval was denied. A high denial rate means the Bot is trying to do things it should not, and you need tighter Auto-review rules or clearer skills.

Plugin sign-in friction. Count how many times teammates report difficulty connecting an OAuth plugin or confusion about which account to use. High friction means the access model is not clear or the plugin is not the right tool.

Usage per teammate from the dashboard. Check the usage page regularly and see whether usage is spread across the team or concentrated in a few people. Concentration means the Bot is useful to some people but not others, and you need to understand why.

Routines active. Count how many routines are set up on the Team Bot and how many are still running. Routines that stop running mean the source system changed, the person who set them up left, or the routine was not useful.

Slack threads where the Bot was the wrong tool. In Slack channels, count how many times someone had to tell the Bot to stop or move the conversation to a DM because the Bot was leaking context or doing the wrong thing. This is a leading indicator of a Slack rules problem.

Write your scorecard in a shared document. Update it weekly during the pilot and monthly after rollout. Use it to decide whether to expand, pause, or change the Bot's configuration. Share it with the team so everyone knows what success looks like.

Offboarding and Change Control

People leave. Systems change. A Team Bot without a change control and offboarding process becomes a risk. Here is what to document and when to do it.

When the owner leaves, if you have managers, the managers can continue maintaining the Bot's setup, but they cannot publish, unpublish, or delete it. If you need to delete the Bot, an admin can do it from Manage Team Bots by typing the exact name. Deleting removes the Bot for everyone, including all teammates' chats and routines, and cannot be undone. If you need to keep the Bot, consider recreating it with a new owner and migrating the skills, files, and plugins.

When a manager leaves, the owner removes them from the managers list with the trash icon and chooses Remove manager. The former manager loses the ability to change the Bot's setup. Their own routines are personal, so ask them to pause or delete routines they no longer need.

When a teammate leaves, before they leave ask them to pause or delete their routines on Team Bots. To remove access, remove them from the team (or turn off Grok Bot for their group on Enterprise) and revoke their sessions in your identity provider. If the teammate was the only person who knew how to do a task the Bot was helping with, document that task in a skill or file before they leave.

When you add a new plugin or secret to a Team Bot, document it in the ownership map and access model. If the plugin uses OAuth, test that each teammate can connect their account. If the plugin uses a secret, confirm the secret is scoped and read-only. If the plugin can write, delete, or spend money, add an Ask first rule on Enterprise, or keep it out of the Team Bot until you can gate it.

When you save a new team skill, announce it to the team. Explain what the skill does and when the Bot will use it. If the skill changes a previous behavior, explain what changed and why.

When you rotate a secret, update the secret in the Team Bot's settings. Test that the Bot can still use the plugin with the new secret. Document the rotation date in the ownership map.

When you remove the Team Bot from Slack, the Slack app is deleted, but the Bot keeps working in the Grok Bot app. If you need to pause Slack access temporarily, unpublish the Team Bot. If you need to stop the Bot entirely, delete it.

Unpublish versus delete: Unpublish removes access temporarily. Teammates cannot see the Bot or talk to it, but their chats and routines are preserved. When you republish, access comes back. Delete removes the Bot for everyone, including all chats and routines, and cannot be undone. Prefer unpublish unless you are certain you will not need the Bot again.

Common Mistakes

Here are common mistakes teams make when rolling out Grok Bot, based on the patterns described in the documentation and the controls available.

Copying personal-Bot habits to a Team Bot. A personal Bot with your admin credentials is a risk you own. A Team Bot with the same credentials is a risk the whole team owns. Use scoped, read-only service accounts for Team Bot secrets.

No ownership map. A Team Bot without a clear owner becomes nobody's responsibility. Write the ownership map before you create the first Team Bot.

Broad connectors. Adding every available connector to a Team Bot gives every teammate the ability to ask the Bot to act in every system. Audit your connector policy and block connectors that should not be available to Bots.

Shared credentials in secrets. A secret is access you give the whole team. If you put your personal API key in a Team Bot secret, every teammate can use it. Use service account keys.

No Slack rules. A Bot in a Slack channel can leak context to everyone in the channel. Write Slack rules before you add the Bot to a channel, and test them in a private channel first.

No access model. Teammates do not know which plugins use their own account and which use a shared credential. Document the access model and share it with the team.

Skipping the pilot. Rolling out a Team Bot to the whole team without testing it with a small group first means you find problems at scale. A pilot with three to five people for about two weeks is a reasonable starting point.

No review cadence. A Team Bot's skills, files, and team memory drift over time. Review them regularly, suggested monthly, and update them as systems change.

No offboarding process. When the owner leaves and nobody knows how to maintain the Bot, it becomes a risk. Document the offboarding process before the first person leaves.

Assuming routines are shared. Routines belong to whoever set them up and run as that person. There is no routine that runs for the whole team. To share output, post it to a shared Slack channel.

Not enforcing Auto-review on Enterprise. Team Auto-review rules apply only while Enforce Auto-review is on, so turn it on before you rely on them.

Allowing local execution by default. Most Team Bots do not need to run commands on member machines. Set Execution on Local Computer to Never allow unless you have a specific reason to allow it.

No audit of connector policy before enabling Grok Bot. If a connector should not be available to Bots, block it before you enable Grok Bot for the team.

Rollout Checklist

Here is a checklist you can copy and adapt for your own rollout. Treat this as a starting point, not a mandate.

Pre-flight:

• Move off Privacy Mode if needed.

• Plan egress IPs if needed.

• Clear TLS-inspecting proxies.

• Decide how members sign in to company tools from the Bot's computer.

• Audit Team Rules, connector policy, Auto-review rules, MCP allowlist.

• Configure admin baseline: connector policy, Execution on Local Computer, Cloud Agent delegation, public template sharing, Network Controls, Enforce Auto-review, Ask first rules.

Ownership map:

• Choose owner for first Team Bot.

• Choose managers after publishing.

• Document plugin approver.

• Document secret approver.

• Document memory reviewer and cadence.

• Document Slack channels.

• Document approval plan.

Access model:

• List every plugin.

• Document whether OAuth or secret.

• Document scope of each secret.

• Document who created service accounts.

• Document when secrets expire.

• Document who rotates secrets.

Slack rules:

• Write rules for what the Bot can do in channels.

• Write rules for what requires a DM.

• Test rules in a private channel.

• Communicate rules to the team.

Pilot:

• Create one Team Bot for one shared job.

• Add plugins, secrets, skills, files.

• Test in owner's chat.

• Publish to team.

• Invite three to five people.

• Limit to read-only and drafts.

• Run for two weeks.

• Review sample of conversations.

• Collect feedback.

• Update skills and files.

Expand:

• Add to Slack.

• Invite to one or two channels.

• Test Slack behavior.

• Add one or two managers.

• Use Manage Team Bots to add to pilot group sidebar.

• Expand to eight to twelve people or one functional team.

• Run for four weeks.

• Review larger sample.

• Check usage per teammate.

• Check active routines.

Team-wide:

• Use Manage Team Bots to add to All team or all relevant groups.

• Announce in team meeting or Slack.

• Link to ownership map and access model.

• Remind team of Slack rules.

• Invite to more channels as needed.

• Establish change control process.

• Establish offboarding process.

Ongoing:

• Review skills, files, team memory monthly.

• Review sample of conversations weekly or monthly.

• Check usage per teammate monthly.

• Check active routines monthly.

• Rotate secrets on schedule.

• Update access model when plugins change.

• Update ownership map when people change roles.

• Review audit logs if available.

SumoGrowth Implementation Help

SumoGrowth Labs helps operations teams plan and set up AI rollouts. If you need help building your ownership map, access model, Slack setup, admin baseline, pilot plan, or rollout scorecard, we can work with you to get it done. SumoGrowth is an AI implementation and consulting agency, and SumoGrowth Labs is the team that does the setup work. Reach out if you want a second set of eyes on your Grok Bot team rollout.

by Darius Gaynor