チームおよびエンタープライズ向けGrok Bot

Grok Botは、リサーチ、運用、ドキュメント作成、ブラウジング、自動化など、日常業務を支える常設Botをチームの各メンバーに提供します。このページは、チームおよび組織の管理者、Grok Botの利用を許可するか判断するセキュリティレビュアー、そして自分が従う承認モデルを理解したいメンバー向けです。Grok Botの仕組み、Botがアクセスできる対象、設定可能なコントロール、Cursorが推奨する設定をまとめています。

利用可否

プランと請求に、プランと利用量の正式な一覧を掲載しています。

Grok Botの構成

Grok Botは、アプリケーション、ブラウザ、開発環境を操作するComputer useエージェントです。Cursorのクラウド上で稼働し、各ユーザーの作業は専用のクラウドコンピューターで実行されます。デスクトップアプリとモバイルアプリは、チャット、確認、承認を行うための軽量クライアントです。

セキュリティモデルは、次の4つの原則に基づいています。

• ユーザーごとの分離。 各ユーザーの作業は、他のユーザーとハードウェアレベルで分離されたマイクロ仮想マシンである専用のFirecracker マイクロVMで実行されます。
• デフォルトではアクセス不可。 Botが使用できるのは、ユーザーまたはチームから許可されたアカウントとプラグインのみです。
• 人による承認ゲート。 機密性の高い操作にはユーザーの承認が必要で、Auto Reviewという独立した確認モデルによって評価されます。
• 管理者による制御。 チームレベルのポリシーで、プラグイン、ネットワークへのアウトバウンドアクセス、委任を管理します。

各要素は次のように連携します。

1. ローカルマシン。 チャット、確認、承認はメンバーのデバイスで行われます。作業はホストされたコンピューターで実行されます。オプションのローカル実行では、デフォルトでコマンドごとに承認が必要ですが、無効にできます。
2. 環境。 ユーザーごとに1つの永続的なFirecracker マイクロVMが用意されます。そのユーザーが実行するすべてのBotは、このコンピューターを共有します。管理者は、CursorダッシュボードのGrok Botページから、ネットワークポリシー、チームルール、セットアップスクリプト、組織全体の無効化スイッチ、任意のメンバーのコンピューターの終了を管理できます。
3. Bot。 ホストされたコンピューター内でシェル、ブラウザ、Computer useを行います。Botはデフォルトでアクセス権を持たず、メンバーがサインインしたアカウントのみを使用して操作します。ログイン、二要素認証、支払いの手順はメンバーに引き継ぎます。
4. プラグイン。 チームのCursor MCP (Model Context Protocol) ポリシーが全面的に適用され、各コネクタを許可またはブロックします。OAuthトークンはCursorのコネクタバックエンドに保持され、Botはトークンを受け取ることなくツールを呼び出します。
5. Cloud Agents。 Grok Botは、既存のCloud Agentの制御下で、コーディングタスクを別のコンピューターに委任できます。管理者は起動を無効にできます。
6. モデルとデータ。 Cursorがモデルの選択を管理します。プライバシーモードを有効にすると、顧客データはトレーニングに使用されません。Cursorはサーバー側でこれを強制し、設定を確認できない場合、システムはデフォルトでトレーニングを行いません。

ユーザーの分離方法

各ユーザーには、ハードウェアレベルで分離された専用コンピューターが割り当てられます。あるユーザーが別のユーザーのコンピューターにアクセスすることはできません。各コンピューターは、独自のカーネル、メモリ、仮想デバイスを備えた Firecracker マイクロVMです。

同一ユーザー内では、分離の境界が異なります。そのユーザーのすべての Bot は1台のコンピューターを共有し、Bot が分離するのはコンピューティングリソースではなく、パーソナリティとワークスペースです。コンピューター上のログイン情報やファイルは、そのユーザーが実行するすべての Bot から利用できるものとして扱い、Bot が不要になったアカウントからブラウザをログアウトさせ、作業完了時には機密性の高い一時ファイルを削除してください。ワークロードごとに専用のコンピューターと認証情報一式が必要な場合は、専用の Cursor ユーザーを作成してください。

