CursorのTeams／Enterpriseを管理する人へ：SSO・SCIM、Privacy Modeの強制、端末とネットワークの制御、使用量、監査ログを、公式ドキュメントで確かめる

この記事は公式ドキュメントとヘルプを2026年10月24日に読んでまとめたもので、実際に使って確かめた記録ではありません。運営者はCursorを入れていますが、使い心地はこの記事には書いていません。画面の項目名、設定のキー、URL、コマンド、APIの例は公式の表記を写したもので、動作確認はしていません。公式の文章は要約の形で取得したため、引用は最小限にし、ほとんどは言い換えています。ダッシュボード全体を説明するページ（Dashboard）は、取得が許可されず読めていません。そこは書かず、読めた別のページの範囲だけで書きました。セキュリティ、契約、法律の助言ではありません。

先に結論

• まず、自分のチームがどの系統か確かめる。 SSOは Teams と Enterprise の両方、SCIM、監査ログ、モデルの制限、リポジトリのブロックリスト、ユーザー別の使用上限は Enterprise です（公式のEnterpriseページの表）。
• 順番は公式の推奨に沿う。 Identity and Access Management のページは、SSO、SCIM、MDMのポリシー、役割の割り当て、の順を推奨しています。
• 強制できるものと、お願いにすぎないものを分ける。 Privacy Mode の強制、SSO、MDM のポリシー、Hooks の failClosed は仕組みで効きます。Team Rules、許可リスト、.cursorignore は、公式自身が「提案」「ベストエフォート」「セキュリティの境界ではない」と書いています。
• 使用量は、上限を先に決める。 設定しなければ上限なし、と書かれているのは、The X SubscriptionのTeamsとサービスアカウントです。旧プランの既定値は書かれていません。
• 監査は、何が記録されないかを先に知る。 失敗したサインインも、プロンプトも、生成コードも記録されません。

前提：用語をそろえる

プランの料金、席の種類、週ごとのプール、前払いクレジットは、前のガイド（03）に書いたので、ここでは管理の側面だけを扱います。Rules、Hooks、MCP、Cloud Agents の使い方は、ほかのガイドに任せ、ここでは「管理者がどう配り、どう縛るか」に絞ります。

プランごとに何が管理できるか

公式のEnterpriseのページ（確認日10月24日）にある、プラン別の表から主なものを写します。

表のSSOの欄には「SAML/OIDC」と書かれています。しかしSSOの設定ページとIAMのページは SAML 2.0 とだけ書いており、OIDCの説明は読んだ範囲で見つかりませんでした。OIDCで使えるかは、表の表記だけでは決められません。

EnterpriseのヘルプのページはEnterpriseを、Teamsの内容に加え、プール使用、請求書や発注書での支払い、SCIM、AIコード追跡のAPI、監査ログ、CMEK（顧客管理の暗号鍵）、Self-Hosted Machines、優先サポートを含むものと説明しています。価格は載らず、問い合わせフォームから見積もりを依頼します。サポートの応答目安は、Enterpriseが最初の人の返信まで重大で8時間、通常で24時間と、Enterpriseの概要ページにあります。

最初に決めること：TeamかOrganizationか

• Teamで足りるか。 Teams では1つのアカウントが同時に1つのチームに属します。Enterprise の Organization では、同じ組織の複数のチームで、人ごとに別の役割を持てます。公式のOrganizationsのページは、各チームが自分のメンバー、役割、使用量の画面、プライバシー設定、使用量の制御を持つと書いています。
• SSOの置き場所。 チームごとのSSO（Team Settings）と、組織全体のSSO（Organization's Settings）があります。複数チームを束ねる会社には、公式は組織全体のSSOを勧めています。以下の手順は、特に断らないかぎりチーム単位です。
• 管理者の範囲。 チームの管理者になっても、組織の管理者の権限は付きません。
• 管理者が辞めたら。 ヘルプには、ほかの管理者に頼むか、いなければサポートに連絡して回復する、とあります。管理者を1人にしない、というのは僕らの見立てです。

SSO：公式の手順

公式のSSOのページの内容です。必要なのは、Cursor側のチーム管理者のアクセスと、IdP（ページの例はOkta）の管理者のアクセスです。

