8月5日、Cloudflareが「WriteGuard: Fine-grained controls for MCP Servers」と題した記事を公開した。MCPサーバー上のAIエージェントによる書き込み操作を細粒度で制御・監査するレイヤー「WriteGuard」について詳しく紹介されている。

「Joeが1時間に1000件チケットを閉じた」問題

Cloudflareがこの仕組みを作るに至った動機を、記事は架空のシナリオで説明している。エンジニアのJoeが午後から複数のバックグラウンドエージェントを走らせていたところ、プロンプトが少し広すぎたクリーンアップタスクが暴走し、数千件のチケットを自動でクローズしてしまった。

問題はそれだけではない。Joeが手動でクローズした記録と、エージェントがクローズした記録が、どちらも「Joeの操作」として同一に記録されてしまう。ネットワークログもエージェントセッションを区別しない。何が起きたか事後調査が困難になる。

記事はClaude AIがデータベースを削除した実際の事例にも言及し、「コントラクト管理ソフトで契約を書き換えるエージェント」「サポートキューで数百件の返信を送るエージェント」といった現実的なリスクを挙げている。

WriteGuardの設計思想

WriteGuardはポリシー・アトリビューション（帰属）・監査の共有レイヤーとして機能する。MCPサーバー自体のコードには手を入れず、各ツールの設定だけで動作する点が特徴だ。

MCP（Model Context Protocol）は、AIアプリケーションを外部ツールやデータソースに接続するためのプロトコル標準。MCPサーバーはツールを提供し、AIエージェントはそのツールを呼び出して実際の処理を実行する。

WriteGuardはツール呼び出しの経路に割り込み、以下の3パターンのいずれかを実行する：

• パススルー: そのまま通す（読み取り系ツール）
• エンリッチ: エージェントのアトリビューションを付加して通す
• ブロック: ハンドラが実行される前に止める

リスクティアによる分類

各ツールにはリスクティアが割り当てられ、それに応じてログ記録の有無やブロックが決まる。

ツール設定はTypeScriptでこう書く：

const sendEmailTool = {
  tool: EmailMCP.sendEmailTool,
  writeGuard: {
    riskLevel: RiskLevel.CONTAINED_WRITE,
    enabled: true,
    labeling: {
      field: "body",
      supportedFormats: [
        LabelFormat.PLAIN_TEXT,
        LabelFormat.HTML,
      ],
    },
  },
};

enabled: falseにするだけでツール呼び出しをブロックでき、その試みは監査ログに記録される。

GitLabの実例：3つのツールの扱い方の違い

記事はGitLabのMCPサーバーを使って、同じサーバー・同じIDフロー・同じAPIを通る3つのツールがWriteGuardでどう処理されるかを示している。

• get_merge_request（READ_ONLY）: 変更なしでパススルー
• create_mr_note（CONTAINED_WRITE）: エージェントのアトリビューションをnoteフィールドに挿入してから実行し、非同期で監査イベントを記録する。元記事によれば、アトリビューションはGitLabが受け付けるフォーマットに沿ったプレフィックス文字列としてnoteフィールドの先頭に付加される形式を取っており、ダウンストリームアプリケーションごとに対応フォーマット（プレーンテキスト・HTMLなど）をsupportedFormatsで指定できる設計となっている
• merge_mr（CRITICAL、disabled）: Cloudflare社内ではマージが本番デプロイパイプラインを起動するため、ヒューマン・イン・ザ・ループを必須とし、エージェントからの呼び出しはブロック。試みはダッシュボードに記録される

アトリビューションの挿入形式がツールごと・アプリケーションごとに異なる点は、ベータ期間中に検証すべき課題の一つとして記事でも明示されている。

エージェントアカウントを作らない設計判断

Cloudflareは「エージェント専用アカウント」を導入しない判断をした。専用アカウントを作ると権限管理が二重になり、エージェントと責任者の人間の紐付けが曖昧になるためだ。

代わりに、Cloudflare AccessとOAuthによる既存の人間アイデンティティを維持しながら、WriteGuardがそこにMCPクライアントとセッション情報を付加する。JoeがアクセスできないイシューはJoeのエージェントもアクセスできない。書き込みには「誰のエージェントが、どのセッションで実行したか」が記録される。

監査ログの実装

監査イベントの送信は非同期処理で行われ、エージェントのレスポンスレイテンシに影響しない。イベントにはサーバー名、ツール名、リスクティア、結果（成功/失敗/ブロック）、ユーザー、クライアント、処理時間が含まれる。秘密情報・機密情報に当たるフィールドの値はスクラブ（除去）される。

社内のMCPサーバーポータルが提供するリクエストログはツール呼び出しそのものを記録するのに対し、WriteGuardのダッシュボードはツールのセマンティック分類・エージェントコンテキスト・バックエンドサーバーの実行結果を加えた形で可視化する。

監査ログの配信保証レベルの要件については、ベータ期間中に顧客ユースケースを通じて検証する予定とされており、現時点での仕様は確定していない点に注意が必要だ。

プライベートベータの状況

Cloudflare社内では記事公開時点で27台のMCPサーバーに展開済み（同記事内で言及されている4月時点の数字は13台）であり、現在プライベートベータとして外部提供を開始している。ベータ期間中に検証したいのは、リスクモデルが顧客ツールにどうマッピングされるか、どのダウンストリームアプリケーションでどのアトリビューション形式が必要か、監査ログの配信保証レベルの要件、といった点だ。

書き込みツールをMCPサーバーに追加しようとしている組織はプライベートベータへの申し込みができる。

詳細はWriteGuard: Fine-grained controls for MCP Serversを参照していただきたい。