概要
Cloudflareの「signed agents」提案は、表向きは安全性向上だが、実際はオープンウェブの精神に反する危険性を孕む。 単一企業による許可制は、インターネット本来の分散性と相容れない。 認証と認可は異なる課題であり、両者を混同した「ボットパスポート」構想は本質的な解決策にならない。 真の解決策は、分散型・検証可能・委譲可能な認証モデルの採用。 プロトコル主導の標準化が、今後のエージェント時代のウェブの自由と発展を守る鍵。
Cloudflareの「signed agents」提案の問題点
- Cloudflare が提案する「signed agents」は、 許可リスト制 の導入
- 開発者やサービス提供者に 申請フォーム での登録を要求
- インターネット のオープン性や標準化の精神に反する運用
- 申請制は標準ではなく、 ベンダーの承認制 に過ぎない
- 単一企業による 中央集権的な管理 の危険性
オープンウェブの歴史と教訓
- Microsoft が90年代にウェブの囲い込みを試みたが失敗
- HTML5 や Open Web Platform が Flash や Silverlight などの独自ランタイムを駆逐
- オープンな標準が イノベーション を促進
- ベンダー主導の許可制は 発展を阻害 する
エージェント時代の新たな課題
- AI agents が情報取得・自動化・購入・契約交渉など多様な役割を担う時代
- 人間とエージェントの 境界が曖昧化
- 例:「友人にスマホを渡して返信を頼む」=委譲の体現
- 認証( 誰が行動しているか)と認可( 何ができるか)の違い
- Cloudflareは両者を 単一パスポート で解決しようとしているが本質的に不十分
「ボットパスポート」構想の限界
- パスポート(署名)だけでは 真正性の担保が不十分
- 委譲の 証明チェーン と リクエストごとの署名 が必要
- 単一署名 の使い回し=セキュリティリスク
- 必要なのは「 User X on Service YがAgent Zに委譲」のような 証明構造
望まれる認証・認可モデル
- 検証可能性 :誰でも独立に確認できる
- 合成可能性 :委譲チェーンを跨いで機能
- 分散性 :単一のゲートキーパーが存在しない
- 公開鍵暗号 によるDNS証明の応用
- 企業はDNSで公開鍵を公開し、第三者認証を実現
- 申請や中央ディレクトリ登録不要
エージェント時代の認可の課題と解決策
- 従来の OAuthスコープ は特定用途向けで有効だった
- エージェント は汎用的かつ短命な場合が多い
- 「 admin key」のような全権限付与は危険
- 認可はタスクごとに発行、エージェントごとではなくタスクごとにトークンを制御
- マカロン(macaroons)やビスケット(biscuits) 等、細粒度・短命・委譲可能なトークンの活用
- Open policy engines (OPAやAWS Cedar)によるRBAC/ABACの実装
委譲チェーンとリクエスト単位の認可モデル
- User X が Service Y でadminトークンを保持
- Agent Z に1タスク限定のトークンを派生
- Agent Z がサブエージェント用にさらに限定トークンを派生
- 各リクエストごとに 委譲チェーンの検証 が可能
標準化と分散型プロトコルの重要性
- この課題は Cloudflare や Google、 Microsoft 一社の問題ではない
- 未来のウェブ はプロトコル主導でなければならない
- 認証・認可・マネタイズは オープン・相互運用・標準化 が必須
- 数社による「有効エージェント」決定権の集中は ウェブの囲い込み を招く危険
今後のアクションと呼びかけ
- 委譲チェーン・リクエスト単位認可・タスクスコープ認可 のアイデアを オープンソース化
- 誰でも実装・議論・協力が可能な体制
- 興味・共感・批判・協力希望は jordi@fewsats.com まで連絡を推奨
- 未来は「 ゲートを握る者」ではなく、「 誰もが構築・共有・革新できるプロトコル」に託すべき