Cloudflareが提案するAgent Access Modelの権限設計

AIエージェントに何を任せるかを検討するとき、モデルの判断精度が最初の論点になることがあります。

もっと賢いモデルを選べば、もっと安心して任せられるはずだ、という発想です。

しかし判断精度をどれだけ上げても、そのエージェントが「本当は触ってはいけないデータに触れた」「承認されていない書き込みを実行した」「一度与えた権限を使い続けている」ことを防げるとは限りません。

エージェントに実際の業務権限を渡すインフラの側が、こうした問いにどう答えているかは、あまり知られていません。

米国のインターネットインフラ企業Cloudflareは、この問いに正面から答える発表を続けています。

2026年8月3日から7日にかけて、同社は「Agents Week」として、AIエージェント向けの機能群を1日ごとにテーマを変えて連日発表しました。

私たちが注目したのは、その中でも権限と信頼の設計に関わる二つの発表です。

8月5日公開の「Agent Access Model」と、同じく8月5日公開の「WriteGuard」です。

Agents Weekの文脈

Agents Weekでは多数の発表がありましたが、本稿に関係が深いのは次の5件です。

Cloudflareの週間まとめ記事「Everything we launched during Agents Week」(著者Shelley Jones、Ann Ming Samborski、Kathy Liao、2026年8月10日公開)によれば、それぞれ次の内容です。

8月4日には、AIエージェントが「エージェント経済の参加者として取引を行う」ためのプログラム可能な決済機能「Cloudflare Wallets」と、従来のソフトウェア開発ライフサイクル（SDLC）に代わる「Agent Development Lifecycle（ADLC）」という開発プロセスの再構成、そしてCloudflare Agentsプラットフォーム上でエージェントの実行をトレース・リプレイし、人間による承認を組み込める可観測性機能が発表されました。

8月5日には、エージェントによるリソースアクセスの参照アーキテクチャ「Agent Access Model」と、MCPサーバーへの書き込みリクエストを制御する「WriteGuard」が発表されています。

本稿では、このうち権限・信頼設計に直接関わるAgent Access ModelとWriteGuardの2本を中心に扱います。

決済機能のWallets、開発プロセスのADLC、可観測性機能については、Agents Week全体の文脈を示す事実として触れるにとどめ、実装の詳細な検証は対象外とします。

なお、この二つは性質が異なります。

Agent Access Modelは実装済みの単一製品ではなく、Cloudflareが提案した参照アーキテクチャ（設計モデル）です。

一方WriteGuardは、Cloudflareが社内で運用したうえで、顧客向けにプライベートベータとして提供を始めた実装です。

この違いは、以降の各節でも区別して扱います。

Agent Access Model——「実行そのものを信頼しない」という参照アーキテクチャ

Agent Access Model（以下AAM）は、CloudflareのMatt Silverlock氏による2026年8月5日公開の記事「The Agent Access Model」で提案されている枠組みです。

記事自身が「This paper proposes an access model for agents（本稿はエージェント向けのアクセスモデルを提案する）」と述べ、続けて「a reference architecture, not a wire-level specification（これは参照アーキテクチャであり、通信レベルの仕様書ではない）」と明記しています。

つまりAAMは、Cloudflareが自社製品として出荷した機能ではなく、業界に向けた設計提案です。

Cloudflareの説明によれば、AAMの中核にあるのは「Do not trust the run. Authorize every action against the task and its accumulated state.（実行そのものを信頼するな。すべての行動を、そのタスクとそこまでに蓄積された状態に照らして認可せよ）」という原則です。

Cloudflareはこれを、GoogleのBeyondCorpが体現してきたZero Trustの考え方——「ネットワークの内側にいるからといって信頼しない」——を、人間のユーザーからAIエージェントのタスク実行へ広げる提案として位置づけています。

記事は「Google’s BeyondCorp assumed a specific principal: a human at a device, acting at human speed（GoogleのBeyondCorpは特定の主体、すなわち端末の前にいる人間が人間の速度で行動することを前提としていた）」と述べ、AAMをその前提を問い直す試みとして説明しています。

AAMは、5つの原則と、それを実装する参照アーキテクチャ（4つの能動的制御＋2つの支援システム、計6要素）で構成されています。

5つの原則は次の通りです。

