このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
ボットやエージェントがリクエストに暗号署名を付け始めるにつれ、Webサイト運営者がサービスをセットアップする際にパブリックキーを知る必要性が高まっています。有名なフェッチングやクローラーのパブリックキー素材を見つけることはできるかもしれませんが、次の1,000、次の1,000,000ではどうなるでしょうか？また、彼らが本人であることを確認するために、どのようにパブリックキー材料を見つければいいのでしょうか？この問題をディスカバリーと呼びます。
この問題は、高度なエージェントを大規模に構築、デプロイ、運用するための包括的エージェンティックプラットフォームであるAmazon Bedrock AgentCore、およびAIエージェントによる大規模なWebサイトとのインタラクションを可能にする、高速かつ安全なクラウドベースのブラウザランタイムであるAgentCore Browserと共有します。AgentCoreチームは、各顧客がそれぞれのリクエストに簡単に署名できるようにしたいと考えています。これにより、CloudflareやCDNインフラストラクチャの他のオペレーターは、AgentCoreからのエージェント署名をモノリスとではなく、個々のエージェントから見ることができます。（注：この方法は個々のユーザーを識別するものではありません。）そのために、CloudflareはAgentCoreのお客様のパブリックキーを大量に取り込み、登録する方法を必要としていました。
このブログ記事では、インターネット上で簡単に発見する方法として、ボットとエージェントのレジストリを提案します。また、Webボット認証をレジストリ形式で拡張する方法についても概説しています。誰でも作成可能で簡単にインポートできるIPリストと同様に、レジストリ形式はエージェントキーを取得するためのURLのリストであり、誰でも作成およびインポートできます。
当社は、そうしたレジストリは、Webサイト運営者が信頼できるオープンなキュレーターのエコシステムを育み、強化すべきだと考えています。
当社は5月に「Web Bot Auth」というプロトコル提案を発表しました。これは、ボットやエージェントの開発者がインフラストラクチャからのリクエストに暗号署名する方法を定めたものです。
現在、Vercel、Shopify、Visaなど、プロトコル提案の実装が複数存在しています。これは積極的に議論され、貢献もされています。Webボット認証は、IPやユーザーエージェントのような脆弱な識別から、より信頼できる暗号による認証に移行するための第一歩となります。ただし、IPアドレスと同様に、暗号化キーは仮名型のIDです。大規模なCDNのスケールやリーチがないWebサイトを運営している場合、既知のクローラーのパブリックキーはどのようにして検出されますか？
最初のプロトコル提案では、1つのアプローチを提案していました。ボットオペレーターは、鍵をホストするHTTPエンドポイントを指す、新しく定義されたHTTPヘッダーSignature-Agentを提供するというものでした。IPアドレスと同様に、デフォルトはすべてを許可することになっていますが、特定のオペレーターがあまりにも多くのリクエストを行っている場合、レート制限の引き上げやオペレーターへの連絡などの対策を講じることができます。
こちらは、Shopifyのオンラインストアの例です。
Signature-Agent: "https://shopify.com"
こうしたことをすべて念頭に置いた結果、次の問題が生じました。Cloudflareは、顧客が許可したいトラフィックを適切なデフォルトで制御できるようにしつつ、顧客や小規模なオリジンに縛られないオープンキュレーションのエコシステムを発展させるにはどうすればよいでしょうか？
このようなエコシステムは、IPアドレスのリスト（例： avestel-bots-ip-lists）やrobots.txt（例： ai-robots-txt）に対して存在します。どちらについても、インターネット上の正規リストを見つけ、これらのIPからのトラフィックを許可または拒否するようにWebサイトを簡単に設定することができます。NGINXやHAプロキシの直接設定を提供し、それを使ってCloudflareアカウントを設定することができます。たとえば、次のようなrobots.txtをインポートします。
User-agent: MyBadBot
Disallow: /
ここでレジストリ形式が登場し、署名エージェントキーを指すURLのリストを提供します。
# AI Crawler
https://chatgpt.com/.well-known/http-message-signatures-directory
https://autorag.ai.cloudflare.com/.well-known/http-message-signatures-directory
# Test signature agent card
https://http-message-signatures-example.research.cloudflare.com/.well-known/http-message-signatures-directory
これだけです。レジストリには、すべての既知の署名エージェントのリスト、学術研究エージェント用の厳選されたリスト、検索エージェント用などを含めることができます。
誰でもこれらのリストを保守、ホストすることができます。IPやrobots.txtリストと同様に、このようなレジストリは任意のパブリックファイルシステムでホストすることができます。つまり、GitHubでリポジトリを作成したり、Cloudflare R2にファイルを配置したり、メールの添付ファイルとして送信したりすることができます。Cloudflareは、このレジストリの最初のインスタンスの1つを提供し、他の人がそのレジストリに貢献したり、自分で構築する際に参照したりできるようにする予定です。
署名エージェントを知ることは素晴らしいことですが、それだけではありません。たとえば、検証済みボットであるためには、Cloudflareが、そのインフラストラクチャからのリクエストが突然失敗したり、形式を変更したりして、予期しないエラーが発生する場合に備えて、連絡方法を必要とします。実際、運営者の名前、連絡先方法、ロゴ、予想されるクロール速度など、オリジンが知りたい情報はたくさんあります。
そのため、レジストリ形式を補完するために、JWKSディレクトリ（RFC 7517）を追加のメタデータで拡張する署名エージェントカード形式を提案しました。昔ながらの連絡先カードに似たようなこのカードには、エージェントやクローラーについて誰かが知りたいと思うような重要な情報がすべて記載されています。
以下に説明のための例を示します。フィールドは変更される可能性があることに注意してください：jwks-uriの導入、ロゴがより説明的になるなどです。
{
"client_name": "Example Bot",
"client_uri": "https://example.com/bot/about.html",
"logo_uri": "https://example.com/",
"contacts": ["mailto:[email protected]"],
"expected-user-agent": "Mozilla/5.0 ExampleBot",
"rfc9309-product-token": "ExampleBot",
"rfc9309-compliance": ["User-Agent", "Allow", "Disallow", "Content-Usage"],
"trigger": "fetcher",
"purpose": "tdm",
"targeted-content": "Cat pictures",
"rate-control": "429",
"rate-expectation": "avg=10rps;max=100rps",
"known-urls": ["/", "/robots.txt", "*.png"],
"keys": [{
"kty": "OKP",
"crv": "Ed25519",
"kid": "NFcWBst6DXG-N35nHdzMrioWntdzNZghQSkjHNMMSjw",
"x": "JrQLj5P_89iXES9-vFgrIy29clF9CC_oPPsw3c5D0bs",
"use": "sig",
"nbf": 1712793600,
"exp": 1715385600
}]
}
大規模にAIエージェントを構築・デプロイするためのエージェンティックプラットフォームであるAmazon Bedrock AgentCoreは、AgentCore BrowserサービスにWeb ボット Authを採用しました（詳細については投稿をご覧ください）。AgentCore Browserは、プロトコルの成熟を見計らって、現在パブリックプレビューで利用可能なサービス署名鍵からお客様固有の鍵に移行する予定です。Cloudflareやオリジン保護サービスを提供する他の運営者は、AgentCoreの全体ではなく、個々のAgentCoreのお客様からの署名を見て検証することができます。
また、Cloudflareは、信頼するボットやエージェントのレジストリをRadarを通じて提供しています。レジストリ形式を使用することで、Cloudflareが信頼するボットのサーバー上での利用を可能にします。
これらのレジストリは、今日から使用できます。Go for Caddyサーバーでは、複数のレジストリからキーをインポートすることを可能にするデモを提供しています。それはcloudflare/web-ボット-authにあります。構成は次のようになります：
:8080 {
route {
# httpsig middleware is used here
httpsig {
registry "http://localhost:8787/test-registry.txt"
# You can specify multiple registries. All tags will be checked independantly
registry "http://example.test/another-registry.txt"
}
# Responds if signature is valid
handle {
respond "Signature verification succeeded!" 200
}
}
}
署名エージェントカード形式を活用してレジストリを運用し、キュレートしたい理由はいくつかあります：
着信署名エージェントを監視これにより、お客様のドメインに到達するエージェントの署名エージェントカードを収集できるはずです。
既存のレジストリからインポートし、自分で分類します。上記の監視ステップから構築された一般的なレジストリはありますが、レジストリは、より多くのカテゴリに対してより有用である可能性があります。
エージェントとの直接の関係を確立する。たとえば、Cloudflareが ボットレジストリに対してこれを行ったり、GitHub公開リポジトリを使ってユーザーが問題をオープンできたりする場合もあります。
ユーザーについて学びましょう。セキュリティサービスを提供する場合、顧客が通過させたいレジストリ/署名エージェントを指定できるようにすることで、貴重なインサイトを得ることができます。
ボットやエージェントの暗号認証が増えるにつれ、検出の必要性も高まっています。
当社は、Signature-Agentにメタデータを付加し、レジストリの形でキュレートする軽量フォーマットと仕様の導入により、このニーズに対応し始めました。HTTPメッセージ署名のディレクトリ形式は拡張されていて、自己認証型のメタデータもいくつか含まれるようになり、レジストリはキュレーションエコシステムを維持しています。
将来的には、クライアントとオリジンが信頼できる署名エージェントを選択し、共通のフォーマットでCDNプロバイダー間で設定を移行し、キュレーションにはサードパーティのレジストリが必要になると予測しています。現在、ボット管理とルールエンジンへの機能統合に取り組んでいます。
試してみたい方は、GitHubにあるデモをご覧ください。当社を助けたいとお考えでしたら、来年度中に1,111名のインターンを採用し、求人を募集しています。