1. チーム管理者でサインインし、https://cursor.com/dashboard/team-settings#single-sign-on-sso を開く。
2. 「Single Sign-On (SSO)」の節を開き、「SSO-Provider Connection Settings」の横の「Configure」を押して、ウィザードに従う。
3. IdP側で、新しいSAMLアプリケーションを作り、Cursorの情報を入れ、JIT（Just-in-Time）プロビジョニングを設定する。入れるべき具体的な値は、ページに載っていません。
4. 「Domain Verification Settings」の横の「Configure」を押して、利用者のドメインを確認する。

IdP別の手順（Okta、Azure AD、Google Workspace など）は、WorkOSの連携ガイド（workos.com/docs/integrations）に案内されています。

強制の考え方。 SSOのページは、強制用の別のスイッチはなく、ドメイン確認とSSO接続が両方有効になると、そのドメインのユーザーはSSOでログインする、と書いています。IAMのページは、全メンバーにSSOを必須にしてパスワード認証を止められる、と書いており、書きぶりが違います。同じことの言い換えに見えますが、確かめきれていません。

JITとドメイン。 SSOで初めてログインした人は自動で登録されます。管理はIdPで行います。ドメインが複数あるときは、ドメインごとに確認し、IdP側でも設定します。Teamsには、確認済みの同じドメインのメールを持つ人が招待なしで参加できる「ドメイン参加」もあり（オプトイン）、設定は cursor.com/dashboard/settings#domain-join と書かれています。

よくあるつまずき。 Microsoft Entra ID で AADSTS50105（User is not assigned to this application）が出るのは、利用者がCursorのエンタープライズアプリに割り当てられていないためです。直接割り当てるか、割り当て済みグループの直接のメンバーにします。入れ子のグループでは足りないことが多い、と公式は書いています。保存して数分待ち、もう一度ログインしてもらいます。ほかに、ドメインが確認済みか、SSO接続が有効か、SAMLの属性の対応づけ、IdPとCursorで姓名が一致しているか、が確認項目に挙がっています。

書かれていないこと。 SAMLの具体的な値、ウィザードの1つ1つの手順、SSOで作られたユーザーへの役割の割り当て。読んだ範囲では見つかりませんでした。

SCIM：メンバーとグループをIdPから動かす

公式のSCIMのページの内容です。条件は、Enterpriseで、SSOの接続が有効なことです。

Cursor側。 SSOが動いているのを確かめ、「Active Directory Management」（cursor.com/dashboard/members?subtab=active-directory、または設定の「Members & Groups」の「Directory Groups」タブ）を開き、SCIMのウィザードに従います。Cursorが用意するエンドポイントとトークンを、IdPに入れます（ウィザードのどこに出るかは、ページに書かれていませんでした）。

IdP側。 SCIMのアプリケーションを作り、エンドポイントとトークンを入れ、「ユーザーのプロビジョニング」と「グループのプッシュ」を有効にし、接続をテストします。グループの同期はユーザーの同期とは別に設定します。ベースURLの書式と属性の対応づけは、このページには書かれていませんでした。

ユーザーの出入り。 IdPでSCIMアプリケーションに割り当てると追加され、「明示的に割り当てられたユーザーだけがCursorに現れる」と公式は書いています。割り当てを外すと削除です。名前とメールの変更は自動で同期します。プロビジョニングされたユーザーは、最初にサインインするまで Members のダッシュボードに出ません。

グループと役割。 同期されたグループとメンバーは、Cursorでは読み取り専用です。チームの中では、グループが使用量の上限とポリシーを決めます。役割をディレクトリから動かすには、ディレクトリグループを Organization Group に同期し、チームに役割つきで割り当てます。グループが役割を決めると、ダッシュボードから変えられなくなります。グループ別のユーザー上限は、チーム全体の既定を上書きし、複数のグループに入る人には、いちばん高い上限が適用されます。

外すときの落とし穴。 SCIMの導入前からチームにいた人は、自動では外れません。Members のダッシュボードから外すか、一度SCIMで同期してからIdPで外します。

役割と席

公式の「Members, Roles, and Seat Types」のページの内容です。