1. 認証情報は短命で、タスクへ拘束する
2. 強制はプロンプトではなくハーネスとネットワークに置く
3. 人による監督は例外的な場面に限る
4. 権限の見直しは実行の証拠に基づく
5. 権限状態は一方向にしか動かない

このうち原則2についてCloudflareは「A harness earns the name only if it enforces. Its default is deny（ハーネスがその名に値するのは強制する場合のみであり、既定は拒否である）」と述べており、指示文に「これ以上はしないでください」と書くだけでは境界にならないという立場を明確にしています。

4つの能動的制御は次の通りです。

まずAgent Identity Brokerは、タスクが割り当てられるたびに、そのエージェント・依頼者・タスクの組み合わせに限定された短命のトークンを発行します。

これはエージェントの「本人性」を、恒常的なAPIキーではなくタスク単位で確認する仕組みです。

Task-Scoped Access Engineは、タスクが承認された時点で、そのエージェントが行える操作の上限を固定します。

これがエージェントの「職務範囲」にあたります。

Mediation Layerは、ツール呼び出しと外向きの通信という二つの境界で強制を行い、既定は拒否です。

Trust Ratchetは、私たちがもっとも興味深いと感じた部分です。

「保護対象」に分類される事象が発生すると、ポリシーで定めた、より狭い権限状態への移行が始まります。

保護対象のレスポンスは、各制御点が新しい権限状態を受け入れるまでモデルに渡されません。

Trust Ratchet によって外された権限が戻るのは、新しく認可されたタスクの中だけです。

Cloudflareが示す例では、次の順序が説明されています。

決済処理業者から返ってきたレポートを、ハーネスが「保護対象」に分類すると、ハーネスはその内容をいったんモデルコンテキストの外で保持します。

その間にTrust RatchetがBaselineからRestrictedへの移行を各制御点へ反映し、決済処理業者向けの操作とサポート連携の権限を外して、二つの台帳の読み取りと、あらかじめ指定された財務部門のメッセージチャンネルへの定型出力だけを残します。

反映が完了してから、レポートがモデルへ渡されます。

その後にプロンプト経由でサポート操作を試みても、ハーネス側とネットワーク側の双方が独立に拒否したと記述されています。

2つの支援システムは次の通りです。

Agent Activity Logは、Identity Broker・Access Engine・ハーネス・Trust Ratchetの状態ストア・ネットワーク強制点が捉えた活動を、**追記専用（append-only）**かつ検索可能な形式で記録する仕組みです。

これがエージェントの「操作記録」にあたります。

ただし記事は「If tamper evidence is required, the storage system must provide it（改ざんの証拠が必要な場合は、保存先のシステムがそれを提供しなければならない）」とも述べており、追記専用という性質そのものが自動的に改ざん耐性を保証するわけではありません。

Grant Review Loopは、実行の記録をもとに、権限が広すぎたか狭すぎたかを見直し、将来のタスクテンプレートの変更候補を提示する仕組みです。

ここで承認された変更は、実行中のタスクを広げるのではなく、将来のタスクにのみ適用されます。

Cloudflareのこの記事で私たちが評価したいのは、機能の説明だけでなく、提案の現在の適用範囲を自ら明記している点です。

複数のユーザーが共有するエージェントが、あるユーザーの情報をもとに別のユーザーへ応答してよいかという「Multiplayer Access Control」の問題について、同社は「We are not comfortable saying that multiplayer access control can be built end to end today（この問題を今日、端から端まで解決できるとは言い切れない）」と述べ、続けて「AAM does not claim to solve this problem. Its current boundary is a task execution graph governed by one effective authority fixed before dispatch（AAMはこの問題を解決すると主張していない。現在の適用範囲は、実行開始前に固定された単一の実効的権限主体によって統治されるタスク実行グラフに限られる）」としています。

これは製品の欠陥告白ではなく、提案の適用範囲を先に線引きしている記述として読むべきです。

WriteGuard——MCPサーバー向けのプライベートベータ

WriteGuardは、Cloudflareのエンジニアリングチーム（著者Scott Roe-Meschke氏、Kenny Johnson氏）による2026年8月5日公開の記事「WriteGuard: fine-grained controls for MCP Servers」で説明されている、MCPサーバー向けの機能です。

記事は「We are now bringing those controls to Cloudflare MCP server portals through a private beta（これらの制御を、プライベートベータを通じてCloudflareのMCPサーバーポータルへ導入している）」と述べており、2026年8月時点でプライベートベータの段階です。

