Grok Bot security

Use these controls and deployment details to decide whether Grok Bot is allowed in, and to limit what Bots can access, change, and retain. Rollout steps and the dashboard settings list live on Grok Bot for Teams and Enterprise. Common review questions are on Grok Bot security FAQ.

Architecture

The Grok Bot desktop and mobile apps send each request to Cursor's servers. From there, work runs on the member's hosted computer, prompts go to model providers, and tool calls reach third-party services through connected apps.

Customer side

Grok Bot

Desktop and mobile

Team policies

Cursor cloud

Hosted computer

One microVM per member, in the US

Cursor servers

Cursor selects the model

Tool calls, no tokens

Connected apps

Network policy

Zero Data Retention

Auto Review

Third parties

Web apps & SaaS

Bots act as the signed-in member

Network policy

Model providers

Zero Data Retention

MCP servers

Slack, Google, GitHub, and more

Auto Review

A control sits on each of those paths. Each one links to its section on this page.

1Team policies

Cursor cloud

Hosted computer

One microVM per member, in the US

2Network policy

Cursor servers

Cursor selects the model

1Team policies3Zero Data Retention

4Tool calls, no tokens

Connected apps

5Auto Review

2Network policy

3Zero Data Retention

5Auto Review

1. 1

   Team policies

   Team Rules apply. Network and Auto-review controls are set on the Grok Bot page.

2. 2

   Network policy

   Admins control which domains the hosted computer can reach.

3. 3

   Zero data retention

   With Privacy Mode on, model providers don't retain your data.

4. 4

   Tokens stay in connected apps

   OAuth tokens are stored server-side; the model sees only tool results.

5. 5

   Approvals and Auto Review

   Auto review can ask users for approval before taking potentially risky actions. Members can add Ask first rules, and Enterprise admins can enforce review.

Network policy

Network Controls is Enterprise only. Admins set a Grok Bot network policy under Network on the Grok Bot page of the Cursor dashboard, in Grok Bot Network Access. It controls which destinations team computers can reach. Self-serve Teams do not see this panel and cannot set a destination allowlist. Teams without a policy default to allow-all.

• Destinations cover web domains as well as IP ranges with ports for raw connections, with no cap on the number of entries.
• Directory groups. Enterprise only, inside Network Controls. Groups can set their own network policy, which replaces the team's for their members, and a lock makes the team policy effective for everyone.
• The policy is separate from Cloud Agent network settings. Running computers apply changes automatically within about a minute. Sleeping computers apply changes when they next wake. You don't need to recreate the computer.
• Restricting egress limits where data can be sent. To check what reaches the model against your own data loss prevention policy, use inference hooks.

Blocking an app doesn't block that service's website. The connector policy and the network policy are separate layers, and closing both paths takes both controls.

MCP servers and the network policy

The network policy governs where team computers send traffic. Connected apps (MCP servers) are different: Bots reach remote MCP servers from Cursor's servers, so an allowlist mode doesn't cover them on its own. To hold them to the same list, turn on Apply to MCP servers. The switch sits below Allowed destinations (Allowed Destinations on the older settings page) and above Lock for all groups (Lock for All Groups) in Grok Bot Network Access, and it appears only while Default, plus the allowlist (Defaults + Team Allowlist) or Allowlist only (Team Allowlist Only) is selected.

• Off, the default for every team. Bots can connect to any MCP server your connector policy permits, whatever the network policy says.
• On. A remote MCP server must also match an entry in Allowed destinations. A server that doesn't match is refused when a Bot tries to use it, and the member sees which destination to ask an admin to add. Command servers that run on the computer are unaffected; the network policy already applies to them.

Turn the switch on before you rely on it: an allowlist mode by itself doesn't restrict MCP servers. The switch is a team setting. Directory groups inherit it and can't turn it off, and a locked team policy includes it. Saving it doesn't restart computers; it applies to the next MCP connection. It's separate from the settings under MCP Configuration in Team Settings, which govern Cursor in the editor; changing one doesn't change the other.