• Unpaid Admin はIT部門や経理向けの、席を使わない管理者です。存在するには、チームに有料のメンバーが少なくとも1人必要です。チームには Admin も常に1人以上必要です。
• 席は Premium（月$30）、Super（月$100、Premiumのプールの3.75倍）、Ultra（月$200、同12.5倍）で、MemberにもAdminにも割り当てます。$0の「Free」の席もあり、メールの招待か Seat メニューで割り当て、招待リンクでは割り当てられません。以前のTeamsは Standard（月$40）と Premium（月$120）の席を使います。
• アップグレードは即時で日割り請求、ダウングレードは期間の終わりに効きます。
• メンバーを外しても、そのCursorのアカウントとデータは消えません。クレジットを使っていた人の席は、請求期間の終わりまで埋まったままです。メンバーは自分でチームを抜けられず、管理者が外します（ヘルプ）。
• ヘルプによると、旧体系のTeamsに入った人の個人の旧プランは自動で解約されますが、The X Subscription のTeamsに入っても個人プランは解約されません。本人が自分で解約します。

Privacy Modeを強制する

Privacy Mode の中身は前のガイド（02）に書きました。ここでは、管理者が全員に守らせる方法を整理します。

前のガイド（02）にも書いたとおり、Teamsの既定を明記しているのはヘルプで、今回もヘルプは「既定で有効」と書いていました。一方 docs は、Enterpriseの既定オンは書くものの、Teamsの既定は書いていませんでした。強制の画面での項目名は、読んだ範囲では見つかりませんでした。実際の画面で確かめてください。

強制が効かない場面（公式の記載）。

• 個人アカウント。 会社のパソコンで社員が個人のCursorアカウントにログインすると、そのアカウントは会社の強制の外です。公式は、MDMの Allowed Team IDs で、ログインできるチームを絞るよう書いています（次の節）。
• BYOK。 自分のAPIキーでは、ZDRは提供元との契約に従います。hardening のページは、CursorのZDRに頼るなら、個人のAPIキーを制限するよう勧めています。
• 提供元がデータを保持するモデル。 Privacy and Data Governance のdocsは、Claude Fable 5.1 と Claude Fable 5 では、Anthropic が有害利用の確認のため入出力を保存し、学習や製品改善には使わないと書いています。EnterpriseとPrivacy Modeの顧客では、管理者がダッシュボードで保持の方針を承認するまで、これらのリクエストは失敗します。承認はチーム全体に効き、管理者はグループごとに選べるかどうかを絞れます。
• Grok Bot。 エディタのPrivacy Modeは、別の製品面である Grok Bot には及びません（ヘルプ）。

データの置き場所と暗号化（Enterprise）。 データレジデンシーはチーム単位で有効にでき、推論、処理、保存（バックアップを含む）が対象です。いま使えるのは米国のみで、EUとUKは推論のみで要望があれば、EU/EEAとAPACは開発中と書かれています。有効にするのは担当者経由で最大2週間、対象モデルに10%の上乗せがあります。SSO、BYOK、@Web、MCP、Bugbotなどは、リージョンの外に出うる機能として挙げられています。通信はTLS 1.2以上、保存はAES-256で、CMEKはEnterpriseのCloud Agentのデータが対象です。Cloud Agentの保持は、Enterpriseで「無期限」か「90日」を上限に選べます（hardening）。

端末側のポリシー：MDMで配る

公式の Deployment Patterns と IAM のページの内容です。MDMのポリシーが設定されると、その値が、対応するCursorの設定を上書きします。

Allowed Team IDs。 値はチームIDのカンマ区切りで、公式の例は "1,3,7" です。許可外のIDでログインすると、すぐにログアウトされ、有効なチームIDでログインするまでブロックされます。

Allowed Extensions。 キーは発行元の名前か完全な拡張機能のID、値は真偽値、バージョンの固定、リリースチャンネルです。大事なのは、エントリが1つでもあると、明示的に許可されたものだけが入れられる点です。公式の例の {"anysphere": false} は、ほかのすべての発行元もまとめてブロックします。特定のものだけを禁止するなら "*": true を足します。公式の例は次のとおりです。

{
  "*": true,
  "untrusted-publisher": false
}

信頼する集合だけに絞る公式の例です。

{
  "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"
}

