企业关心的其实就三件事：谁能用、它能碰到什么、出了事能不能查。官方把答案拆在 Security、Identity and access、Private networks、Approvals/security/privacy、Teams and enterprises 五页里，本篇把它们并成一份评估材料。

一、先分清哪些是 Enterprise 专属

这一条决定了预算。官方在 Security 页顶部的提示里点名的 Enterprise only 项：组织级总开关、Network Controls（网络策略）、Team Setup（团队电脑初始化）、Action Recording（动作录制）、组织管理员的云电脑管理；此外审计日志、OpenTelemetry 导出、MCP 白名单、SCIM 也是 Enterprise only。自助版 Teams 看不到这些设置。 如果你在看板上看不到 Team Setup，官方给的动作是联系你的客户团队。

二、身份与登录：沿用你的 Cursor SSO

成员用 Cursor 账号登录 Grok Bot，所以你现有的 Cursor SSO 配置直接生效：SAML 2.0 单点登录支持 Okta、Microsoft Entra、Google Workspace、OneLogin，并且可以为全员强制 SSO（强制后就封掉密码登录）。SCIM 2.0 的账号开通与回收是 Enterprise only。Okta 与 Entra 的分步配置（应用指配 + 允许从云电脑浏览器登录 IdP）见官方 Identity and access 页。

在云电脑内部，成员是通过你们自己的身份提供商在浏览器里登录各个应用的 —— 和给新员工配一台笔记本是一回事：你现有的会话策略管这些会话，在 IdP 里撤掉这个用户，会话就结束了。

最该记住的一句：Bot 没有自己的身份，也没有自己的凭据。

  • **Bot 以登录成员的身份行动**：它永远不可能拥有超过本人权限的访问；每个动作都能归到某个具名成员；除了你的 IdP，不存在第二套需要开通、轮换、审计的机器身份。唯一例外是团队管理的连接器 —— 它们可以用团队或服务账号的凭据。
  • **连接器令牌留在 Cursor 后端**：Bot 调用工具时拿不到 OAuth 令牌，令牌也从不存放在那台电脑上。
  • **凭据留在成员手里**：登录、两步验证、支付这类步骤，Bot 是把电脑交给成员，而不是自己敲凭据；对支持的连接，安全的密钥请求会把输入值打码，既不进对话记录也不给模型看。密码和一次性验证码永远不该出现在普通聊天里。

要快速收回访问：组织管理员可以在看板上终止该成员的云电脑（该电脑管理控件是 Enterprise only）—— 持久磁盘会保留，下一次会话开一台全新的电脑；同时别忘了去你的 IdP 里撤销会话。应用层面的会话只存在于成员那台电脑上。

三、网络：策略四档 + 共享静态出口 IP

Network Controls 是 Enterprise only，管理员在 Cursor 看板的 Grok Bot 页设置「团队电脑能到达哪些目的地」，官方给了四档：

  • **无策略**：全部放行（没有设策略的团队的默认值）。
  • **允许所有网络访问**：显式放行全部目的地。
  • **默认目标 + 团队白名单**：Cursor 的默认目的地，加上你自己的清单。
  • **仅团队白名单**：只有你的清单，外加电脑运转必需的目的地。

细节上有几点容易漏：条目既覆盖网域，也覆盖带端口的 IP 段（用于裸连接），条目数量不设上限；目录组（Enterprise only，在 Network Controls 里）可以各自设网络策略，组策略会替换其成员所在的团队策略，而「加锁」则让团队策略对所有人强制生效；这套策略与 Cloud Agent 的网络设置相互独立，并且是在电脑创建或重建时应用的 —— 改完策略要让运行中的电脑重建或重启才能生效。还要明确一条边界：限制出网只是限制数据能发到哪，官方没有专门的数据防泄漏（DLP）钩子。

