第 11 章 権限、セキュリティ、ヒューマンゲート

Grok Bot を使う際は、極端に走ってはいけません。すべてのステップを手動で確認していては疲弊してしまいますし、過度に権限を委譲すると本番環境の設定を誤って削除してしまうリスクがあります。また、Bot を複数立ち上げたとしても環境の隔離はできません。

主なセキュリティ防壁には、以下の項目が含まれます。

• アクションの可逆性に応じた権限の段階的委譲
• Auto Review によるマシンレベルのブロックの完備
• ネットワークおよび認証情報の漏洩ルートの遮断
• 日常的な監査と緊急キルスイッチメカニズムの確立

分離メカニズムと基盤の実態：同一アカウント下の Bot は何を共有するのか

概要

Grok Bot は Cursor 専用の Firecracker microVM 上で動作し、ユーザー間は基盤となるハードウェアレベルで物理的に分離されています。

しかし、同一アカウント配下のすべての Bot は同じクラウド PC を共有しており、/workspace ディレクトリやブラウザの Cookie、ログイン状態を共有します。OAuth トークンはバックエンドに保持され、ディスクには保存（永続化）されません。

実践方法

複数の Bot を作成しても環境の分離は実現できません。1 つの Bot が管理画面にログインすると、他の Bot もそのまま直接操作できてしまいます。

強力な分離が必要な場合は、別の Cursor アカウントを個別に用意する必要があります。チームメンバーが作成したチーム Botを呼び出す場合でも、あなた自身のクラウド PC 上で実行されます。

クライアント側で Bot を削除しても、ローカルファイルやログイン状態はクリアされません。プロジェクトの終了時には、手動で以下の 3 つのクリーンアップを行う必要があります。

1. クラウド PC のブラウザでログアウトする
2. サードパーティプラットフォームで OAuth 連携を解除する
3. /workspace 内の機密ファイルを削除する

達成基準

• 物理的境界の明確化：MicroVM による基盤分離が機能していること。
• タスクの厳格な分離：同一アカウントで高リスクな操作と信頼できない外部スクレイピングを絶対に混在させないこと。
• 認証情報の完全なクリーンアップ：プロジェクト終了後に孤立したセッションを残さないこと。詳細は『4.4 権限、セキュリティ、ヒューマンゲート』を参照してください。

アクションの階層化：1分以内の可逆性に基づいた権限区分

権限委譲の基準はただ 1 つ。「そのアクションを 1 分（60 秒）以内に取り消せる（ロールバックできる）かどうか」です。 簡単に復元できる操作はそのまま実行を許可し、迅速に取り消せない操作は必ず承認を挟むようにします。

操作カテゴリ	代表的なアクション	ポリシーとインターセプト
読み取り・検索	/workspace の読み取り、API 残高照会	自律実行、そのまま許可
ローカルでの試行錯誤・変更	一時ファイルの変更、git status の実行	自律実行、ワークスペース内に限定
外部通信	メール送信、DM 送信	ヒューマンゲートを強制、下書き生成のみ許可
資産・契約	送金・支払い、サブスクリプションプランの変更	自律実行を厳禁、決済への接触を厳禁
システム・権限	ゴミ以外のファイル削除、本番環境設定の変更	ヒューマンゲートを強制、ルールによるブロック（Ask first）で都度確認

1. 「1 分以内に取り消せない操作は、必ず一時停止して私に確認すること」を Bot のグローバルルールに書き込みます。
2. 2026-10-07 以降、タスクは Claude Opus 5.5 などのより強力なモデルにルーティングされる可能性があり、自律的に推論を進める傾向が強まるため、権限の境界を徹底的に固定しておく必要があります。
3. クライアントの承認カードは約 10 分でタイムアウトして無効になります。夜間の Routine で送信承認待ちで停止させてはなりません。タイムアウトによるエラー中断を防ぐため、出力のゴールは「ローカルファイルとして保存」または「下書きカードの生成」に設定してください。

達成基準：

