身份与访问管理

身份与访问管理决定 Cursor 在企业里能不能被可靠回收。SSO（Single Sign-On，单点登录）解决登录来源，SCIM（System for Cross-domain Identity Management，跨域身份同步标准）解决生命周期，RBAC（Role-Based Access Control，基于角色的访问控制）解决管理权限，MDM（Mobile Device Management，移动设备管理）解决企业设备上”只能进正确团队”的约束。

1. 推荐顺序

Cursor 官方推荐的顺序很明确：

1. Set up SSO：先让企业身份成为唯一入口。
2. Enable SCIM：再把用户增删和目录组交给 IdP。
3. Deploy MDM policies：再把企业设备限制到指定 Team ID 和扩展策略。
4. Assign roles：最后给少数人分配 Admin 或 Unpaid Admin。

不要反过来做。先发账号再补治理，会出现个人账号、手工邀请、离职未回收和设备上混用个人团队的问题。

2. SSO：统一登录入口

SSO 让成员用企业 IdP 登录 Cursor，而不是再维护一套 Cursor 密码。官方文档说明 Cursor 支持 SAML 2.0，并列出 Okta、Azure AD、Google Workspace、OneLogin 等常见 IdP。

上线时建议按这个顺序验收：

• 用测试组先完成 SAML 配置。
• 确认新成员登录会进入正确 Cursor Team。
• 启用“必须通过 SSO 登录”，防止密码登录绕过企业身份。
• 记录 IdP 应用 owner、证书轮换 owner 和回滚方式。

SSO 的关键不是”能登录”，而是把认证、MFA（Multi-Factor Authentication，多因素认证）、条件访问、离职锁定交给企业身份系统。

3. SCIM：自动化成员生命周期

SCIM 2.0 用来从 IdP 自动同步用户和目录组。官方文档说明它适用于启用 SSO 的 Enterprise 计划。

有 SCIM 后，成员生命周期应该这样流转：

• 入职：员工加入指定 IdP group 后自动获得 Cursor 访问。
• 转组：IdP group 变化后，Cursor 侧权限或可见资源随之变化。
• 离职：员工从 IdP 移除后，Cursor 访问自动取消。

验收时不要只测“新增用户”。必须同时测：

• 从 IdP 移除用户后，Cursor 访问是否被回收。
• group membership 变化是否会同步。
• 手工添加的例外账号是否有 owner 和过期时间。
• 自动化账号是否应该改用 Service Accounts，而不是真人账号。

4. RBAC：减少管理员面

Cursor Teams 有三类角色：Members、Admins、Unpaid Admins。

建议把角色分成三层：

• Members：日常开发者，只使用被授权的模型、Agent、集成和团队规则。
• Admins：少数平台 owner，负责 SSO、SCIM、隐私、安全、模型、成本和审计。
• Unpaid Admins：安全、IT、采购或财务人员，只做管理和审计，不作为付费开发席位。

管理员不要按职位泛发。Cursor 管理权限会影响模型、隐私、成员、计费和安全策略，应该按 owner 责任发放。

5. MDM：限制企业设备只能进企业团队

MDM 是企业落地 Cursor 的关键防线。官方文档说明 Cursor 支持 macOS MDM，也支持 Windows 上的 Intune / Group Policy。

Allowed Team IDs

Allowed Team IDs 用来阻止企业设备登录个人 Cursor 账号或错误团队。Cursor 的本地 setting 是：

{
  "cursorAuth.allowedTeamId": "1,3,7"
}

这个值是逗号分隔的 Team ID 列表。用户登录不在列表里的团队时，Cursor 会强制退出并阻止继续认证。

企业级下发时应使用 MDM policy：

AllowedTeamId = "1,3,7"

MDM policy 会覆盖用户本地的 cursorAuth.allowedTeamId。这比要求员工自己配置可靠，因为它直接把企业设备和企业 Team ID 绑定起来。

Allowed Extensions

扩展可以读取工作区，所以不能默认全开放。Cursor 支持用 extensions.allowed 控制允许安装的 publisher 或完整 extension ID：

{
  "anysphere": true,
  "github": true,
  "esbenp.prettier-vscode": true,
  "ms-azuretools.vscode-containers": false,
  "dbaeumer.vscode-eslint": ["3.0.0"],
  "github.vscode-pull-request-github": "stable"
}

官方文档说明 Admin Portal 里的 Allowed Extensions 需要 Cursor client 2.1 或更高版本；MDM AllowedExtensions 会覆盖 Admin Portal 和用户本地设置。

生产环境建议：

• 默认只允许基础开发扩展、公司自有扩展和已审查的安全扩展。
• 高权限扩展必须有 owner、用途、版本范围和回滚方案。
• 扩展白名单变更要进入安全审查或平台变更流程。

6. .cursor 文件夹：共享规则前先查敏感信息

项目打开后，Cursor 会在仓库根目录创建 .cursor 文件夹。官方文档说明它可能包含：

• 项目级 settings。
• indexing cache。
• rules 和项目上下文。

这个目录可以提交到 Git，让团队共享规则和配置。但提交前必须检查：

• rules 里没有密钥、token、账号、内部 URL、客户数据。
• 项目规则只写工作方式，不写不能公开的凭据。
• 公共仓库、开源仓库和外包仓库要单独审查。

可以提交 .cursor/rules，不等于整个 .cursor 都适合提交。缓存、临时文件和敏感上下文要按项目规则排除。

7. Workspace Trust：降低陌生工作区风险

Workspace Trust 控制用户打开新工作区时是否需要确认信任。对应 setting 是：

{
  "security.workspace.trust.enabled": true
}

MDM policy 是：

WorkspaceTrustEnabled = true

启用后，未信任 workspace 会以受限模式运行，减少打开未知目录、外部仓库或下载包时的风险。

8. 商业级验收

上线前至少完成这些检查：

• SSO 已强制，普通密码登录无法绕过。
• SCIM 的新增、转组、离职回收都实测通过。
• 企业设备只能登录指定 Cursor Team ID。
• Admin 和 Unpaid Admin 有 owner 名单，不靠默认全员管理。
• Allowed Extensions 有白名单、版本策略和变更记录。
• .cursor 提交策略写进仓库规则，敏感信息扫描通过。
• Workspace Trust 策略在 macOS 和 Windows 设备上都已验证。
• 例外账号、外包账号和自动化账号都有到期时间。

9. 常见失败点

• SSO 能登录，但没有禁止密码登录。
• SCIM 只测新增，没测离职回收。
• 企业设备仍能登录个人账号，导致 Privacy Mode 和模型策略失控。
• 扩展白名单只按 publisher 放开，没有限制高风险扩展。
• 把 .cursor 目录全部提交，带入缓存、内部路径或敏感上下文。
• 给太多人 Admin，后来没人知道谁改了安全和计费策略。

官方来源

• https://cursor.com/docs/enterprise/identity-and-access-management.md
• https://cursor.com/docs/account/teams/sso.md
• https://cursor.com/docs/account/teams/scim.md
• https://cursor.com/docs/account/teams/members.md
• https://cursor.com/docs/enterprise/deployment-patterns.md

接下来去哪