ダッシュボードの Security & Identity でも設定できます（クライアント2.1以降）。公式の警告は、ダッシュボードの欄を空にしても、すでにクライアントに適用されたポリシーは消えない点です。許可をすべてに戻すには、先に {"*": true} を配り、クライアントが更新されてから、欄を空にします。MDMの AllowedExtensions は、ダッシュボードとユーザー設定の両方を上書きします。

macOS。 構成プロファイルを使い、PayloadType はチャンネルのバンドルIDに合わせます（製品版は com.todesktop.230313mzl4w4u92）。公式のキーの例です。

<key>AllowedExtensions</key><string>{"anysphere": true, "github": true}</string>
<key>AllowedTeamId</key><string>1,3,7</string>
<key>NetworkDisableHttp2</key><true/>
<key>UpdateMode</key><string>none</string>
<key>WorkspaceTrustEnabled</key><true/>

アプリ内の Contents/Resources/app/policies/ に、全ポリシーを設定した参照用のプロファイルがあります。編集しなかったポリシーは既定の値を強制するので、不要なものは消すよう公式は書いています。macOSでは更新に管理者権限が要るため、更新を中央から配るか、UpdateMode を none にします。

Windows。 AppData\Local\Programs\cursor\policies の ADMX と ADML を、C:\Windows\PolicyDefinitions などに置いてグループポリシーで設定します。コンピュータ側がユーザー側より優先されます。レジストリのパスは、読んだ範囲では書かれていませんでした。

Linux。 Cursor 2.0以降で ~/.cursor/policy.json が使えます。公式の例を整形すると次のとおりです。AllowedExtensions は、入れ子のオブジェクトではなく、引用符をエスケープしたJSON文字列です。

{
  "AllowedExtensions": "{\"anysphere\": true, \"github\": true}",
  "AllowedTeamId": "1,3,7",
  "WorkspaceTrustEnabled": true
}

ファイルがない場合も、JSONが不正な場合も、Cursorは制限なしで動きます。環境変数は使えません。

Workspace Trust と許可リスト。 Workspace Trust は既定で無効です（前のガイド02）。公式は、制限モードではAI機能が限られるので、本当に信頼できないものにだけ使うよう書いています。~/.cursor/permissions.json をMDMで配ると、確認なしで動かしてよいコマンドとMCPのツールを揃えられ、管理者のチーム設定が優先されます。

ネットワーク：SSL検査とテナント制限

ドメインとSSL検査。 Network Configuration のページは、SSL検査を外すよう、.cursor.sh、cursor-cdn.com、marketplace.cursorapi.com、authenticate.cursor.sh、authenticator.cursor.sh、*.cursorvm.com、*.*.cursorvm.com を挙げています。サインインには accounts.spacex.ai と accounts.x.ai も要ります。IPの許可は、IPが変わるので、*.cursor.sh などのドメインのパターンで行うよう勧めています。公式は、SSL検査は導入の障害の定番で、タイムアウトやAgentのエラーの原因になりやすいと書き、在宅や出張先のプロキシ設定にも同じ除外を入れるよう勧めています。つながりの確かめ方として curl -v https://api2.cursor.sh |& grep -C1 issuer: が示され、発行元がAmazonなら検査なし、プロキシ製品の名前なら検査ありです。通信は既定でHTTP/2の双方向ストリームで、だめなら HTTP/1.1 のSSEに切り替わります。

テナント制限。 自社のネットワークから使えるCursorの組織とチームを、プロキシで絞る仕組みです。ヘッダーを付けるのはクライアントではなく会社のプロキシで、ダッシュボードに設定はありません。公式の例の値は次のとおりです。

x-cursor-allowed-tenants: v1.orgs=1001,1002;teams=70

• 値の形は v1.orgs=<組織ID>;teams=<チームID> です。上の例は、組織が1001か1002のどちらかで、かつチームが70であることを求めます。IDは数字だけで、ヘッダーは最大8個まで付けられ、すべてを満たす必要があります。
• 空の値や不正な値は「制限なし」ではなく拒否されます。ヘッダーがまったくない場合だけ、制限なしです。
• 付ける先は api2.cursor.sh（サインインを含む）と cursor.com です。TLSを終端するプロキシが最も確実だと書かれています。
• 組織IDは、公開の org_ で始まるものは使えず、数字のIDを監査ログのイベントから取る、とあります。
• 限界：デスクトップアプリはまだエラーを画面に出さず、ログインが待ち画面のままになったり、更新のときに説明なしでログアウトされたりします。ヘッダーは自社のネットワークを通る通信にしか効きません。Allowed Team IDs のような端末のポリシーとは別の仕組みです。ページに、特定のプランの記載はありませんでした。

