Cloudflare Mesh時代のAIエージェント接続設計, プライベートAPIをゼロトラストで安全に開く方法
Cloudflare Meshは、ユーザー・ノード・AIエージェントを含むアクセス主体に対して、Workers VPCと連携した安全なプライベート接続を提供する流れを明確にしました。これは単なるネットワーク機能追加ではなく、エージェント運用の前提を変える更新です。
参照: https://blog.cloudflare.com/tag/workers-ai/
なぜ従来方式が限界なのか
従来は次のような方式が一般的でした。
- 長寿命のサービス資格情報を共用
- 手動で管理されたトンネルを維持
- 接続できれば広範囲に到達可能
人間主体の運用では何とか回っても、エージェント主体になると破綻します。理由は単純で、アクセス回数と自動化密度が桁違いだからです。
- 1時間に数百回の短命セッション
- 複数ツールへの連鎖アクセス
- 失敗時のリトライ連打
この状態で「広く繋がる」設計を残すと、1つの誤判定が全体事故につながります。
設計原則, 経路より先にアイデンティティ
ゼロトラストで重要なのは、ネットワークを先に開くことではなく、誰が何をしようとしているかを先に判定することです。
判定に必要な軸は4つです。
- 主体: どのエージェント実行体か
- 意図: どの操作を要求しているか
- 宛先: どの分類のリソースか
- 期間: いつまで許可するか
この4軸を満たしたときだけ経路を開く、という順序に変える必要があります。
実装しやすい4レイヤ構成
1. Admissionレイヤ
Workersを入口にして、全ツール呼び出しを検査します。
- ワークロード署名検証
- 実行コンテキスト付与
- 宛先とメソッドの適合判定
2. Segmentationレイヤ
Workers VPC内で接続先を役割分離します。
- データ参照系API
- 制御系API
- 運用保守インターフェース
同一トークンで3系統すべてに触れられる設計は避けます。
3. Credentialレイヤ
資格情報は短命・用途限定で払い出します。
- TTLは分単位
- タスク種別ごとの分離
- ワークフロー終了時に自動失効
4. Observationレイヤ
アクセスイベントをSecOpsとPlatformで共通化します。
- 発行元エージェントID
- 宛先/操作種別
- ポリシー判定ID
- 返却データのリスク分類
観測面を分断すると、障害対応とセキュリティ対応が衝突しやすくなります。
ブラスト半径を抑えるポリシー実践
意図ベース許可
URL単位だけでなく、操作意味で許可します。
ticket.createは許可ticket.deleteは禁止db.read:sanitizedは許可db.read:rawは禁止
リスク階層ルーティング
- 低リスク: 直接実行
- 中リスク: 追加確認ポリシー
- 高リスク: 人間承認を必須化
セッション予算
自律実行に上限を持たせます。
- ツール呼び出し回数
- 外部書き込み回数
- 取り扱いデータ量
上限超過時に自動停止できると、暴走時の被害が小さくなります。
インシデント対応を事前定義する
エージェント接続系の事故は、発生後のアドホック対応では遅れます。最低限、次をRunbook化しておくべきです。
- 対象ワークロードIDの即時失効
- 直近アクセスの再生（どこに何をしたか）
- 一時denyポリシーで区画隔離
- フォレンジックモード再実行
「後で考える」は現実的ではありません。自動化比率が高いほど、初動速度が成果を左右します。
導入ロードマップ
1-2週目, 可視化
- エージェントが触る内部システムの棚卸し
- 高リスク操作の洗い出し
- 利用パターンの基準値取得
3-6週目, 封じ込め
- 高リスク系から意図ベース許可に移行
- 長寿命共用トークン廃止
- 短命資格情報ブローカー導入
7-10週目, 統制定着
- リスク別ルーティング運用
- 承認証跡を変更管理へ接続
- セキュア接続のSLO化
まとめ
Cloudflare Meshの価値は「つながること」ではなく、「必要最小限だけ確実につなぐこと」です。エージェント時代の内部接続は、ネットワーク機能単体でなく、ID・ポリシー・証跡を統合した運用設計で初めて安全にスケールします。