導入前に

• プライバシーモード (Legacy) を無効にします。 この設定ではGrok Botをまったく利用できず、有効化する前に変更を求められます。Team Settingsでプライバシー設定を確認してください。
• 共有エグレスアドレスに備えます。 会社で送信元IPに基づいてサービスを制限している場合は、静的エグレスIPを参照してください。
• メンバーがコンピューターから会社のツールにサインインする方法を決めます。 IDとサインインを参照してください。
• Grok Botが継承するポリシーを確認します：MCP設定、チーム ルール、Auto Reviewのチーム向け指示。

チームをセットアップする

管理者コントロール

ほぼすべての設定は、Cursor ダッシュボードの Grok Bot ページにあります。別の場所にある設定には、その旨を記載しています。

• Grok Bot を有効にする。 Grok Bot を有効または無効にする組織全体の切り替えです。無効にするとメンバーは利用できなくなりますが、メンバーのコンピューターは削除されません。
• ネットワーク ポリシー。 4 つのモード、グループ スコープ、ロックを設定できます。ネットワーク ポリシーを参照してください。
• Cloud Agents。 Cursor Cloud Agents への委任を許可またはブロックします。デフォルトでオンです。
• パブリック テンプレート共有。 オフにすると、Bot テンプレートの共有はチーム内に限定されます。ポリシーは既存のパブリック テンプレートを含め、Cursor のサーバーで適用されます。エンタープライズ プランのチームでは、パブリック共有はデフォルトでオフです。
• チーム ルール。 すべてのメンバーの Bot に適用されるルールです。ルールは常に必須で、任意にはできません。また、各ルールのスコープを Cursor、Grok Bot、またはその両方に設定できます。「会社のデータを個人アカウントに移さない」のように、短く少数に抑えてください。強制には、代わりに Auto Review の指示を使用してください。
• チーム セットアップ。 すべてのチーム コンピューターで実行される管理者用インストール スクリプトのマニフェストです。標準ツールをどこでも利用できるようにします。セットアップ スクリプトにシークレット値を含めないでください。
• コンピューター管理。 組織管理者は、任意のメンバーのコンピューターを確認し、作成日時と最終アクティブ日時を確認して終了できます。コンピューターはメンバーが所属するすべてのチームにまたがるため、チーム管理者権限では不十分です。永続ディスクは保持され、メンバーの次回セッションでは新しいコンピューターが起動します。
• Auto Review チーム指示。 すべてのメンバーに対するレビューアーの判断に反映される、チーム全体の許可・ブロック指示です。これらはチーム設定の「Security と Automation」にあります。
• ローカル実行。 メンバー自身のマシンで動作する Bot に関するポリシーです。ローカル実行を参照してください。
• アクション記録。 Bot のアクションを記録するエンタープライズ プランの設定で、デフォルトではオフです。イベントを自身のコレクターで受け取るには、OpenTelemetry エクスポート を設定してください。ログ記録と監査を参照してください。
• コネクタ ポリシー。 Grok Bot はチームの Cursor MCP における許可・ブロック ポリシーをそのまま継承します。Grok Bot 専用のコネクタ リストはなく、コネクタはアプリ内でプラグインとして表示されます。ポリシーは MCP server trust management で設定します。ポリシーによってサーバーがブロックされると、メンバーにはプラグインが チーム管理者により無効化済み と表示されます。必須またはデフォルトで有効なコネクタをメンバーにプロビジョニングすることはできません。

ネットワークポリシー

管理者はダッシュボードから、チームの Grok Bot のネットワークポリシーを設定できます。このポリシーにより、チームのコンピューターがアクセスできる送信先を制御します。