エージェントを管理者が縛る

前のガイド（02）では、Run Modesと許可リストを利用者の目線で書きました。管理者が決められる部分を、公式のEnterprise、LLM safety and controls、Model and Integration Management、hardening の記載から拾います。

• Run Modeのポリシー。 Enterprise のチームは、ダッシュボードでRun Modeのポリシーを決められます。hardening は、組織のポリシーを Auto-review にし（Run Everything にしない）、サンドボックスを有効にするよう勧めています。ただし分類器はベストエフォートなので、Hooksと組み合わせるように、という注意つきです。
• Browser Controls と .cursor Directory Protection。 どちらもEnterprise限定で、チームのダッシュボードにあります。前者はブラウザの道具が訪れてよいサイトを許可リストで絞り、後者はエージェントが .cursor/ の中を書き換えるのを防ぎます。
• MCPの許可リスト（Enterprise）。 「MCP Configuration」で、承認するサーバーをコマンドかURLで足し、サーバーごとに使えるツール（欄が空ならすべて）とネットワークの扱いを決めます。優先順位は、チームのダッシュボード、~/.cursor/permissions.json、エディタの設定の順で、上のものが下のものを置き換えます（合わさりません）。有効なとき、当てはまらないサーバーは動きません。許可リストはサーバーを利用者のパソコンに入れるものではない、とも書かれています。
• Repository Blocklist（Enterprise）。 ブロックしたリポジトリは、Cursorが索引づけも作業もしません。ただし、効くのはエディタとCLIだけで、Cloud Agents、Automations、Bugbotには効きません。
• Protected Git Scopes（Teams、Enterprise）。 ダッシュボードの Integrations タブで、Gitの組織や名前空間を自分のCursorの組織にロックし、Cloud Agents、Automations、Bugbotに効かせます。申請には、Cursorのチーム管理者がGitプロバイダの管理者でもある必要があります。
• Team Rules、Hooks、プラグイン。 Team Rules は「Enforce this rule」で必須にできますが、公式は、ルールは提案であり確定的ではないと書き、Hooksなどと組み合わせるよう勧めています。Hooks は、Teams が MDM、Enterprise が MDM とサーバー側で配布でき、止めたいものには failClosed を使います。ダッシュボード経由のHooksは failClosed が使えず、止める動きが要るならMDMで配る、という点は前のガイド（04）に書いたとおりです。プラグインは、何が入るかを確かめ、非公開のチームのマーケットプレイスを優先するよう書かれています。
• .cursorignore。 秘密や規制対象のパスを入れつつ、ターミナルとMCPのツールは従えないので、承認とファイルの権限を併用するよう書かれています。

モデルとBYOK（Enterprise）。

• 「Team Settings → Models」で、「Cursor Models」と「Other Models」のモデルを切り替え、「Model Defaults」で新しい提供元やモデルの既定を決め、「Personal API Keys (BYOK)」でBYOKを管理します。新しいモデルは自動では有効にならず、オプトインが要ります。
• 「Organization → Groups → [グループ] → Models」で特定の集団だけに広げられます。合わさるときは、いちばんゆるい側（和集合）です。グループは、ほかの経路が許しているモデルを禁止できないので、厳しい既定はチームに置くよう勧められています。
• BYOKを止めると、OpenAI、Anthropic、Azure、AWS Bedrock の自分のキーが使えなくなり、使用はすべてCursorのモデルとプールを通ります。Organization Group の Models の設定は、BYOKを制御しません。
• 落とし穴。 Auto-review の分類器は、Gemini 3.5 Flash Lite が主で、Claude 4.5 Haiku が予備です。Haiku をブロックすると、チームのRun Modesに入っていても、IDEのAuto-reviewが使えなくなることがあります。Bugbot が使えるモデルがすべてブロックされると、レビューが止まり、PRのチェックは neutral で終わります。