Cloudflareの説明では、WriteGuardは「a shared policy, attribution, and auditing layer（共有のポリシー・属性付与・監査のレイヤー）」です。

ここでの「属性付与（attribution）」は、ある操作を行ったのが人間本人か、その人の代理として動くエージェントのセッションかを区別して記録することを指します。

各ツールは、リスク階層（risk tier）・有効/無効（enabled/disabled）の設定・ラベリング設定という3つの設定要素を持ちます。

記事は「Risk tiers determine whether the action is logged and whether the tool call is permitted（リスク階層は、その行動が記録されるか、ツール呼び出しが許可されるかを左右する）」としています。

公開されているGitLabの例ではリスク階層と有効/無効設定の両方が使われているため、この例をもって「各階層と結果が1対1で対応する」と一般化して読むべきではありません。

リスクレベル	Cloudflareが挙げる例	記事で確認できる扱い
Read Only	検索、マージリクエスト閲覧	GitLab例では変更せずそのまま許可
Minimal Impact	リアクション追加、既読化	例示のみ。固定の許可ルールまでは記事に明記なし
Contained Write	コメント投稿、マージリクエスト作成	GitLab例では帰属情報を付加し、監査イベントを記録して実行
Critical	マージリクエストのマージ、本番デプロイ	GitLab例ではツールを無効化に設定し、実行前にブロック

Cloudflareが挙げるGitLab向けの具体例では、マージリクエストの取得（Read Only）はそのまま通過し、コメント投稿（Contained Write）はエージェントの帰属情報を付けたうえで実行され非同期で監査イベントが記録され、マージリクエストのマージ（Critical）はハンドラーが実行される前にブロックされ、その試行が記録されます。

記事の導入部では、過度に広い権限を持つクリーンアップ用エージェントが数時間で数千件のチケットを閉じてしまうという架空のシナリオ（「Let’s imagine the Case of the Endlessly Closing Tickets」として提示）が、この仕組みが必要とされる背景として説明されています。

データベースのテーブル削除も、一般に想定されるより深刻なケースとして挙げられているもので、実際にWriteGuardが防いだ事故件数として書かれているわけではありません。

Cloudflareは、社内のMCPポータルが27のMCPサーバーへ接続しており、WriteGuardをそれらのサーバーを横断する共通の制御・監査レイヤーとして運用していると説明しています。

外部提供前に、まず自社の運用で試したという順序自体が、この種の統制機能に対するCloudflareの姿勢を示していると私たちは見ています。

ただし、WriteGuardは完成した一般提供製品ではなく、プライベートベータです。

記事自身も、リスク分類を顧客のツールへどう適合させるか、どの下流アプリにどの帰属形式が必要か、顧客が求める監査配信の保証がどの程度必要かを、このベータで検証している段階だと説明しています。

「自社で運用済みだから、顧客環境でも同じ水準で機能する」と読むのは早計です。

私たちの見方——エージェントの権限設計を見る6つの観点

モデルの性能は重要です。

そのうえで、安全に任せられるかどうかは、権限がどう設計され、どこで強制されるかにも左右されます。

MIFは実務上の枠組みとして、本人性・認可された範囲と行動上限・実行時の強制・人による監督・操作記録・権限の縮小という6つの観点を使っています。

AAMとWriteGuardは、抽象度の異なる二つの資料です。

AAMは提案された参照アーキテクチャであり、WriteGuardはプライベートベータの具体的な実装です。

WriteGuardは、MCPツールの実行前のポリシー適用・行為主体の帰属・監査に関わる部分を、サーバー側で具体化した実装と見ることができます。

6つの観点に対応させると次のようになります。

MIFの観点	Cloudflare資料との対応	位置づけ
本人性	Agent Identity Broker	AAMが提案する参照アーキテクチャ
認可された範囲と行動上限	Task-Scoped Access Engine	AAMが提案する参照アーキテクチャ
実行時の強制	Mediation Layer、WriteGuard	AAMは設計提案。WriteGuardはプライベートベータの実装
人による監督・承認	監督を例外的な判断に限るというAAMの原則、Grant Review Loop	重要な判断と、将来のタスクテンプレート変更の承認に人を限定
操作記録	Agent Activity Log、WriteGuard監査ログ	AAMは提案。WriteGuardは社内実装をプライベートベータとして提供中
権限の縮小	Trust Ratchet	AAMが提案する参照アーキテクチャ