• 送信先には、Web ドメインのほか、raw 接続用のポート付き IP 範囲も指定できます。エントリ数に上限はありません。
• グループは独自のネットワークポリシーを設定でき、メンバーにはチームのポリシーの代わりに適用されます。ロックすると、チームのポリシーが全員に適用されます。
• このポリシーは Cloud Agent のネットワーク設定とは別で、コンピューターの作成時または再作成時に適用されます。新しいポリシーを反映するには、実行中のコンピューターを再作成または再起動してください。
• **egress を制限すると、データを送信できる先も制限されます。**専用のデータ損失防止フックは利用できません。

プラグインをブロックしても、そのサービスの Web サイトはブロックされません。コネクタポリシーとネットワークポリシーは別のレイヤーであり、両方の経路を閉じるには両方の制御が必要です。

静的エグレスIP

ホスト型コンピューターは、共有の静的エグレスIP アドレスを介してインターネットに接続します。これらの範囲は Grok Bot の顧客間で共有されており、顧客ごとの専用 IP は利用できません。そのため、チーム単独ではなく Grok Bot のトラフィックを識別するものとして扱ってください。現在の範囲については、アカウントチームにお問い合わせください。製品側の制御には、送信元 IP エディターではなく送信先許可リストを使用します。

会社で TLS トラフィックを検査している場合は、Cursor が公開しているホスト名を許可し、それらを検査対象から除外してください。最新のリストはアカウントチームから提供できます。

承認と Auto Review

承認により、影響の大きい操作をメンバーの管理下に置くことができます。最も強力な境界はリクエスト自体にあるため、Bot が変更してよい内容と、どこで停止すべきかをメンバーが明記するようにしてください。

キャンペーンデータを照合し、推奨する予算変更案を作成してください。キャンペーンは 変更せず、代理店にも連絡しないでください。現在の値、提案値、予想される影響を表示した後に 承認を求めてください。

操作に承認が必要な場合、会話には提案された操作とその入力内容が表示されます。今回のみ許可では Bot がその操作を続行でき、常に許可では一致するルールを保存でき、拒否では操作をブロックします (iPhone では、コントロールは Approve once と Deny です) 。承認の対象は提案された操作であり、すでに���了した作業ではありません。対象や影響を特定できない操作は、承認してはいけません。

Auto Review は、こうしたプロンプトの背後にある確認レイヤーです。独立した確認モデルが、リスクを伴う Bot の操作を実行前に評価します。対象には、シェルコマンド、プラグイン呼び出し、Computer use、自動化による書き込み (ルーチンやイベントトリガーの変更) 、Cloud Agent やサブエージェントの起動といった委任が含まれます。操作の続行を許可したり、承認を求めたり、拒否したりできます。

• Enforcement は Cursor により有効化されており、現在はすべてのユーザーに適用されています。 Auto Review をオフにできるのは各メンバー自身の設定のみです。セキュリティ上重要なデプロイでは、オンのままにするようメンバーに依頼してください。
• チームの指示は全員に適用されます。 管理者は、決して許容されない操作にはチーム全体向けのブロック指示を、日常的で安全な作業には許可指示を、チーム設定の Security と Automation で追加できます。
• メンバーは個人ルールを追加できます。場所は Settings > General > Auto-review です。Require Approval ルールは一致する操作を常に停止し、Always Allow ルールは確認で停止すべき他の理由がない場合にのみ、一致する操作の続行を許可します。両方に一致する場合は Require Approval が優先されます。「外部メールを送信する前に承認を必須にする」や「/workspace/reports での git status の実行を常に許可する」のように、既知の操作と範囲に絞ったルールが最も効果的です。「ブラウザ内のすべてを許可する」のような広範なルールは避けてください。個人ルールは現在のデスクトップに保存され、その Grok Bot コンピューター に同期されるため、別のデスクトップインストールでは個別に設定する必要があります。
• すべての副作用を確認するわけではありません。 たとえば、メモリへの書き込みやほとんどの設定変更は対象外です。明示的な境界と最小権限を補完するものとして扱い、モデルの判断に依存しない制御、つまり操作ごとの承認、ネットワークポリシー、ユーザーごとの分離と併用してください。