使用量を管理する

使用量の仕組みは前のガイド（03）に書きました。ここでは、管理者が上限を決める操作を整理します。

• 公式のSpend limitsのページ（旧プランの説明）によると、変更は即時に効き、「No Limit」で上限が外れます。上限に達すると、その人の追加分だけが止まり、次の期間で再開します。ただし旧Teamsのチーム全体の上限は、オンデマンドを使っている全員のAI機能を止めます。
• 止まる前に上限を少し超えることがあります。超えた分は返金ではなく一時的な上限クレジットとして扱われ、同じ期間に上限を上げると、一部や全部が請求対象になりえます。複数の経路で上限がある人には、いちばん高いものが適用されます。
• 既定の上限値は、読んだ範囲では書かれていませんでした。

請求グループ（Enterprise）。 支出の把握、社内の費用配分、予算づくりのためのものです。「Members & Groups」から「Create Group」で作り、メンバーはSCIMの同期、Admin API、CSV、手動の4通りで割り当てます。1人は同時に1つのグループだけで、どこにも入らない人は「Unassigned」です。使用量は使ったときの所属に付き、SCIMで同期したグループは手動やAPIでは編集できません。削除は元に戻せません。グループごとの上限は、ページに書かれていませんでした。

サービスアカウント（Enterprise）。 人ではない自動化用のアカウントです。「Dashboard → Settings → API Keys → Service Accounts」で「New Service Account」から作ります。APIキーは「一度しか表示されない」ので、すぐ控えます。席は使いませんが、使用量はチームのプールから引かれます。Cloud Agentの実行には、チームのレベルのGitHub連携が必要です。CLIでは CURSOR_API_KEY に入れます。回転すると古いキーはすぐ止まります。支出の上限は、新しいアカウントでは既定で上限なしで、「Edit spend limit」で決めます。アーカイブはキーを取り消して連携を壊します。公式は、ワークフローごとに別のアカウントを作るよう勧めています。

分析（Teams、Enterprise）。 管理者は、チーム全員のデータを見られます。AIが書いたコードの割合、Agentの編集、Tabの補完、アクティブユーザー、Cloud Agentの使用などがあり、ユーザー（最大10人）、グループ、日付（連続90日まで）で絞れ、CSVで書き出せます。データが集まるのは、クライアント1.5以上の利用者だけです。Enterprise向けの Conversation Insights は、ページに「2026年1月1日から推論の料金がかかる」と書かれていますが、すでに過ぎた日付で、いまの料金は読めていません。

Admin API。 ベースURLは https://api.cursor.com で、認証はAPIキーをユーザー名にした Basic 認証（パスワードは空）です。公式の例は次のとおりです。

curl -X GET https://api.cursor.com/teams/members \
  -u YOUR_API_KEY:

エンドポイントには、監査ログ（GET /teams/audit-logs）、日ごとの使用量（POST /teams/daily-usage-data）、今の請求期間の支出（POST /teams/spend）、ユーザー別の上限（POST /teams/user-spend-limit、Enterprise）などがあります。レート制限は、監査ログと日ごとの使用量が1チームあたり毎分20回などです。APIキーの作り方は、このページには書かれておらず、「API Overview」が案内されていました（読んでいません）。

OpenTelemetry Export（Enterprise）。 使用量のデータを、自分たちのコレクターにOTLPで送ります。設定は「Team Settings > OpenTelemetry Export」で、受け口は HTTPS の /v1/metrics と /v1/logs（gRPCとJSONは不可）です。宛先を作り、「Test connection」、「Enable」の順です。会話の内容は既定でオフで、チームの「Allow conversation content export」と宛先の「Conversation content」の両方をオンにしたときだけ送られ、対象はCloud AgentsとGrok Botだけです。内容の除去はパターンによるベストエフォートで、当たらない秘密はそのまま出ることがあり、そのリスクはチームが負う、と公式は書いています。

監査：何が残り、何が残らないか

公式の Compliance and Monitoring のページの内容です。Enterpriseだけで使えます。

