Grok Bot のセキュリティと承認設計

Bot を分けても、セキュリティ境界にはならない

Grok Bot のコンピューターは Bot ごとではなく、ユーザーごとに1台割り当てられます。役割ごとに Bot を分けても、同じユーザーの Bot 同士では中身が共有されるため、公式も「Bot を分けることをセキュリティ境界として使わないこと」と明記しています。

ユーザーA のクラウドコンピューター

資料作成Bot の画面

情報収集Bot の画面

データ整理Bot の画面

3つの Bot で共有ファイル（/workspace）・ブラウザのログイン・コマンドラインの認証情報・コネクタ

ユーザー間は分離

ユーザーB のクラウドコンピューター

確認・監視Bot の画面

別のコンピューターユーザーA のファイルやログインには届かない

• ユーザー間は強く分離：各ユーザーの作業は専用の Firecracker microVM（独自のカーネル・メモリ・仮想デバイス）で動き、他のユーザーのコンピューターには到達できません。
• 同じユーザーの Bot は共有：ブラウザの Cookie とサインイン状態、ファイル、コマンドラインの認証情報が全 Bot で共有されます。1つの Bot でサインインすると、他の Bot もそのセッションを使えます。
• 画面は分かれるが、境界ではない：Bot ごとに画面は分かれますが、公式は「別々の作業面であって、別々のセキュリティ境界ではない」としています。
• コネクタはアカウント全体で有効：インストールしたコネクタは、特定の Bot だけに限定されません。
• Bot を削除してもファイルは残る：削除で消えるのは Bot のプロフィール・会話・ルーティンで、共有コンピューター上のファイルやブラウザのセッションは残ります。
• 分けたいときは、ユーザーを分ける：別のコンピューターと認証情報が必要な業務には、別の Cursor ユーザーを割り当てるよう公式は案内しています。

Bot は、独自の ID や権限を持たない

• Bot はサインインしているメンバーとして動作し、そのメンバー以上の権限を持つことはありません。操作はすべて、名前のあるメンバーに帰属します。
• コネクタのトークンは Cursor のバックエンドに保管され、Bot には渡されず、コンピューターにも保存されません。
• ログイン・2要素認証・支払いの手順は、Bot が入力せず、メンバーに操作を渡します。パスワードやワンタイムコードを通常のチャットに送らないよう案内されています。

承認と Auto Review の仕組み

承認は「これから行う操作」を止めるもの

• 承認が必要な操作では、会話に操作の内容と入力値が表示されます。デスクトップでは「Allow once（今回だけ許可）」「Always allow（ルールとして保存）」「Deny（拒否）」、iPhone と Android では「Approve once」「Deny」で応答します。
• 承認は、すでに完了した作業を取り消しません。公式は、対象や影響を特定できない操作は承認しないこと、分からなければ平易な説明や下書きを先に出させることを勧めています。
• アカウント・お金・共有リソースに触れる操作では、「Always allow」より「Allow once」を選ぶよう推奨されています。

Auto Review は、承認の手前で働くレビューモデル

• 独立したレビューモデルが、リスクのある操作を実行前に評価し、「続行」「承認を求める」「拒否」を判断します。対象はシェルコマンド、プラグインの呼び出し、コンピューター操作、ルーティンやイベントトリガーの変更、Cloud Agent やサブエージェントの起動です。
• すべての副作用を見るわけではありません。メモリへの書き込みや大半の設定変更は対象外の例として挙げられています。
• 強制（enforcement）は Cursor が全ユーザーで有効にしていますが、オフにできるのは各メンバー自身の設定で、組織単位のロックはありません。
• ルールは「Require Approval（必ず承認）」が常に優先し、「Always Allow（常に許可）」はレビューが他の停止理由を見つけない場合だけ続行します。「社外へのメール送信の前に承認を求める」のような狭いルールが推奨され、「ブラウザ内はすべて許可」のような広いルールは避けるよう案内されています。
• 外部のページやツールの結果に仕込まれた指示（プロンプトインジェクション）への対策は多層ですが、公式は「リスクを減らすが、なくしはしない」としています。

どの操作に、承認の境界を置くか

公式は、次の操作には明示的な境界を置くよう勧めています。右の列は、当社がトップページの「権限・承認設計」で示している3段階に当てはめた設計例です。

当社の設計例は一例です。対象業務・扱う情報・利用環境に応じて個別に設計します。境界は、Bot の説明文（常に守らせるルール）、依頼文（その作業での止めどころ）、Require Approval ルール、Auto Review のチーム指示を組み合わせて表現します。

管理者が使える統制

• Network Controls（Enterprise 限定）：コンピューターが接続できる宛先を制限します。ポリシーのないチームは「すべて許可」が既定です。プラグインを禁止しても、そのサービスの Web サイトはブラウザから使えるため、経路を閉じるにはネットワーク側の制限も必要です。
• Team Rules と Auto Review のチーム指示（Teams・Enterprise）：全メンバーの Bot に効くルールと、許可／禁止の指示です。
• 監査ログと Action Recording（Enterprise 限定）：監査ログは管理・セキュリティ・認証のイベント、Action Recording は Bot の操作（機微な値を除いたシェルコマンドを含む、90日保持、既定はオフ）で、別々の仕組みです。
• ローカル PC での実行：Bot が手元の PC でコマンドを実行する機能は、既定で毎回確認です。公式は、特別な理由がなければ「許可しない」を勧めています。
• アクセスの即時停止：組織管理者はメンバーのコンピューターを停止できます（Enterprise 限定）。あわせて ID プロバイダー側のセッションも失効させるよう案内されています。

プランごとの管理機能の一覧は、法人・Enterprise 導入ガイドの対応表にまとめています。

企業側で決めるべき権限と承認境界

当社の考え方製品の仕組みで守れるのは一部です。残りは、導入する企業が業務ごとに決める必要があります。PoC の前に、次の7点を文書にしておくことをお勧めします。

表は横にスクロールできます