两个常被误解的点：第一，封掉一个插件不等于封掉那个服务的网站 —— 连接器策略和网络策略是两层，要堵住两条路得两个控制一起上。第二，出口 IP 是共享的静态地址：托管的电脑经 Cursor 的共享静态出口 IP 访问互联网，这些网段在所有 Grok Bot 客户之间共用，不提供客户专属 IP —— 所以只能把它们当作「识别 Grok Bot 流量」，而不是识别你的团队；具体网段向客户团队索取，产品侧的控制手段是目的地白名单，而不是来源 IP 编辑器。如果你们公司做 TLS 流量检查，就把 Cursor 公布的 hostname 放行并跳过对这些 hostname 的检查。

要访问私网（内部 API、代码仓库、数据库、预发环境）就上 Team Setup（Enterprise only）：在每一台团队电脑上安装你们自己的网络客户端。Tailscale 与 Cloudflare Tunnel 是官方给的两个完整例子，其他能在 Debian 系 Linux 上从 shell 脚本安装运行的 VPN / 零信任 / 组网客户端走同一套模式。但官方特别强调：这是「你自己运营的一套模式」，不是 Cursor 托管的网络模式 —— Cursor 只提供钩子（Team Setup 在每台电脑上执行你的安装脚本），客户端装什么、怎么配、怎么给电脑做认证、访问规则怎么维护、以及跟进厂商变更，全部归你；Cursor 默认什么都不装，不运维也不监控你的客户端，看板上也不显示客户端状态。实践要点：用一份 admin 管理的 manifest 驱动安装脚本，配合 Check Script 让已经装好的电脑跳过安装（脚本要可重复执行）；运行中的电脑大约一天内会刷新 manifest，想立刻生效就重启或重建电脑；脚本在某些电脑上失败不影响电脑启动，失败项会在后续刷新时重试。

四、审批与 Auto Review：人的控制层

官方反复强调一句：最强的边界写在请求本身里 —— 让成员明确说出 Bot 可以改什么、到哪里必须停。官方给的范例：

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

需要审批时，对话里会显示提议的操作及其输入，成员先核对目标、范围和取值，再 Allow once（放行这一次）、Always allow（存成一条匹配规则）或 Deny（拒绝）—— 手机端对应的按钮是 Approve once 和 Deny。两条原则：审批管的是这一次提议的动作，不能撤销已经做完的工作；目标或效果说不清的动作不要批，可以让 Bot 用大白话解释，或先出一版草稿。

Auto Review 是这些提示背后的审查层：一个独立的审查模型，在风险动作执行前评估，覆盖面包括 shell 命令、插件调用、computer use、自动化写入（对 routine 与事件触发器的修改），以及 Cloud Agent、子智能体这类委派，结论可以是放行、要求审批或拒绝。落地注意：强制启用由 Cursor 打开，目前对所有用户生效；成员自己的 Auto Review 设置仍然是那个「关掉的开关」，没有组织级锁，所以安全敏感的部署要请成员保持开启。团队指令可以为所有人塑造它 —— 管理员在团队设置的 Security and Automation 下，为「绝不可接受的动作」加团队级 block 指令，为日常安全操作加 allow 指令。

本地执行要单独理解：Bot 可以通过桌面端作用在成员自己的机器上（跑命令、读文件、在云电脑与本地机之间搬文件）。它和托管电脑里的工作是两套控制，也不是 Auto Review 管的范围。默认是逐条命令审批，审批卡会显示确切命令；成员在 Settings → General → Agent → Execution on Local Computer 里选「每次都问 / 总是允许 / 永不允许」。官方建议：除非某个 Bot 有明确理由要碰本地文件，否则选 Never。团队层面可以整体禁用本地执行，并有一个团队级上限通过设置强制执行（目前看板上没有配置这个上限的控件）。