ID とサインイン

メンバーは Cursor アカウントで Grok Bot にサインインするため、既存の Cursor SSO 設定が適用されます。SAML 2.0 シングルサインオンは Okta、Microsoft Entra、Google Workspace、OneLogin に対応しています。すべてのメンバーに SSO を必須にすることもでき、その場合はパスワードでのログインがブロックされます。SCIM 2.0 プロビジョニングは エンタープライズ プランで利用できます。コンピュータのブラウザ向けのアプリ割り当てやサインインルールを含む、Okta および Entra ID の詳細な設定手順については、ID とアクセスを設定する を参照してください。

ホストされたコンピューターでは、新しいノートパソコンをセットアップする場合と同様に、メンバーはブラウザで自社のアイデンティティプロバイダーを通じてアプリケーションにサインインします。これらのセッションにはセッションポリシーが適用され、アイデンティティプロバイダーでユーザーを無効化すると終了します。

Bot には独自の ID や認証情報はありません。

• Bot はサインインしているメンバーとして動作します。 Bot が所属するメンバーを超えるアクセス権を持つことはありません。すべての操作は名前が特定されたメンバーに紐づけられ、アイデンティティプロバイダー以外に、プロビジョニング、ローテーション、監査が必要な独立したマシン ID は存在しません。唯一の例外はチーム管理のコネクタで、チームまたはサービスアカウントの認証情報を使用する場合があります。
• コネクタのトークンは Cursor のバックエンドに保持されます。 Bot は OAuth トークンを受け取らずにツールを呼び出し、トークンがコンピュータに保存されることはありません。
• 認証情報はメンバー側に保持されます。 ログイン、二要素認証、支払いの手順では、Bot は認証情報を入力するのではなく、コンピュータの操作をメンバーに委ねます。サポート対象の接続では、安全なシークレットリクエストにより入力値がマスクされ、会話記録やモデルには渡されません。パスワードやワンタイムコードを通常のチャットに入力しないでください。シークレットを安全に保存する を参照してください。

アクセスを迅速に取り消すには、ダッシュボードからメンバーのコンピュータを終了し (永続ディスクは保持され、次のセッションでは新しいコンピュータが起動します) 、アイデンティティプロバイダーでセッションを取り消します。アプリケーションのセッションはメンバーのコンピュータ上にのみ保持されます。

プロジェクトやログインを利用できないようにする場合、メンバーは直接クリーンアップします。関連するルーチンを一時停止または削除し、コンピュータ上の Web サイトからサインアウトし、プラグインをアンインストールしてソースサービスでその認可を取り消し、/workspace から機密性の高いファイルを削除します。Bot を削除しても、コンピュータのファイルやブラウザセッションは削除されません。

ログと監査

監査ログとアクション記録は別々のパイプラインを使用します。監査ログは管理およびセキュリティに関するイベントを対象とします。アクション記録は Bot のアクションを内部でキャプチャし、設定すると OpenTelemetry エクスポートによってそれらのイベントがお使いのコレクターに送信されます。

• エンタープライズプランの監査ログ には、管理者、セキュリティ、認証に関するイベントが記録されます。ダッシュボードで確認するか、SIEM にストリーミングできます。
• アクション記録 はエンタープライズプランの設定で、デフォルトではオフです。チームが有効にすると、Cursor は Bot のアクション (スクラブ済みのシェルコマンドを含む) を内部ストアに 90 日間保存します。サニタイズされたイベントを自社のコレクターで受信するには、OpenTelemetry エクスポートを設定してください。アクション記録のイベントは監査ログページには表示されません。

エンドポイントツール