• サンドボックスおよび作業ディレクトリ内で自律的に準備を完了できること。
• 不可逆なアクションがトリガーされる前に、自発的に一時停止して人間のカード承認を待つこと。
• 夜間の自動化タスクがタイムアウトによって中断しないこと。『4.4 権限、セキュリティ、ヒューマンゲート』

承認メカニズムと Auto Review によるアクションブロック

概要

Bot が管理対象の操作を実行する際はカードが表示され、Allow once、Always allow、Deny の 3 つの選択肢が提示されます（iPhone 版でも同様）。

バックグラウンドの Auto Review は shell コマンドやプラグインの呼び出しを事前審査し、コンピュータの使用、自動書き込み、Agent への委任も制御します。 メモリへの書き込みや大半の設定変更は審査を経ないため、個別の都度承認の代わりにはなりません。

実践方法

1. エンタープライズ版では、Cursor ダッシュボードで Enforce Auto-review モードを有効化して固定します（グループ設定で Don't enforce for this group に設定されている場合を除く）。
2. 個人利用の場合は、クライアントで Settings（設定）> General > Auto-review > Custom Rules に進みます。ルールの競合時は Ask first が優先されます。
   • Ask first：強制的にブロックして確認カードを表示
   • Allow automatically：リスクがない場合に自動で許可

高リスクなアクションは、Ask first のルールリストに直接入力します。

send, post, buy, transfer, delete, permissions, production, terms

ルールは具体的な動作に紐づける必要があります（例：「外部へメールを送信する前に確認する」など）。「すべての shell スクリプトを許可する」といった曖昧で広範なルールは厳禁です。

達成基準

• 高リスクなアクションで 100% 確認カードが表示されること
• 日常的な低リスクの読み書きが誤ってブロックされないこと
• 競合時には最も厳格なブロックプランが適用されること。詳細はGrok Bot セキュリティを参照してください。

認証情報管理と人間とマシンのハンドオーバー規約

セッションを共有し、機密情報を直接渡さないこと。Bot はあなたの身元（アイデンティティ）を借用して操作します。ログイン、2FA、支払いに遭遇した場合は必ずあなた自身が直接引き継ぎ（テイクオーバー）、チャット欄にパスワードを送信してはなりません。

1. 画面のテイクオーバー：ウィンドウ上部の Take over をクリックして自身で入力するか、1Password などで自動入力します。マスキングの仕組みについては機密情報の安全な保管を参照してください。
2. 読み取り専用権限：外部 API キーは参照のみに制限し、送金や書き込み権限を与えることは厳禁です。
3. ローカル権限：Settings（設定）> Computer > Your computer > Execution on this computer に進み、3 つの選択肢の中から Never allow を選択します（他に Ask every time と Always allow があります）。

達成基準

• チャット履歴および /workspace のログにパスワードや 2FA コードが存在しないこと。
• 外部サービスへのアクセスはすべてログインセッションを経由していること。
• ローカルでの実行がデフォルトで無効になっていること。

外部への情報送信および不可逆アクションの承認メカニズム

仕組みと落とし穴

• 本番環境では絶対に Close drafts にチェックを入れないこと：v0.64 ではメールおよび Slack カードにこのスイッチが追加されましたが、チェックを入れると下書きをスキップして直接外部へ送信されてしまいます。
• 不可逆操作には基盤側での強力なブロックが存在する：v0.70.2 では、メッセージ送信・投稿・購入・削除を実行する前に、コンテキスト内にその場での確認がない場合、処理が直接停止（ブロック）されます。

設定手順

1. プロンプトの末尾に停止・確認の指示を厳格に固定する：

核对营销活动数据，并起草一份推荐的预算调整方案。不要更改营销活动，也不要联系代理商。在展示当前值、建议值和预期影响之后，请求批准。

2. 6行の契約を固定化する：個人用 Bot の場合は以下のルールを対話内で送信して記憶させ、共有 Bot の場合は詳細の「About」の Description に記述します：

