Web Bot Auth とは何か
Web Bot Auth は、IETF working group と、その automated web traffic の認証に関する Internet-Draft 作業の名称です。考え方はシンプルです。crawler、AI assistant、autonomous agent が HTTP Message Signatures (RFC 9421) を使って HTTP リクエストに署名し、その署名を検証できる public key を、自分たちが管理する識別子の下で公開します。すると website は、user-agent string のように誰でも複製できるものに頼るのではなく、そのリクエストが本当に記載された operator から来たものかを確認できます。これが product team にとって何を意味するかは Web Bot Auth for product teams を、実装手順は how to verify signed AI agent requests の guide を参照してください。
2026年11月時点で、working group の中核文書は draft-ietf-webbotauth-httpsig-protocol です。ここでは、インラインでの key discovery のための Signature-Agent header、JSON Web Key Sets に基づく key directory format、そしてその directory を公開する well-known URI を定義しています。working group documents page には、関連する個別 draft と並んで掲載されています。これらは Internet-Draft であり、作業中の文書です。key をどのように見つけるか、どの request component に署名が必要か、どの header が operator 情報を運ぶかといった詳細は、版によって変わることがあります。実装者は、どのスナップショットでもなく、現在の draft を追う必要があります。
なぜ重要なのか
Website と API は長く、user-agent string と IP range で bot を識別してきました。しかし両方に限界があります。user-agent string は簡単に偽装でき（user-agent spoofing を参照）、IP range は変動し、クラウド事業者間で共有されます。AI agent が人に代わって browse し、API を呼び出し、MCP servers を使い始めると、application には、協調する automated client と匿名の client を見分ける、より堅牢な方法が必要になります。
署名付き request は、そのより堅牢な基盤を与えます。検証済みの署名があれば、application は既知の operator を一貫して認識し、人間向けの interface ではなく構造化された経路を与え、その activity を正確に測定できます。
高レベルではどう動くか
- operator は key pair を生成し、自分の identity に紐づく場所、通常は自分の domain 配下の
http-message-signatures-directorywell-known path に public key を公開します。 - 各 request には、選択された request component を対象とする
Signature-InputとSignatureheader に加え、key identifier と、key directory を指すSignature-Agentheader が含まれます。 - 受信側の site は、operator が公開した key を取得またはキャッシュし、signature base を再構成して、署名を検証します。
- 成功すると、その site は、その request が、公開された identifier に関連付けられた、その key の保有者によって生成されたと分かります。
何を示し、何を示さないか
Web Bot Auth の署名は、automated client を認証します。ただし、次の点には答えません。
- operator がその要求を行う権限を持つかどうか (agent authorization)
- 人がその action を指示したか、承認したかどうか (delegated authority)
- action が安全かどうか、また返された content が適切に使用されるかどうか
これらは、受信する application 自身の authentication、authorization、policy の判断に残ります。ブログ記事 what signed AI agent requests prove, and what they don't では、この境界を詳しく扱っています。
よくある誤解
- "Every bot will sign soon." 採用は client ごとに進みます。application には、署名付き、declared、anonymous の traffic が長い間混在するため、それぞれを明確に扱う方法が必要です。
- "A signature makes a bot good." 署名は bot を known にします。known は policy の出発点であって、policy そのものではありません。
- "The draft is final." これは進化中の Internet-Draft です。現在の本文を基準に実装し、改訂を想定してください。
Proof of Actor との関係
Proof of Actor は、検証済みの署名を、その key と identifier に限定した basis verified の evidence として扱います。declared 名称や inferred signal とは分けて保持し、identity を permission には変換しません。Proof of Actor は、これらの standards が成熟するにつれて、signed request の検証に対応するよう設計されています。Route における独自の policy が、verified な agent が何を行えるかを決めます。
これが APIs と MCP servers にどう当てはまるかを見るか、early access を申請 してください。
出典
- IETF Web Bot Auth working group: charter、chairs、status
- Web Bot Auth working group documents: 現在の working group 文書と関連 draft
- draft-ietf-webbotauth-httpsig-protocol:
Signature-Agent、JWKS key directory、およびその well-known URI（2026年11月時点で作業中） - RFC 9421: HTTP Message Signatures: Web Bot Auth が基盤とする signature standard