プロンプトに「これ以上はしないでください」と書くだけの統制は、モデルの誤りや文脈の取り違えの影響をそのまま受けます。

モデルの外側に制御を置けば、関係する実行経路がその制御を迂回できないという前提のもとで、プロンプトだけに依存するより強い境界になりえます。

この但し書きは実際に重要です。

AAM自身が、ツール呼び出しや通信がMediation Layerを迂回できないこと、共通の制御基盤（control plane）が異常時に拒否側へ倒れる（fail closed）こと、そして境界の外にある処理までは保証対象に含まれないことを明記しています。

記事は「Coverage follows the mediation boundary…Encrypted traffic, activity outside the boundary, and telemetry failures create collection gaps that deployments should make explicit（カバレッジは仲介の境界に従う。暗号化された通信・境界外の活動・テレメトリの失敗は収集の隙間を生み、導入側はそれを明示すべきである）」としています。

制御をモデルの外に置くことは強い設計ですが、境界そのものに漏れがないかは別途確認が要る、ということです。

私たちが2パスのリファイン工程やPRベースの公開ゲートを自社の記事生成の仕組みに組み込んでいるのも、近い発想です。

確認が通らなければ次に進めない構造を、個別のやり取りに頼らず埋め込んでおくという考え方です。

もう一つ注目しているのが、Trust Ratchetの「一方向にしか進まない」という設計です。

権限を一度絞ったら、そのタスクの中では緩めない。

迷いが生じたときに、より狭い権限状態へ既定で倒れる設計には価値があると私たちは考えています。

同時に、それが正当な業務まで止めうることも認識しておく必要があります。

AAM自身が「A broad ratchet policy will deny benign activity along with malicious activity, especially while classifications and destination policies are coarse（粗いRatchetポリシーは、分類や送信先ポリシーが粗いうちは特に、悪意ある活動だけでなく正当な活動も拒否してしまう）」と述べ、さらに「It does not prove that every permitted output is safe（許可されたすべての出力が安全であることを証明するものではない）」とも明記しています。

保護対象データへのどのアクセスを権限縮小のきっかけにするか、どの出力先を残すかは、実際の拒否記録を見ながら調整が必要な設計対象だということです。

なぜ、これだけの統制機能が同じ週に集まったのか

Agents Weekでは、WalletsやCloudflare Agentsのようにエージェントの実行範囲を広げる発表と、AAM・WriteGuardのようにその行動を制御・追跡するための発表が並びました。

Cloudflare自身も週間まとめ記事の中で、エージェントが高度化・自律化するほど、課題がモデルの性能だけでなく本人性・オーケストレーション・可観測性・セキュリティへ広がっていくと説明しています。

ここから先は私たちの見立てです。

実行能力を広げる機能と統制機能が同じ週に集まったのは、単なる偶然というより、両者を一体で整備する必要性が高まっていることの表れではないかと捉えています。

Cloudflareの説明にある「エージェント経済の参加者」という表現は、エージェントが取引の当事者になる場面が今後増えることを前提にした言い方です。

取引や書き込みを任せる範囲が広がるほど、その裏側でどこまで縛れるかという設計の重みは増します。

ただし、これはあくまでインフラ提供事業者としてのCloudflareの取り組みであり、これを導入すれば権限設計の問題がすべて解決するという話ではありません。

どのタスクをエージェントに任せるか、何を「保護対象」として指定するか、誰が例外を承認するかは、結局のところ利用する企業側が決める設計事項です。

自社でエージェントに権限を渡す前に確認する項目（叩き台）

AAMやWriteGuardのような機能を実際に使うかどうかに関わらず、AIエージェントに業務上の権限を持たせる場面では、次のような観点を先に整理しておくと設計の抜けが減ります。

ここに挙げる項目や粒度はあくまで一例であり、具体的な範囲や運用の厳しさは、自社の業務内容・リスク許容度・規制環境に合わせて決めるべきものです。