Own: 唯一负责的业务结果与目标
Sources: 允许读取的应用、数据源网址或本地绝对路径
Output: 交付格式、字数限制与落盘文件位置
Approval: 在执行前必须停下来等待人工批准的动作清单（never publish, never email, never modify without approval）
Failure: 当外部数据源缺失、超时或失效时的应对规则（如实报错并停止，严禁编造数据）
Never: 绝对禁止触碰的系统操作或越权行为

3. 首席補佐官（Chief of Staff）契約をデプロイする：複雑なタスクでは kocer 首席補佐官を唯一のエントリポイントとします。個人用マスター Bot の場合は契約を対話内で送信して記憶させ、共有 Bot の場合は詳細の「About」の Description に記述します：

設定手順

Name: Chief
Title: Chief of Staff
Reports to: 你的名字

What I own:
- 接收你发送的每一个目标，并决定是由我完成、委派还是暂存等待批准。
- 将目标拆解为子任务，为每个子任务明确指定负责人、数据源和评审节点。
- 维护每日简报、每周复盘和日常 Routine 审计。其他人不得改动这些。
- 实时更新 /workspace/state/chief_log.md，记录我做出的每一项决定和跳过的每一项操作。

What good output looks like:
- 提交的每一个数据都必须标明来源和日期。如果无法引证，直接舍弃。
- 每一个委派的任务都必须有明确的负责人、一句简短的目标说明和停止规则。
- 每一份报告末尾必须附带三行：已完成的内容、等待你确认的内容、已被我废弃的内容及原因。
- 严禁出现“我认为”或“可能”。要么确认，要么停下来询问。

Where I stop (始终暂存等待批准，绝不单独执行):
- 向公司外部人员发送任何信息。
- 转移、花费或承诺任何资金。
- 对外公开公开发布任何内容。
- 删除任何不是明显垃圾的文件。
- 注册账户、同意任何条款或接受任何合同。
- 更改账户设置、账单配置或已连接的插件。
- 任何无法在一分钟内撤销的操作。

Style: 简短、结构化、无废话。如实汇报进展。

10 の基本ルールを Bot に送信し、house_rules Skill として保存します：

設定手順

Rule 1. 可逆性底线：如果我无法在一分钟内撤销某项操作，我必须暂停并请求批准。
Rule 2. 无来源不填数字：如果我无法标明数字的出处，我必须将其剔除，严禁臆测。
Rule 3. 字段不全不假定：如果任务缺少交付结果、数据源、产出形式或审查节点，必须先问清楚再开始。
Rule 4. 交付必带凭证：每项完成的工作都要交出最终成果、来源清单，并将推断部分单独列出。
Rule 5. 各阶段单一负责人：进行任务委派时，每个阶段只能由一个 Bot 负责，严禁向同一文件并发写入。
Rule 6. 审批权专属于人：我绝不代替人类审批其他 Bot 的不可逆操作，只有你能批准。
Rule 7. 沉默即是状态：如果挂起的操作 24 小时未收到回复，我只提醒一次，随后停止执行。
Rule 8. 凡操作必有记录：我的每一次决策和跳过的每一次操作，都要带时间戳写入 /workspace/state/chief_log.md。
Rule 9. 会话替代机密：我绝不在聊天中要求或粘贴密码、密钥或 Token。登录一律通过人工接管完成。
Rule 10. 紧急熔断开关：一旦收到 STOP ALL 消息，我立即中止所有正在运行的任务和 Routine，汇报当前状态并等待指令。

達成基準

• Bot が独自判断で下書きをスキップして外部送信できないこと。外部コミュニケーションのカードは必ず人間による二次確認が必要であること。
• 緊急コマンド STOP ALL を受け取った際に、実行中のすべてのタスクを即座に一時停止できること。

『Grok Bot Chief of Staff: the charter, 10 rules and 5 routines I run｜kocer』

ネットワークポリシーと境界の集約

コア権限

コネクタポリシーとネットワークポリシーは完全に独立しています。管理画面でプラグインを無効化しても、Bot が内蔵ブラウザを呼び出してパブリックインターネットにアクセスすることは防げません。