Grok Botには、組み込みの顧客向けテレメトリーやEDRフィードはありません。コンピューターはCursorが運用するインフラであり、Cursorは運用上の健全性と不正利用を監視しています。このテレメトリーには、意図的に顧客データを含めていません。チームセットアップのマニフェストを使用すると、管理者はチーム内のすべてのコンピューターに独自のツールをインストールできます。

データの保持と削除

各メンバーのコンピューターでは、ローカルファイル、ブラウザセッション、ブラウザに保存されたすべてのデータが、セッションをまたいで永続ディスクに保持されます。

• アイドル状態のコンピューターは自動的に休止状態になります。 休止状態は削除ではありません。
• イメージの更新ではファイルが保持されます。 古いシステムイメージを使用しているコンピューターは、メンバーのファイルを保持したまま最新のイメージで再作成されます。
• メンバーによるリセットでは同期済みデータが保持されます。 メンバーはデスクトップアプリから自分のコンピューターをリセットできます。リセットしても同期済みの永続データは保持されますが、最近の未同期の作業は失われる���能性があります。Grok Bot コンピューターのデータを復元するを参照してください。
• 削除はDPAに従って行われます。 Data Processing Agreementに基づき、サービス終了後、書面による指示を受けてから30日以内にデータが削除または返却されます。
• バックアップは毎日実行されます。 Cursorの本番コントロールプレーンは、別の復旧施設に複製された暗号化済みの日次バックアップで保護されています。

組織ごとの保持ポリシーおよび個別のコンピューターに対する顧客管理のポイントインタイムリストアは利用できません。

データレジデンシー

Grok Bot computer は現在、米国で稼働しています。確認のために書面でのデータレジデンシーに関する確約が必要な場合は、アカウントチームにお問い合わせください。

モデルとデータ

Cursor がモデルの選択を管理します。顧客向けのモデルピッカーはなく、提供されるモデルの組み合わせは時間の経過とともに変更される場合があります。固定のベンダー構成は保証されません。利用分析には、フェイルオーバーを含め、各リクエストを実際に処理したモデルが表示され、請求も実際に処理したモデルに基づきます。

• チームのモデル許可リストはデフォルトで適用されますが、強制適用は保証されません。 オンボーディングでは、Grok Bot がリストに従わない可能性があることを確認します。強制適用は設定に依存するものとして扱ってください。モデルアクセス制御を参照してください。
• プライバシーモードが適用されます。 メンバーがチームに所属している間はチームのプライバシーモードが適用され、プライバシーモードを有効にすると、顧客データはトレーニングに使用されません。
• ゼロデータ保持は、Cursor の既存のプロバイダー契約に従います。 モデルプロバイダーはプロンプトや出力を保持せず、Grok Bot による個別の制御も追加されません。プロバイダーは不正利用やセーフティの分類器を実行する場合があり、フラグが付いたデータは調査のために保存されることがあります。

ローカル実行

Botはデスクトップアプリを通じて、メンバー自身のマシン上で操作できます。コマンドの実行、ファイルの読み取り、クラウドコンピューターとローカルマシン間でのファイルの移動が可能です。これはホストされたコンピューターでの作業とは別に管理され、独自のコントロールがあり、ホストされたコンピューター内での作業を管理するAuto Reviewとも異なります。

デフォルトでは、コマンドごとに承認が必要で、承認カードには実行するコマンドが正確に表示されます。メンバーは 設定 > 一般 > エージェント > ローカルコンピューターでの実行 でポリシーを選択します。毎回確認する、常に許可する、または許可しない、のいずれかです。Botがローカルファイルで作業する明確な理由がない限り、許可しないことを推奨します。ローカル実行を完全に無効にすることもでき、チームレベルの上限は設定で適用されます。現時点では、この上限を設定するダッシュボードのコントロールはありません。

ホスティング