Built-in connectors are checked too. The switch covers every connected app a Bot uses, including the ones Cursor operates for you under Connect apps, such as GitHub, X, Origin, Google Workspace, and Microsoft 365. A connected app is checked by the hosts it sends requests to, not by the name in the connector list, so add those hosts to Allowed destinations before you turn the switch on. A connector whose hosts aren't all allowed is refused the next time a Bot uses it, with the message MCP server "<host>" refused: it is not on your team's Grok Bot network allowlist (Grok Bot settings > Network > Allowed destinations). A team admin can add it.

Other connectors in the Team Marketplace are checked by the host in their server address, which is shown on the dashboard's Plugins & MCPs page; allow that host.

Static egress IPs

Hosted computers reach the internet through shared static egress IP addresses by default. The ranges are shared across Grok Bot customers, and dedicated per-customer IPs are not available, so treat the ranges as identifying Grok Bot traffic rather than your team alone. Current ranges are available from your account team, and the product control is the destination allowlist rather than a source IP editor.

If member devices sit behind Zscaler or another TLS-inspecting gateway, allow Cursor's domains and exempt them from inspection on every profile, including off-network. See Configure TLS-inspecting proxies.

Members can route traffic through their desktop to use its IP address; sites that resolve to a private or VPN address stay blocked on that route unless they've been allowed for your organization. Team Setup Scripts is Enterprise only. Those teams can also install their own networking client on every team computer. Both paths are separate from the shared egress ranges. See Connect to private networks.

Approvals and Auto Review

Approvals keep consequential actions under the member's control. The strongest boundary is the one in the request itself, so have members state what a Bot may change and where it must stop:

Reconcile the campaign data and draft a recommended budget change. Don't change the campaign or message the agency. Ask for approval after showing the current value, proposed value, and expected impact.

When an action needs approval, the conversation shows the proposed operation and its inputs. Allow once lets the Bot continue with that action, Always allow can save a matching rule, and Deny stops the action; the Bot doesn't try it again until the member sends another message. The controls are the same on iPhone. An approval controls the proposed action, not work already completed, and nobody should approve an action whose target or effect they can't identify.

Auto Review is the review layer behind those prompts: an independent review model that evaluates risky Bot actions before they run, covering shell commands, app calls, computer use, automation writes (changes to routines and event triggers), and delegation such as Cloud Agent and subagent launches. It can let an action proceed, require approval, or deny it.

• Team admins can enforce Auto-review. Enterprise only. The switch lives on the Grok Bot page of the Cursor dashboard. When it is on, members can't turn Auto-review off, unless a group they belong to lifts the lock with Don't enforce for this group; see Group settings.
• Admins can add team Auto-review rules. Enterprise only. These live on the Grok Bot page too. They apply to every member's Bots, show up as locked rows in the member settings table, and save automatically when an admin adds, edits, or deletes a rule. If admins turn enforcement off, the team rules stop applying and members go back to their own rules only.
• Members can add personal rules under Settings > General > Auto-review, in Custom Rules. Ask first rules always stop matching actions, and Allow automatically rules let matching actions proceed only when the reviewer finds no other reason to stop. Members can add personal rules on top of team rules, but they only make behavior stricter; Ask first wins when rules conflict. Keep rules narrow and tied to a known action, like "ask first before sending any external email" or "allow automatically when running git status in /workspace/reports". Avoid broad rules like "allow everything in the browser". Personal rules are saved to the member's account, so they apply from every desktop and the mobile app.
• It doesn't review every side effect. Memory writes and most settings changes are examples. Treat it as a complement to explicit boundaries and least privilege, working alongside controls that don't depend on a model's judgment: per-action approvals, the network policy, and per-user isolation.

Inference hooks

Inference hooks send each Grok Bot model request, signed, to an AI security server your organization runs or uses through a security vendor. Your server allows or denies the request before the model runs, so your own policy checks prompts and the content Grok Bot gathers, such as web pages and app results. New configurations start in Shadow mode, which records denials in the audit log without blocking anything.

