Enterprise 總覽
用企業上線視角梳理 Cursor Enterprise 的安全、許可權、隱私、模型、審計和成本治理。
Cursor Enterprise 的核心不是“多買幾個賬號”，而是把 AI 程式設計工具納入企業治理：誰能用、能接觸哪些程式碼、能呼叫哪些模型、能建立哪些 Agent、成本歸到哪裡、審計證據怎麼留。
核驗日期：2026-05-09。Enterprise 能力、合規檔案、支援 SLA（Service-Level Agreement，服務等級協議——供應商對響應時間和可用率的承諾）、模型許可權和計費規則可能隨合同與後臺開關變化；採購、審計和上線前必須回到頁面底部官方來源複核。
1. 一句話判斷
如果團隊已經把 Cursor 用到生產程式碼庫，Enterprise 的價值是把“個人效率工具”升級成“可審計、可限制、可回收、可計費”的組織級開發平臺。
不建議從功能清單開始推進。正確順序是先過安全審查，再設身份生命週期，再定資料和模型邊界，最後用 Dashboard、Audit Logs、Analytics、Billing Groups 追蹤採用和成本。
2. Enterprise 覆蓋什麼
Cursor 官方把 Enterprise 文件分成幾條主線：
- 身份與訪問：SSO/SAML、SCIM、成員角色、MDM、Allowed Team IDs、Allowed Extensions。
- 隱私與資料治理：索引、LLM 請求、Cloud Agents 三類資料流，Privacy Mode、ZDR、DPA、CMEK。
- 網路與部署：代理、證書、IP allowlist、MDM 管理編輯器、自託管 CLI 等部署模式。
- Agent 安全控制：Hooks、終端沙箱、自動執行、瀏覽器、網路訪問、儲存庫 blocklist。
- 模型與整合治理：模型訪問限制、MCP、GitHub、Slack、Linear、Bugbot 等整合控制。
- 監控與合規：Audit Logs、SIEM 整合、AI Code Tracking API、Conversation Insights、Cursor Blame。
- 成本歸屬：Spend Limits、Pooled usage、Billing Groups、Analytics API、Service Accounts。
這些能力不要當成獨立開關看。真實上線時，它們會形成一條鏈路：身份決定誰能登入，MDM 決定只能登入哪個團隊，隱私策略決定程式碼如何流轉，模型和 Agent 策略決定能做什麼，審計和成本系統負責事後追蹤。
3. 上線順序
第 1 步：準備安全審查材料
安全、法務和採購通常先要這些材料：
- Trust Center：證書、第三方評估和安全材料。
- Security page：安全架構與控制說明。
- Privacy Overview：隱私承諾與資料處理說明。
- Data Processing Agreement：GDPR 相關的資料處理承諾。
- SOC2 Type II 與 GDPR 狀態：以 Trust Center 最新檔案為準。
不要把審查材料下載後長期複用。合規檔案有版本和有效期，正式簽約、續約、年度審計都要重新核驗。
第 2 步：先鎖身份，再發賬號
推薦順序：
- 配置 SSO，讓員工用企業身份登入。
- 啟用 SCIM，把入職、轉組、離職交給 IdP 生命週期管理。
- 下發 MDM 策略，限制企業裝置只能登入指定 Cursor Team ID。
- 設定成員角色，只給少數人 Admin 或 Unpaid Admin。
這裡最容易犯的錯是先讓全員試用，再補 SSO/SCIM。這樣會留下個人賬號、個人 Privacy Mode、個人 API Key 和無法統一回收的歷史用法。
第 3 步：定資料和模型邊界
上線前要把這些問題寫成內部策略：
- 是否強制 Privacy Mode。
- 是否允許 Cloud Agents 儲存臨時程式碼副本。
- 哪些模型可以用，是否允許 BYOK。
- 哪些儲存庫禁止 Agent 訪問。
- MCP、Slack、GitHub、Linear、Bugbot 是否按團隊開放。
- 自動執行、瀏覽器訪問、網路訪問、終端沙箱如何配置。
如果安全策略禁止任何程式碼在雲端暫存，就不要啟用 Cloud Agents；本地編輯器功能仍可繼續評估。
第 4 步：把採用和成本接進管理閉環
Enterprise 不只看“多少人開通”。更有用的是：
- Dashboard：團隊設定、成員、用量和管理入口。
- Analytics：團隊採用情況、使用趨勢和 Conversation Insights。
- AI Code Tracking API：按 commit 追蹤 AI 參與度。
- Cursor Blame：在 Git blame 層面區分 AI 與人工程式碼歸屬。
- Billing Groups：按團隊、部門或專案歸整合本。
- Service Accounts：把自動化工作流和真人賬號拆開。
4. 採購前檢查清單
- 合規材料已從 Trust Center 下載最新版，且審查範圍覆蓋 Cursor、模型供應商和 subprocessors。
- SSO、SCIM、RBAC、MDM 的目標狀態已經寫清楚。
- Privacy Mode、Cloud Agents、CMEK、DPA、BAA 是否需要已經定案。
- 網路訪問、代理、證書、IP allowlist、儲存庫 blocklist 有 owner。
- 模型許可權、BYOK、MCP 和第三方整合的預設開關已經確認。
- 成本歸屬方式已經對映到 Billing Groups 或內部成本中心。
- 審計證據接入 SIEM 或至少進入固定月度覆盤。
5. 試點 rollout 建議
先選一個邊界清楚的工程團隊做 2-4 周試點：
- 只開放少量生產儲存庫和一個內部模板儲存庫。
- 強制企業賬號、Privacy Mode 和 Allowed Team IDs。
- 停用未審查 MCP 與無 owner 的外部整合。
- 要求所有 AI 生成改動走 PR、測試和程式碼評審。
- 每週看採用率、失敗場景、超額用量和審計事件。
- 試點結束後再擴大到更多團隊和更高許可權 Agent 能力。
試點不是為了“證明 Cursor 有用”，而是驗證組織的許可權、審計、成本和回退機制能不能承受真實使用。
6. 常見失敗點
- 只採購 Teams/Enterprise，不做身份生命週期和裝置限制。
- 把 Privacy Mode 當成口頭承諾，沒有強制團隊策略和 MDM 約束。
- Cloud Agents、MCP、Hooks、GitHub、Slack、Linear 一次性全開，沒有分級准入。
- 只看月度總賬單，不按團隊、專案、自動化賬號拆成本。
- 審計材料散在採購、法務和工程文件裡，事後無法覆盤。
- 用過期截圖回答安全審查，沒有引用最新 Trust Center、DPA 和官方文件。
7. 商業級驗收
達到上線標準時，至少能回答這些問題：
- 離職員工多久會失去 Cursor 訪問權，誰驗證。
- 企業裝置能否登入個人 Cursor 賬號，證據是什麼。
- 哪些程式碼會被髮送給模型，哪些程式碼會被 Cloud Agents 臨時儲存。
- 哪些模型、MCP、瀏覽器、終端、網路動作被允許。
- 高風險儲存庫如何 blocklist，例外如何審批。
- AI 用量和成本如何歸因到團隊或專案。
- 審計日誌進入哪裡，保留多久，誰看異常。
官方來源
- https://cursor.com/docs/enterprise.md
- https://trust.cursor.com/
- https://cursor.com/security
- https://cursor.com/privacy-overview
- https://cursor.com/terms/dpa