Grok Bot は、Cursor がホストするクラウドコンピューターでのみ実行されます。オンプレミスへのデプロイ、自社のセキュリティ境界内へのデプロイ、独自のイメージを使用したデプロイには、現時点では対応していません。また、VPN、トンネル、プライベートリンクを介してコンピューターのトラフィックをお客様のネットワークへルーティングする機能も提供していません。サポートされる構成は、送信先の許可リストと組み合わせた共有静的エグレスです。

プロンプトインジェクション

Web ページ、プラグインの結果、コマンド出力など、Bot が外部から読み取るコンテンツは、Bot を誘導しようとする可能性があります。Grok Bot は多層的な防御を備えています。強制適用がオンの場合、Auto Review は Bot のアクションがメンバーの実際のリクエストに沿っているかを確認します。その下には、モデルの判断に依存しないネットワークポリシー、アクションごとの承認、ユーザーごとの分離などの制御があります。Bot が外部から読み取ったコンテンツは、モデルに提示する際、信頼できないデータとして扱われます。これらの制御は悪意のあるコンテンツによるリスクを低減しますが、完全になくすことはできません。そのため、影響の大きいアクションは承認を必要とする状態にしておく必要があります。

認証

Cursorを提供するAnysphereは、Schellmanが発行するISO/IEC 27001およびISO/IEC 42001の認証を取得しており、Grok Botは現在のISO認証の適用範囲に含まれています。ISO/IEC 27001は、組織全体のセキュリティプログラムである情報セキュリティ管理システムを認証するものです。ISO/IEC 42001は、Cursorが開発・運用するAIをどのように管理するかに関するAI管理システムを認証するものです。証明書とレポートはtrust.cursor.comで確認できます。

推奨設定

セキュリティ要件が厳���いデプロイでは、以下を推奨構成のベースラインとします。

管理者向け：

1. ネットワークポリシーを設定します。 ポリシーのないチームでは、デフォルトですべてが許可されます。
2. Grok Bot を有効にする前に、チーム MCP 許可リストを監査します。 許可されたコネクタは、メンバーが実行するすべての Bot で利用できます。
3. メンバーに Auto Review の強制適用をオンのままにするよう促します。 強制適用は Cursor により有効化されており、現在すべてのユーザーに適用されています。オフにできるのは各メンバー自身の設定のみです。
4. 明示的なローカル実行ポリシーを設定し、Bot によるメンバーのマシン上での操作を許可するかどうかを決定します。
5. 委任が不要な場合は、Cloud Agent の起動を無効にします。
6. メンバーがチーム外で Bot テンプレートを公開する必要がない限り、パブリックテンプレート共有はオフのままにします。
7. 自分の環境で決して許可しない操作についてチームのブロック指示を追加し、日常的で安全な作業には許可指示を設定します。本番環境へのデプロイ、外部メール、支払い、法的条項への同意は代表的なブロック対象です。
8. アイデンティティプロバイダーを通じて、管理対象デバイスからのサインインを制限します。 Grok Bot のサインインには SSO が使用されるため、デバイスを考慮したサインインポリシーが適用されます。これはサインインを制限するものであり、ホストされたコンピューター自体を制限するものではありません。

メンバー向け：

1. 認証情報をチャットに貼り付けないでください。 マスクされたシークレットリクエストが、サポートされている方法です。
2. アカウント、資金、共有リソースに影響する操作では、[常に許可] ではなく [一度だけ許可] を優先します。
3. Bot のブラウザには、タスクに必要なアカウントだけでサインインし、不要になったアカウントからはサインアウトします。ソースシステムが対応している場合は、権限を限定したサービスアカウントを使用してください。
4. 新しい役割では参照専用のタスクと下書きの出力から始め、送信、公開、購入、削除、本番環境への変更は承認が必要な状態に保ちます。
5. インストール済みのプラグインと有効なルーチンを定期的に確認し、そのソースシステムが変更された場合はルーチンを一時停止します。

よくある質問

関連ページ

• ID とアクセスを設定する
• Grok Botを使う
• プランと請求
• プライバシーとデータガバナンス