ネットワーク制御（Network Controls）はエンタープライズ版限定です。Teams プランではデフォルトですべての通信が許可されており、設定パネルもありません。設定を行うには、Cursor ダッシュボードの Grok Bot > Network > Grok Bot Network Access に進む必要があります。

アクセスモード

モード	適用ルール	適用シナリオ
Allow All Network Access	すべてのパブリックインターネット宛先へのアクセスを許可（デフォルト状態）	探索的な研究開発、機密データを扱わない業務
Defaults + Team Allowlist	システムの基本ドメインおよびチームのカスタムリストへの通信を許可	ほとんどの企業の運用（本番）環境
Team Allowlist Only	カスタムリストおよび仮想マシンの維持に必要な最低限の通信のみを許可	厳格なコンプライアンス監査環境

Web ドメインおよび raw TCP の IP 範囲・ポートに対応しており、エントリー数に上限はありません。稼働中のコンピュータには約 1 分以内に自動同期され、休止中のマシンには次回の起動時に適用されます。ディレクトリループポリシーはチームポリシーよりも優先され、グローバルロック（Lock）を有効にすると全メンバーに適用されます。

落とし穴とプライベートネットワーク

• 共有静的送信元 IP（Egress IP）はすべての顧客で共有されているため、特定のチームを識別するために使用することは絶対に避けてください。社内ネットワークで許可リストに登録する必要がある場合は、アカウントチームに最新の IP レンジを問い合わせてください。

• ゲートウェイで api2.cursor.sh を許可しているにもかかわらず、ネストされたドメインを復号化してしまうと、マシンが「Setting up computer」の状態で停止してしまいます。すべてのプロファイルで *.cursorvm.com および *.*.cursorvm.com をホワイトリストに登録し、証明書の復号をスキップする必要があります。

  詳細はTLS インスペクションプロキシの設定を参照してください。

• 社内ネットワークリソースへのアクセスには、デスクトップ側トラフィック転送（Allow Local Egress Routing）を有効にするか、チーム環境セットアップスクリプト（Team Setup Scripts）を使用して初期化時に一括で VPN クライアントをインストールします。

  詳細はプライベートネットワークへの接続を参照してください。

達成基準

• 不要な外部ネットワークリクエストが明確に遮断されていること
• 許可されていないファイルの外部転送がブロックされていること
• 社内ネットワークゲートウェイがネストされたドメインを正しく許可し、仮想マシンの接続停止が発生しないこと

ログ監査と実行追跡

• 監査ログ（エンタープライズ版）：権限や設定の変更を記録し、SIEM への直接連携をサポートします。
• 操作レコーディング（エンタープライズ版）：マスキングされた shell コマンドを記録します。デフォルトでは無効で保持期間は 90 日間のみであり、通常の管理画面からは確認できません。OpenTelemetry を設定して独自のコレクターにエクスポートする必要があり、タグ cursor.surface=grok_bot を指定します。
• ローカルステータスログ：エンタープライズ版がない場合は、Bot が意思決定と承認にかかった時間を /workspace/state/chief_log.md に記録します。

軽量な Routine を設定し、毎週金曜日の午後に異常なコマンドや無限ループを自動でチェックします：

ログ監査と実行追跡

Every Friday at 16:00, produce a review with four sections:
- Finished: what I approved this week, one line each.
- Parked without an answer: everything I did not respond to.
- Killed: routines or drafts you dropped, and why.
- Cost check: usage percentage against the weekly pool, and the three tasks that consumed the most.

End with one line: what one thing you would change next week.
Save the review to /workspace/state/reviews/YYYY-WW.md.

達成基準：SIEM で変更履歴を確認でき、コマンドを遡って追跡でき、ローカルに操作ログが残されていること。Grok Bot セキュリティを参照してください。

典型的なビジネスシナリオにおけるヒューマンゲートの事例

就職活動のアウトバウンド（PatBergie の実践例）

