Cloudflare、Workersへのアクセスを単一の大きな権限リストではなくロールとスコープに分割

より多くのチームや自律型コーディングエージェントがCloudflareのDeveloper Platformへ直接デプロイするようになるにつれ、既存の権限モデルは厄介な選択を迫っていた。すなわち、エージェントがアカウント内のすべてのWorker、データベース、バケットに触れられる広範なアカウント全体のロールを付与するか、あらゆるケースをカバーできるだけの個別権限を手作業で構築するかである。後者は、リソースとアクションの数が増えるにつれて管理不能になる。

Cloudflareの解決策は、アクセスを単一の平坦なリストとして扱うのをやめ、代わりに2つの独立した次元を定義することだった。4つのロール、すなわちMetadata Read-Only、Content Read-Only、Editor、Adminは、コードを見ずにログやメトリクスを閲覧することから、編集せずにコードを読むこと、削除せずに編集すること、そして完全な制御まで、能力レベルを表す。これとは別に、各ロールは3つのスコープのいずれかで適用できる。Developer Platform上のすべてのリソース、1つの製品のすべてのリソース（すべてのWorkers）、または単一の名前付きリソース（特定の1つのWorker）である。

2つの軸は独立して組み合わさる。CI/CDパイプラインには、デプロイするまさにその1つのWorkerにスコープを限定したEditorロールを付与できるため、トークンが漏洩してもそのWorkerを更新できるだけで、削除したり他のアプリケーションに触れたりすることはできない。デバッグ用エージェントには、1つのWorkerにスコープを限定したMetadata Read-Onlyを付与できるため、ソースコードを一切読むことなくログやトレースを検査できる。Cloudflareは、製品ごとに新しい権限を発明するのではなく、この同じ「ロール×スコープ」構造を、後からD1データベースやR2バケットなど他のDeveloper Platformリソースにも拡張できるよう設計した。

「何ができるか」（ロール）と「どこでできるか」（スコープ）を2つの独立した軸として分離した

4つのロールと3つのスコープを組み合わせることで、リソースごとの一回限りの権限が組み合わせ爆発を起こす代わりに、小さく固定された語彙から12の正確なアクセスレベルが生まれる。

単一のリソース（1つのWorker）にスコープを限定することで、侵害されたり設定を誤ったりしたエージェントのトークンの影響範囲が封じ込められる。すなわち、アカウント内の他のリソースを見ることも触れることもできない。

同じロール／スコープ構造は、毎回モデルを再設計することなく、他の製品（D1、R2、KV）にも拡張できるよう構築された。

Durable Objectsは独自の権限システムを必要とせず、親Workerのロールからアクセスを継承するため、モデルがさらに細分化されるのを防いでいる。

エージェントの増加に伴ってアクセス要件が増大するときは、個別の権限をさらに追加するのではなく、アクセス制御を能力とスコープという2つの直交する軸に分割し、掛け算ではなく組み合わせで対応すべきである。

Cloudflareはさらに、どの権限が不足しているかを説明するドキュメントへ直接リンクする、文脈付きの403エラーレスポンスを追加した。これにより、権限の壁に突き当たったエージェントや開発者は、一般的な「Forbidden」レスポンスで行き詰まることなく自己修正できる。同社は、この同じロールとスコープのモデルを次にD1データベース、R2バケット、KV名前空間へ拡張する計画だと述べている。