五、审计：两条独立的管道

  • **Audit Logs（审计日志，Enterprise only）**：覆盖**管理、安全与认证**事件，可以在看板里看，也可以流到你的 SIEM。自助版 Teams 拿不到这份日志。
  • **Action Recording（动作录制，Enterprise only）**：Grok Bot 页上的一个设置，**默认关闭**。团队开启后，Cursor 会记录 Bot 的动作（包括**脱敏后的 shell 命令**）到内部存储，**保留 90 天**。它的记录**不会出现在审计日志页**；要把这些脱敏事件送进你自己的采集器，需要配置 **OpenTelemetry Export**（同样是 Enterprise only）。注意 **Legacy Privacy Mode 会强制关闭录制**。

另外，官方明确 Grok Bot 不自带面向客户的遥测或 EDR 数据源 —— 端点侧的可观测性得靠你们自己的手段。

六、数据、模型与托管形态

  • **数据驻留**：Grok Bot 的电脑目前运行在**美国**。需要书面驻留承诺的，联系客户团队。
  • **模型由 Cursor 管理**：**没有面向客户的模型选择器**，服务模型组合会随时间变化，**不保证固定的厂商集合**；用量分析会显示**每次请求实际由哪个模型服务**（包括故障切换），**计费跟随实际服务的模型**。
  • **团队模型白名单是 Enterprise only，且官方明说不保证强制**：默认会被遵守，但入门流程里会给出「Grok Bot 可能不遵守该名单」的确认 —— 所以要把它当作**取决于配置**，而不是硬保证。
  • **Privacy Mode 适用**：成员在你们团队期间由团队的隐私模式约束；开启 Privacy Mode 时，客户数据不用于训练。**Zero Data Retention** 沿用 Cursor 既有的供应商协议 —— 模型供应商不保留提示与输出，Grok Bot 没有额外控制；供应商可能运行滥用与安全分类器，被标记的数据可能被存储用于调查。如果你的合同限制了哪些子处理者可以处理你的数据，**上线前先联系客户团队**。
  • **托管形态只有一种**：**仅在 Cursor 托管的云电脑上运行**。官方明确**不支持**本地部署、自有边界内部署、自带镜像（BYOI），Cursor 也**不为 Grok Bot 运营进入你网络的 VPN、隧道或私有链路** —— 支持的模式就是「共享静态出口 + 目的地白名单」，要私网就走 Team Setup。

七、提示注入与认证

Bot 从外部世界读到的东西（网页、插件返回、命令输出）都可能试图操纵它。官方的防御是分层的：Auto Review 在强制开启时按成员的请求核查 Bot 的动作；在它之下还有一层不依赖任何模型判断的控制 —— 网络策略、逐动作审批、逐用户隔离；此外，外部内容在呈现给模型时会被标记为不可信数据。官方的结论很坦诚：这些控制降低但无法消除恶意内容带来的风险 —— 这正是要把重要动作留在审批后面的另一个理由。

认证方面：Cursor 背后的 Anysphere 持有 ISO/IEC 27001 与 ISO/IEC 42001 认证（由 Schellman 颁发），Grok Bot 包含在当前的 ISO 范围内。其中 27001 认证的是信息安全管理体系（整个组织的安全项目），42001 认证的是 AI 管理体系（Cursor 如何治理它构建和运营的 AI）。证书与报告在 trust.cursor.com。

八、最小权限落地清单

官方给的这套清单可以直接抄进你的上线检查表：

  • 只连接某个工作流真正需要的工具。
  • 源系统支持的话，用**限权的服务账号**。
  • 从**只读任务和草稿产出**开始。
  • **发送、发布、采购、删除、生产变更**一律留在审批后面。
  • 定期复查已安装的连接器和在跑的 routine。
  • 源系统或预期流程发生变化时，**暂停对应的 routine**。
  • 重要决策保留**来源链接与动作日志**。

相关阅读：成员侧的操作步骤见 kb-243，官方 18 页的整体地图见 kb-242；更细的条款解释以官方 Security、Security FAQ 与 Teams and enterprises 三页为准。

版权说明：本篇是对 xAI / Cursor 官方文档（docs.x.ai/grok-bot）要点与原文引用的中文整理，版权归原方所有；条款与可用性可能随时调整，做采购或合规决策前请以官方页面为准。