記録されるもの。 サインイン、メンバー、役割、APIキー、設定、連携、Cloud Agentの環境、Origin のリポジトリなど、管理とセキュリティのイベントで、時刻、実行した人（またはキー）、クライアントのIP、製品の画面が付きます。種類には、login、add_user、remove_user、update_user_role、privacy_mode、user_spend_limit、team_settings、team_hook、mcp_server_config、organization_identity_provider などがあります。

記録されないもの（公式が明記）。

• プロンプト、エージェントの返答、生成コード（これにはHooksを使う、とあります）。
• Cloud Agentの自動化（Automation）の実行。grok_bot_routine はGrok Botのルーティンだけを対象にします。
• 失敗したサインイン（login は成功だけ）。
• 秘密の値そのもの（Cloud Agentの秘密は名前と範囲だけ）。
• Grok Botのシェルとブラウザの操作（OpenTelemetry Exportへ）。
• Privacy Mode は監査イベントを抑えませんが、中身にプロンプトや生成コードは入りません。例外が team_hook で、Hooksのスクリプトやプロンプトの文面が入ります。

取り出し方。

• ダッシュボードの監査ログのページ。日付、イベントの種類、実行した人、アプリケーションで絞り、CSVで書き出せます。
• Admin API の GET /teams/audit-logs（チームのAPIキー）と GET /organizations/audit-logs（組織のAPIキーで auditlogs:read か admin:*）。既定で直近7日、最大30日の窓、1ページ500件まで、古い順です。
• SIEMへの送信は、Splunk HTTP Event Collector、Sumo Logic、HTTPSのWebhook、S3が対象で、設定には hi@cursor.com へ連絡する、と書かれています。

注意。 user_email には、メンバーのメールのほか、Api Key: <名前>、Bot: <所有者のメール>、SCIM、System、unknown、Cursorのサポートによる変更の場合の hi@cursor.com などが入ります。SCIMによる追加や削除は、人の名前ではなく SCIM として残ると読めます。

読んだ範囲で見つからなかったこと。 監査ログの保存期間は、2回確かめましたが書かれていませんでした。ダッシュボードで何日遡れるかは分かりません。長く残したいなら、SIEMかAdmin APIで外に出すのが前提になりそうです（僕らの見立てです）。

最初の10分でやること

公式のAdmin Setup Guideの順序は、Trust Center（trust.cursor.com）の確認、SSO（任意でSCIM）、Gitプラットフォームの接続、MDMのポリシーの配布と AllowedTeamIDs、ダッシュボードでの使用量の監視です。Gitの接続は、管理者が済ませるまで、リポジトリからCloud Agentを始められないと書かれています。以下は、それを踏まえた僕らの整理で、公式の順序そのものではありません。

1. 自分の役割とプランを確かめる。 「Single Sign-On (SSO)」が出るか、Admin か Unpaid Admin かを見ます。管理者が自分1人なら、もう1人を管理者にします。
2. Privacy Mode を強制する。 チームのダッシュボードで、有効か、メンバーが切れない強制になっているかを見ます（設定の場所は公式で確認できていません）。
3. 使用量の上限を決める。 The X SubscriptionのTeamsなら grok.com/dashboard/billing、旧プランなら Spending タブです。
4. SSOを入れる。 IdP担当と一緒に、接続とドメイン確認を済ませます。両方が有効になってから、利用者に告知するのが無難です。
5. MDMの設定を決める。 AllowedTeamId を配る手配をします。拡張機能は、"*": true を付けるか否かで意味が逆になるので、先に決めます。
6. ネットワーク担当に、SSL検査の除外ドメインを渡す。
7. Enterpriseなら、監査ログの送り先を決める。 保存期間が読めていないので、SIEMかAdmin APIか、早めに決めます。

誤解されやすい点

• 「Privacy Modeを強制すれば、全員のコードが守られる」わけではない。 個人アカウントでのログイン、BYOK、提供元がデータを保持するモデル、Grok Bot は、別の扱いです。
• 「Team Rulesで禁止すれば、AIは従う」わけではない。 公式自身が、提案であり確定的ではないと書いています。止めたいことは、MDM、Hooks（failClosed）のような仕組みの側に置きます。
• 「Repository Blocklistに入れれば、クラウド側でも使われない」わけではない。 エディタとCLIにしか効きません。
• 「監査ログがあるから、誰が何を聞いたかも分かる」わけではない。 プロンプトも生成コードも入りません。
• 「上限を決めたから、その額で必ず止まる」わけではない。 止まるまでに少し遅れがあり、旧プランでは、超えた分が一時的な上限クレジットとして扱われます。
• 「SSOを入れれば、辞めた人のアクセスも自動で止まる」とは書かれていない。 公式は、SCIMで、IdPから外すと失われる、と書いています。SCIMの導入前からいる人は自動で外れません。

