AIエージェントの権限管理は「許可ボタン」から「文脈判断」へ：Cursor Auto-review

何が発表されたか

2026年6月11日、Cursorは研究ブログで「Auto-review」を発表した。これは、コードエージェントがローカル環境でツール実行やファイル操作を行う前に、その行為がユーザー意図やリスクに照らして妥当かを判定する仕組みだ。Cursor自身は、エージェントの自律性を「オン／オフのスイッチ」ではなく「調整可能なダイヤル」として扱う、と説明している。(cursor.com)

背景にある問題は分かりやすい。コーディングエージェントは、テスト実行、ファイル探索、修正、ビルド、外部ツール呼び出しまで担うようになった。一方でローカルエージェントは、ファイル、認証情報、環境変数、MCPツール、場合によっては本番系へのアクセスに近い場所で動く。すべての操作を人間に確認させれば安全に見えるが、確認が多すぎるとユーザーは読まなくなる。Cursorはこの「承認疲れ」自体を安全上の問題として位置づけている。(cursor.com)

新しい点：許可リストではなく、文脈を見る分類器

Auto-reviewの中核は、親エージェントの実行経路に挟まる「分類器エージェント」だ。単にコマンド文字列だけを見るのではなく、ユーザーの依頼、直前の作業、操作が失敗した場合の影響を合わせて判断する。Cursorの例では、同じ python script.py でも、中身によって安全にも危険にもなりうるため、分類器は必要に応じて ReadFile、Grep、Glob、ListDir などでワークスペースを調べられる。(cursor.com)

ここが面白い。Auto-reviewは「AIを止めるためのAI」ではなく、「AIに止まるべき理由を説明するAI」として設計されている。分類器がブロックした場合、それは直ちにユーザーへの確認ダイアログになるとは限らない。まず親エージェントに説明が返され、親エージェントはより狭い操作、別のツール、より安全な手順を選び直せる。つまり、人間を毎回呼び出すのではなく、エージェント自身にリスクを回避させるフィードバックループが作られている。(cursor.com)

なぜ重要か

これは、コーディングエージェントの実用化における焦点が「モデルが賢いか」から「どこまで任せられるか」へ移っていることを示している。エージェントが単にコードを提案する段階なら、失敗は差分レビューで吸収できた。しかし、ローカルでコマンドを実行し、ファイルを読み書きし、外部ツールを呼び、複数ステップの作業を継続する段階では、問題は能力ではなく権限設計になる。

Cursorは以前から、ローカルエージェント向けにサンドボックスを整備してきた。2月のブログでは、macOS、Linux、Windows向けにサンドボックス化を進め、サンドボックス内では自由に動かし、外に出るときだけ承認を求める設計を説明していた。今回のAuto-reviewは、その次の層に見える。サンドボックスが「実行境界」を作るなら、Auto-reviewは「境界を越えようとしている理由」を判断する。(cursor.com)

評価の仕方も実務寄りになっている

Cursorによれば、最初の評価データは約12時間分の社内開発セッションから作られ、重複を削ったうえで6,122件のラベル付き行動に整理された。さらに、秘密情報の読み取り、本番データへの接触、信頼できない指示への追従、大きな副作用を持つ操作など、通常利用では頻出しにくい危険ケースを合成データで補っている。(cursor.com)

この設計は、エージェント安全性の評価が「ベンチマーク問題を解けるか」だけでは足りないことを示している。実務上は、危険な操作はそもそも頻度が低い。しかし低頻度だからこそ、通常ログだけで学習・評価すると見落とす。そこで、日常的な作業ログと、意図的に作ったレッドチーム的なケースを組み合わせる必要がある。

またCursorは、同じケースで許可とブロックが揺れる「flapping」も見ている。これは地味だが重要だ。安全判定がランダムに揺れると、ユーザーもエージェントも学習できない。権限管理は正しさだけでなく、一貫性が必要になる。

数字は有望だが、読み方には注意がいる

Cursorの報告では、分類器が実際に走るのは文脈判断が必要な一部の操作であり、そのうち現在ブロックされるのは約4%。ただしブロックが直ちにユーザー割り込みになるわけではなく、Auto-reviewモード全体では、少なくとも一度ユーザー割り込みが発生するチャットは約7%だという。Cursorは、以前一部の企業顧客で約40%の操作がブロックされていた例と比較している。(cursor.com)

ただし、これはCursor自身の初期データであり、独立検証された安全率ではない。特に「危険操作をどれだけ見逃したか」は、公開ブログだけでは十分に分からない。割り込み率が低いことはユーザー体験には良いが、安全性の証明ではない。今後は、ブロック率、見逃し率、誤ブロック率、企業ポリシー別の挙動、MCPツール経由のリスクなどが、より透明に評価される必要がある。

SDKへの広がり

Auto-reviewはデスクトップアプリだけの話に閉じていない。Cursorの変更履歴では、ローカルSDKエージェントでも local.autoReview を設定することでツール呼び出しをAuto-reviewに通せるようになったと説明されている。また permissions.json に自然言語で許可寄り・ブロック寄りの指示を書ける。これは、企業や開発チームが「削除操作は必ず止める」「ビルド成果物の読み取りは許可する」といった運用ルールを、コードではなくポリシー記述として渡す方向を示している。(cursor.com)

今後の見通し

Auto-reviewの意義は、万能な安全装置ができたことではない。むしろ逆で、エージェントの安全性が単一の承認ボタンや単一のサンドボックスでは解けないことを明確にした点にある。

これからの開発環境では、モデル、サンドボックス、権限ポリシー、実行ログ、分類器、ユーザー確認が重なり合う。エージェントは自由に動くほど役に立つが、自由に動くほど危険にもなる。その緊張関係を、毎回人間に丸投げするのではなく、文脈に応じて機械的に調整する。Auto-reviewは、その実装例として注目に値する。

出典：Cursor公式ブログ「Governing agent autonomy with Auto-review」およびCursor公式Changelog。(cursor.com)