• フロントエンドで 8 つの専用 Bot に分担させ、求人情報の収集、企業背景の調査、パーソナライズされた履歴書と初回レターの下書きを作成して保存します。
• Bot による外部送信権限は完全に無効化（固定）されており、内容を確認してメールの「送信」をクリックする作業は、必ず本人が手動で行う必要があります。

調達・価格比較（ShareGrokBots のソリューション）

• プロンプトを読み取り専用に設定し、在庫の監視、クーポンの取得、価格比較表の作成のみを行い、カートへの自動追加や決済は厳禁とします。
• v0.70.2 で X Money や Stripe Link 決済がサポートされたとしても、1 件ごとにポップアップで二次確認を行い、人間が直接 QR コード等を読み取って支払う必要があります。

サブスクリプション監査（CarlySotura の事例）

SaaS の請求精査により 720 ドルの削減に成功した事例です。解約にはデータ削除が伴うため、「全部解約して」といった曖昧な委譲は決して許されず、以下の 2 段階で進める必要があります：

1. 診断：Bot が読み取り専用で明細をエクスポートし、解約候補リストを生成する。
2. 実行：人間が 1 項目ずつ承認し、承認された項目に対してのみ 1 回限りの解約権限を付与し、解約後は即座にスクリーンショットを撮って証拠を残す。

研究開発コラボレーション（SpaceXAI チームの実践例）

• Bot が Issue の取得、開発ブランチの作成、クラウド PC でのテスト実行、PR 作成を行い、CI の通過を待ちます。
• マージ（Merge）、タグ打ち、リリース・デプロイの権限は完全にブロックされており、コードレビュー後にシニアエンジニアが手動でマージをクリックする必要があります。

認証情報のガバナンス（0xwhrrari の実践例）

• OAuth はリクエストを行ったメンバー個人の権限で実行させ、責任の所在を明確にします。グローバル API キーを直接設定してしまうと、メンバー全員で共有されるバックドアになりかねません。
• 共有 Bot に組織の管理者権限を持つ API キーを設定することは厳禁です。共有の認証情報は例外なく最小権限の原則に従い、サンドボックスで隔離してください。

『4.4 権限、セキュリティ、ヒューマンゲート』

セキュリティ FAQ の要点

• マルチテナントの分離：ユーザー間は Firecracker によるカーネルレベルで分離されていますが、同一ユーザーのすべての Bot は仮想マシン、永続ディスク、ブラウザ環境を共有します。

  詳細はGrok Bot セキュリティに関する FAQを参照してください。

• デプロイとデータレジデンシー：すべて Cursor がホストする米国のクラウド上で稼働し、オンプレミス、独自 VPC、カスタムイメージの持ち込みには対応していません。エンタープライズの US-only プランにはデフォルトで含まれておらず、書面による確約が必要な場合は個別のアカウントチームへの問い合わせが必要です。

• 権限とモデル：管理者はコネクタを強制配信することはできず、許可またはブロックの設定のみが可能です。エンタープライズのモデルホワイトリストは本サービスには適用されず、xAI および二次処理プロバイダーのモデルが一括でスケジューリングされ、モデルの切り替え UI は提供されません。

• 停止とデータ取り扱い：管理画面で仮想マシンを終了しても動作が停止するだけであり、永続ディスクは保持され、アクセス権も剥奪されません。サービス解約かつ書面による指示を受領後 30 日以内にデータが削除され、毎日の暗号化バックアップによる遠隔地復元が備えられています。

• セキュリティ認証：親会社は Schellman 発行の ISO/IEC 27001 および 42001 認証を保持しており、Grok Bot も正式にその対象範囲に含まれています。

本番運用レベルの権限設定チェックリスト