Inference hooks check model inputs, not actions as they run. Keep the network policy and Auto Review in place to control what Bots do. Setup, modes, the request format, and audit events are on Grok Bot inference hooks.

Identity and sign-ins

Members sign in to Grok Bot with their Cursor account, so your existing Cursor SSO configuration applies. SAML 2.0 single sign-on works with Okta, Microsoft Entra, Google Workspace, and OneLogin, and SSO can be required for all members (which blocks password login). SCIM is Enterprise only: SCIM 2.0 provisioning and deprovisioning. For step-by-step Okta and Entra ID configuration, including app assignment and sign-in rules for the computer browser, see Configure identity and access.

Inside the hosted computer, members sign in to applications through your own identity provider in the browser, comparable to enrolling a new laptop. Your session policies govern those sessions, and revoking the user in your identity provider ends them.

A Bot has no identity or credentials of its own:

• Bots act as the signed-in member. A Bot can never hold more access than the person it belongs to, every action stays attributable to a named member, and there's no separate machine identity outside your identity provider to provision, rotate, or audit. Team-managed connectors are the one exception: they may use team or service-account credentials.
• Connector tokens stay on Cursor's backend. Bots invoke tools without receiving OAuth tokens, and tokens are never stored on the computer.
• Credentials stay out of the model. To sign in, the Bot uses a login the member saved in Vault, a connected password manager, or a value the member enters in a Secure Form. These values are filled into the page by reference: the model never receives a saved password, card number, or security code, or what the member types in a Secure Form. The Bot can see which logins are saved and the member's saved contact info. For single sign-on, passkeys, and other steps a form can't handle, the Bot hands the computer to the member. For an API key or other secret, a secure secret card masks the value and keeps it out of the transcript and away from the model. A card saved in Vault fills at checkout without a separate approval each time, so members who want to approve each payment shouldn't save the card. Vault isn't available on Team Bots. Passwords and one-time codes never belong in ordinary chat. See Store secrets securely.

To end a member's current work, an organization admin terminates the member's computer from the dashboard; see Manage Grok Bot computers. That control is Enterprise only. It stops running Bots, keeps the durable disk, and the member's next session starts a fresh computer. It does not remove access. To remove access, remove the member from the team or turn off Grok Bot for their group, and revoke their sessions in your identity provider. Application sessions persist only on the member's computer.

When a project or login should no longer be available, members clean up directly: pause or delete related routines, sign out of websites on the computer, remove connected apps and revoke their authorization in the source service, and remove sensitive files from /workspace. Deleting a Bot doesn't remove computer files or browser sessions.

Logging and audit

Audit Logs and Action Recording use separate pipelines. Audit Logs cover administrative and security events, including Grok Bot control-plane actions. Action Recording captures Bot actions, and OpenTelemetry Export sends those events to your collector when configured, tagged cursor.surface=grok_bot.

• Audit logs. Enterprise only. They cover admin, security, and authentication events, plus Grok Bot control-plane events: Bot creation, member access changes, Team Setup manifests, MCP authentication, Slack account links, and routines. Filter them by application in the dashboard, or stream them to your SIEM. Self-serve Teams do not get this log.
• Action Recording. Enterprise only. It is a setting on the Grok Bot page, off by default. When a team enables it, Cursor records Bot actions, including scrubbed shell commands, in an internal store with a 90 day retention. Action Recording events don't appear on the Audit Log page. To receive the sanitized events in your own collector, configure OpenTelemetry Export, which is also Enterprise only. Privacy Mode (Legacy) forces recording off.

Endpoint tooling

Grok Bot doesn't ship a built-in customer-facing telemetry or EDR feed. The computers are Cursor-operated infrastructure that Cursor monitors for operational health and abuse, and that telemetry deliberately excludes customer data. Team Setup Scripts is Enterprise only. Those admins can install their own tooling on every team computer.

Data retention and deletion

Each member's computer keeps local files, browser sessions, and anything saved in the browser on a durable disk across sessions. Connector tokens are never stored on the computer.

