Cloudflare API MCPが選択可能なOAuth scopesへ移行、エージェントの権限をタスクに必要な範囲まで縮小可能に

Cloudflareは8月22日、WranglerとCloudflare API MCP ServerのOAuthフローを更新し、要求する権限の一部をoptional scopesとして指定した。ユーザーは同意画面で権限エディターを開き、現在の作業に必要な読み取り・書き込み範囲だけを残せる。required scopesは引き続き選択された状態に固定される。エージェントが後から、拒否済みのscopeを必要とするコマンドを実行しようとした場合、ユーザーは再認可を行い、その権限を追加しなければならない。

これは、エージェント基盤における実質的なセキュリティ変更だ。CloudflareのMCP Serverは、Workers、KV、R2、D1、Pages、DNS、ファイアウォール、ロードバランシング、AI Gateway、Vectorizeなどの製品にアクセスできる。公式サーバーは約2,500個のAPI endpointの完全なschemaをモデルのコンテキストへ詰め込むのではなく、Code Modeを通じて`docs`、`search`、`execute`という3つの主要ツールを提供する。エージェントはまずサーバー側の仕様を検索し、次に実際のAPIを呼び出すコードを生成する。Cloudflareの推計では、これによりツール記述を約244K tokenから約1.1K tokenまで圧縮できるが、認証情報の権限が自然に縮小されるわけではない。簡素な`execute`インターフェースであっても、その背後では多数の操作が可能な場合がある。そのため、OAuthレイヤーでタスクに応じてscopeを絞り込むことは、prompt injection、モデルの誤判断、乗っ取られたセッションによる被害範囲を直接制限することにつながる。

新しいフローは、操作ごとの承認ではなく、ツールレイヤーのポリシーと同じものでもない。ユーザーが書き込みscopeを付与すると、そのtokenは有効期間中、対応する操作を引き続き実行できる。人による確認を必須にするかどうかは、MCPクライアント、エージェントフレームワーク、組織のポリシーに依存する。また、scopeを拒否しても、モデルのコンテキストから権限のないツールが自動的に削除されるとは限らない。エンジニアは引き続き、認可エラーと再ログインのフローを処理する必要がある。

デプロイチームは、Workersの状態を読み取るだけで、DNSやアカウント管理の書き込み権限は同時に付与しない、といった一般的な作業向けの最小権限テンプレートを用意すべきだ。今後の注目点は、Cloudflareが既存tokenの移行方法、scopeと各endpointの完全な対応表を公開するかどうか、またクライアントが実際に認可されたscopesに応じてツールを動的に非表示にし、無効な呼び出しや権限の混乱を減らせるようになるかどうかだ。