気をつけること

• この記事は、実際に使って確かめた記録ではありません。運営者はCursorを入れていますが、使い心地はこの記事には書いていません。画面の項目名、URL、キー、コマンド、APIの例は、公式の記載を写したもので、動作確認はしていません。
• 取得したのは、ページの要約です。JSONやplistの例は、要約が示したものを整形したもので、元のページの全文ではありません。
• 読めていないもの：Dashboard（取得が許可されず）、Teamsの設定ページ、Endpoint security、Cyber Safeguards、HIPAA BAA、Cursor Blame、API Overview、Organization Groups と Organization API の個別ページ、WorkOS側のIdP別ガイド、SSOのトラブルシューティングの個別ページ、Grok Botの管理のページ。SAMLの具体的な値、SCIMのベースURLと属性の対応づけ、Privacy Mode強制の画面の項目名、監査ログの保存期間は、読んだ範囲で見つかりませんでした。
• 公式のページ同士で、書きぶりが違う点があります。SSOの強制の説明、SSOの方式（SAML 2.0 とだけ書くページと、SAML/OIDC と書く表）、TeamsのPrivacy Modeの既定（ヘルプは明記、docsは書いていない）です。
• 管理画面のURLに、cursor.com/dashboard と grok.com/dashboard が混在しています。プランの系統で見るべき画面が違う可能性があります。契約前に、自分のアカウントの画面で確かめてください。
• 版つきの記載（クライアント2.1以降など）や、プレビューと書かれたAPIは変わることがあります。使う前に最新の表示を確かめてください。
• 契約、データ保護、コンプライアンスに関わる判断は、公式の最新の文書、自社の契約、専門家で確かめてください。この記事は、セキュリティや法律の助言ではありません。

出典

• Enterprise（Cursor Docs、Cursor、10月24日確認）
• Admin Setup Guide（Cursor Docs、Cursor、10月24日確認）
• Identity and Access Management（Cursor Docs、Cursor、10月24日確認）
• SSO（Cursor Docs、Cursor、10月24日確認）
• SCIM（Cursor Docs、Cursor、10月24日確認）
• SSO and authentication（Cursor Help、Cursor、10月24日確認）
• Organizations（Cursor Docs、Cursor、10月24日確認）
• Members, Roles, and Seat Types（Cursor Docs、Cursor、10月24日確認）
• Get Started with Teams（Cursor Docs、Cursor、10月24日確認）
• Manage your team（Cursor Help、Cursor、10月24日確認）
• Privacy and Data Governance（Cursor Docs、Cursor、10月24日確認）
• Privacy and data（Cursor Help、Cursor、10月24日確認）
• Deployment Patterns（Cursor Docs、Cursor、10月24日確認）
• Network Configuration（Cursor Docs、Cursor、10月24日確認）
• Tenancy Restriction（Cursor Docs、Cursor、10月24日確認）
• LLM Safety and Controls（Cursor Docs、Cursor、10月24日確認）
• Security and Privacy Hardening（Cursor Docs、Cursor、10月24日確認）
• Model and Integration Management（Cursor Docs、Cursor、10月24日確認）
• Compliance and Monitoring（Cursor Docs、Cursor、10月24日確認）
• OpenTelemetry Export（Cursor Docs、Cursor、10月24日確認）
• Spend limits（Cursor Help、Cursor、10月24日確認）
• Analytics（Cursor Docs、Cursor、10月24日確認）
• Admin API（Cursor Docs、Cursor、10月24日確認）
• Billing Groups（Cursor Docs、Cursor、10月24日確認）
• Service Accounts（Cursor Docs、Cursor、10月24日確認）
• Enterprise（Cursor Help、Cursor、10月24日確認）