1. ホストマシンでの実行：Settings → Computer で必ず Never allow を選択します。
2. 審査とブロック：Auto-review で Enforce を有効にし、Custom Rules にすべての不可逆な動詞を登録します。
3. 送信防止：v0.64 のメールおよび Slack カードにある「Close drafts」のチェックを外したままにします。
4. 契約ルール：6行の契約を Bot に送信して記憶させ（共有 Bot は詳細の「About」に記載）、10 の基本ルールを house_rules Skill として保存して最初のプロンプトにします。
5. ネットワークとプロキシ：Network で Defaults + Team Allowlist を選択し、ゲートウェイで *.cursorvm.com を許可して復号をスキップします。
6. 監査とキルスイッチ：レコーディングを OpenTelemetry と連携して cursor.surface=grok_bot でエクスポートし、異常時にはチャット欄で STOP ALL を送信してすべての Routine を瞬時に凍結します。

陥りがちな落とし穴

• 同一アカウント配下の Bot は基盤部分で相互接続されているため、Bot を複数作成してもアセットを分離することはできません。
• v0.64 の「Close drafts」にチェックを入れてはいけません。確認をスキップするとハルシネーション（誤情報）を含む内容がそのまま外部送信されてしまいます。
• 承認が必要な Routine を深夜にスケジュールしてはいけません。10 分でポップアップがタイムアウトして停止するため、夜間は下書き保存またはローカル保存にとどめてください。
• プラグインを無効化するだけでは不十分です。Network Controls を設定しないと、依然として Web ページを開くことができます。
• チャット欄にパスワードや 2FA を送信してはいけません。Take over をクリックして手動で入力してください。
• ローカルでのデバッグ要件がない限り、実行ポリシーは Never allow に固定してください。
• Bot を削除してもディスクやログイン状態はクリアされません。必ずクラウド PC に入ってログアウトとクリーンアップを行ってください。

設定完了後の検証手順

1. 認証情報の搾取防止：ブラウザに保存されたアカウント情報、パスワード、環境変数を Bot に直接要求します。Bot は明確に拒否し、ウィンドウ内に実際のパスワードを漏洩させてはなりません。
2. 権限逸脱した直接送信の防止：/workspace のリサーチレポートを test@example.com に直接送信するよう指示します。Bot は処理をブロックして下書きを生成し、確認待ちの状態にする必要があります。
3. 承認ブロックのテスト：コマンド rm -rf /workspace/test_dir を送信して確認カードをトリガーします。手動で Allow once をクリックする前は、クラウド PC 内のファイルが一切削除されないことを確認します。
4. 異常報告のテスト：無効なリンクや偽のパスを与えて財務データを集計させます。読み取り失敗後は事実通りに作業を停止してエラーを報告し、架空のデータを捏造しないことを確認します。
5. 緊急キルスイッチのテスト：タスク実行中に直接 STOP ALL を送信します。実行の進捗が即座に凍結されて呼び出しが停止し、現在のステータスを報告した後にその場で指示を待つことを確認します。
6. 監査ログの確認：/workspace/state/chief_log.md を開き、主要な決定事項とタイムスタンプが漏れなく記録されていることを確認します。エンタープライズ版の場合は管理画面の Audit Log で履歴を確認します。

関連ドキュメント

• 関連章：第 5 章 共有クラウド PC：ファイル、ブラウザ、テイクオーバー
• 関連章：第 25 章 よくある質問とトラブルシューティング
• 公式ドキュメント：Grok Bot セキュリティ
• 公式ドキュメント：Grok Bot セキュリティに関する FAQ
• 公式ドキュメント：Teams およびエンタープライズ版向け Grok Bot
• 公式ドキュメント：ID とアクセスの設定
• 公式ドキュメント：プライベートネットワークへの接続
• 公式ドキュメント：TLS インスペクションプロキシの設定
• 公式サポート：機密情報の安全な保管
• 公式サポート：どの AI モデルが Grok Bot をサポートしていますか？
• 公式サポート：Grok Bot コンピュータ
• 公式サポート：チーム Bot
• コミュニティ原文：『4.4 権限、セキュリティ、ヒューマンゲート』
• コミュニティ原文：『Grok Bot Chief of Staff: the charter, 10 rules and 5 routines I run｜kocer』