• Idle computers hibernate automatically. Hibernation is not deletion.
• Image updates preserve files. Computers on a stale system image are recreated on the fresh image with member files preserved.
• Member resets keep saved data. Members can reset their own computer from the desktop app. Like Recover, Reset rebuilds the computer from the last saved data, and very recent changes can be lost if the computer can't be reached to save them. See Grok Bot computer.
• Deletion follows the DPA. Under the Data Processing Agreement, data is deleted or returned within 30 days of written direction after the service ends.
• Backups run daily. Cursor's production control plane is covered by daily encrypted backups, replicated to a separate recovery facility.

A per-organization retention policy and customer-managed point-in-time restore of an individual computer are not available.

Data residency

Grok Bot computers run in the United States today. That is not the same as Cursor's US-only data residency program, which does not apply to Grok Bot by default. If your review needs a written residency commitment, contact your account team.

Models and data

Grok Bot manages model selection. There is no customer-facing model picker, and the serving mix can change over time with no fixed vendor set guaranteed. Each request goes to a first-party xAI model or a third-party model from a provider on the sub-processor list. Usage and spending views record this activity as Grok Bot usage rather than by model. See Which AI models power Grok Bot?.

• The team model allowlist does not govern Grok Bot. Grok Bot uses xAI first-party models and may use third-party models regardless of your model access control settings. Teams with a model allowlist see this acknowledgement when they enable Grok Bot. If your contract restricts subprocessors, contact your account team.
• Privacy Mode applies. While a member is on your team, the team's privacy mode governs them, and with Privacy Mode enabled, customer data is not used for training.
• Zero Data Retention follows Cursor's existing provider agreements. Model providers don't keep prompts or outputs, and Grok Bot adds no separate control. Providers may run abuse and safety classifiers, and flagged data may be stored for investigation.

Local execution

Bots can act on a member's own machine through the desktop app: run commands, read files, and move files between the cloud computer and the local machine. This is separate from work in the hosted computer, with its own control, and it's distinct from Auto Review, which governs work inside the hosted computer.

Per-command approval is the default, and the approval card shows the exact command. Members choose the policy under Settings > Computer > Your computer, in Execution on this computer (Execution on Local Computer until the desktop is listed): Ask every time, Always allow, or Never allow. Recommend Never allow unless a Bot has a specific reason to work on local files. Admins can cap the policy for the whole team with Execution on Local Computer on the Grok Bot page; a member's own setting still applies when it is stricter.

Hosting

Grok Bot runs only on Cursor-hosted cloud computers. On-premises deployment, deployment inside your own perimeter, and bring-your-own-image deployment are not supported today. Hosted computers use shared static egress by default. Members can route traffic through their desktop, and Enterprise teams can install a networking client with Team Setup Scripts. See Connect to private networks.

Prompt injection

Content a Bot reads from the outside world, like web pages, app results, and command output, can try to steer it. Grok Bot layers defenses: Auto Review checks Bot actions against the member's request when enforcement is on, and beneath it sit controls that don't depend on any model's judgment, including the network policy, per-action approvals, and per-user isolation. Outside content is marked as untrusted data when presented to the model. With inference hooks, your own security server can also screen that content before the next model call. These controls reduce, but don't eliminate, risk from malicious content, which is another reason to keep consequential actions behind approval.

Certifications

Anysphere, the company behind Cursor, holds ISO/IEC 27001 and ISO/IEC 42001 certifications, issued by Schellman, and Grok Bot is included in the current ISO scope. ISO/IEC 27001 certifies the information security management system, the security program of the whole organization. ISO/IEC 42001 certifies the AI management system, how Cursor governs the AI it builds and operates. Certificates and reports are available at trust.cursor.com.

Related pages

• Grok Bot security FAQ
• Grok Bot for Teams and Enterprise
• Grok Bot inference hooks
• Configure identity and access
• Connect to private networks
• Configure TLS-inspecting proxies
• Privacy and Data Governance