観点	確認する問い	主な実装先の候補
本人性	エージェントの識別情報はタスク単位か、恒常的な鍵の使い回しか	認証基盤・シークレット管理
職務範囲・行動上限	このタスクで触れてよいデータ・呼び出してよいツールをどう固定するか	権限管理・ワークフロー設計
監督	既定は許可か拒否か。例外はどこで人の承認を挟むか	ミドルウェア・接続基盤の設定
権限縮小	想定外のデータや操作に触れたとき、権限を自動的に縮小できるか	権限管理の実装、社内ポリシー
操作記録	どのエージェントが、誰の代理として、どのタスク・ポリシー結果に基づき、何を実行したかを後から追えるか	ログ基盤・監査システム
実行時の書き込み判断	書き込み系の操作をリスクの重さで仕分けているか。取り消せない操作は何か	接続先ツールの設定、社内運用ルール
制御境界の網羅性	すべてのツール呼び出しと外向き通信が、宣言した制御点を通るか。直接接続・別クライアント・暗号化された通信・経路外での実行が、その制御を迂回しうるか	ハーネス、ネットワーク、MCPサーバー、接続設計

最後の行は特に注意が要ります。

Cloudflareは8月14日公開の続編記事で、MCPの通信を観測・管理できる場所をクライアント・ネットワーク・MCPサーバーの3層に分けたうえで、そのいずれからも見えない経路があることを明示しています。

ローカルの stdio 呼び出し、社外ネットワークからの接続、TLS検査の対象外とした通信、ゲートウェイを通らないリクエストはこの可視範囲の外に出ます。

また、上流のURLへ直接つなげば、ポータルのポリシー・整理されたツールカタログ・ツール単位の監査証跡をまとめて迂回できるとも説明されています。

この表を作るときに大事なのは、どの項目が「エージェント自身には変更できない外枠」で、どの項目が「社内の運用ルールとして守ることになっているだけ」かを混同しないことです。

前者はエージェントの外側で技術的に強制することを意図した縛りであり、後者は運用手順が守られ続ける限りにおいて有効な縛りだからです。

まとめ——モデルの性能と権限の設計は、別の設計課題

本稿で扱ったCloudflareの2本は、エージェントをより賢くすることよりも、エージェントがどの権限のもとで動くかを統制することに焦点を当てています。

AAMはタスク単位の認証情報・仲介された実行・証拠に基づく権限の見直し・活動の記録・一方向の権限縮小を提案しています。

WriteGuardはより範囲を絞り、MCPツールの書き込みを分類・制御し、エージェントの帰属情報を付け、活動を記録する具体的な実装を提供しています。

ただし両者は段階が違います。

AAMは提案された参照アーキテクチャであり、WriteGuardは顧客環境での検証が続くプライベートベータです。

どちらも、エージェントの権限設計に対する完成した最終回答として扱うべきではありません。

また、どのタスクをエージェントに任せるか、何を保護対象とみなすか、誰が例外を承認するかを、インフラが代わりに決めてくれるわけでもありません。

エージェントに実際の業務権限を渡す前に確かめるべきなのは、モデルの性能だけではありません。

その権限がどこで強制され、どの経路がその制御を迂回しうるか、どんな証拠が記録され、想定外の挙動が起きたときに誰が止められるか——ここまで含めて見る必要があると私たちは考えています。

情報確認について

本記事は2026年8月20日確認時点で、Cloudflare公式ブログの次の記事を主要な参照元として作成しています。

• 「Everything we launched during Agents Week」（Shelley Jones、Ann Ming Samborski、Kathy Liao、2026年8月10日公開）
• 「The Agent Access Model」（Matt Silverlock、2026年8月5日公開）
• 「WriteGuard: fine-grained controls for MCP Servers」（Scott Roe-Meschke、Kenny Johnson、2026年8月5日公開）
• 「How Cloudflare detects MCP traffic and helps secure it」（Kenny Johnson、2026年8月14日公開）

Agent Access Modelは、Cloudflareが提案する参照アーキテクチャであり、単一の製品または一般提供済みの機能として発表されたものではありません。

WriteGuardは、Cloudflareが社内のMCP環境で運用してきた仕組みをもとに、MCPサーバーポータル向けのプライベートベータとして提供されています。

公開記事では、顧客環境における安全性や防御効果を定量的に検証した結果までは示されていません。

本稿の6つの観点（本人性・認可された範囲と行動上限・実行時の強制・人による監督・操作記録・権限の縮小）という枠組み、およびAgents Weekの発表を権限設計の観点から横断的に捉える部分はMIFによる分析です。

製品の提供状況・仕様・リスク分類・監査機能は今後変更される可能性があります。