Web Bot Auth

Was Web Bot Auth ist

Web Bot Auth ist der Name einer IETF-Arbeitsgruppe und ihrer Internet-Draft-Arbeit zur Authentifizierung automatisierten Web-Traffics. Die Idee ist einfach: Crawler, KI-Assistenten und autonome Agenten signieren ihre HTTP-Anfragen mit HTTP Message Signatures (RFC 9421), und veröffentlichen die öffentlichen Schlüssel, mit denen diese Signaturen überprüft werden, unter einer Kennung, die sie kontrollieren. Eine Website kann dann bestätigen, dass eine Anfrage tatsächlich von dem von ihr benannten Betreiber stammt, statt sich auf einen User-Agent-String zu verlassen, den jeder kopieren kann. Was das für ein Produktteam bedeutet, steht in Web Bot Auth für Produktteams; Implementierungsschritte finden Sie im Leitfaden wie signierte Anfragen von KI-Agenten überprüft werden.

Stand November 2026 ist das Kerndokument der Arbeitsgruppe draft-ietf-webbotauth-httpsig-protocol, das einen Signature-Agent-Header für die Schlüsselermittlung im Band, ein auf JSON Web Key Sets basierendes Schlüsselverzeichnisformat und einen well-known URI definiert, unter dem dieses Verzeichnis bereitgestellt wird. Die Dokumentenseite der Arbeitsgruppe führt es zusammen mit verwandten individuellen Drafts auf. Das sind Internet-Drafts, also Arbeiten in Fortschritt. Details wie die Art der Schlüsselermittlung, welche Anfragebestandteile signiert werden müssen und welche Header Betreiberinformationen tragen, können sich zwischen Versionen ändern. Implementierer sollten die aktuellen Drafts verfolgen und nicht einen beliebigen Snapshot.

Warum das wichtig ist

Websites und APIs identifizieren Bots seit Langem über User-Agent-Strings und IP-Bereiche. Beides hat Grenzen: User-Agent-Strings sind trivial zu fälschen (siehe User-Agent-Spoofing), und IP-Bereiche verschieben sich und werden von Cloud-Anbietern gemeinsam genutzt. Wenn KI-Agenten beginnen, im Auftrag von Menschen zu browsen, APIs aufzurufen und MCP servers zu verwenden, brauchen Anwendungen eine robustere Methode, um kooperierende automatisierte Clients von anonymen zu unterscheiden.

Signierte Anfragen geben diese robustere Grundlage. Eine verifizierte Signatur ermöglicht es einer Anwendung, einen bekannten Betreiber konsistent zu erkennen, ihm einen strukturierten Pfad statt einer menschenähnlichen Oberfläche zu geben und seine Aktivität genau zu messen.

Wie es auf hoher Ebene funktioniert

1. Der Betreiber erzeugt ein Schlüsselpaar und veröffentlicht den öffentlichen Schlüssel an einem Ort, der mit seiner Identität verknüpft ist, typischerweise dem well-known-Pfad http-message-signatures-directory unter seiner Domain.
2. Jede Anfrage enthält Signature-Input- und Signature-Header, die ausgewählte Anfragebestandteile abdecken, plus eine Schlüsselkennung und einen Signature-Agent-Header, der auf das Schlüsselverzeichnis verweist.
3. Die empfangende Website ruft die veröffentlichten Schlüssel des Betreibers ab oder cached sie, baut die Signaturbasis neu auf und verifiziert die Signatur.
4. Bei Erfolg weiß die Website, dass die Anfrage von dem Inhaber dieses Schlüssels erzeugt wurde, der mit dieser veröffentlichten Kennung verknüpft ist.

Was es belegt, und was nicht

Eine Web Bot Auth-Signatur authentifiziert den automatisierten Client. Sie beantwortet nicht:

• ob der Betreiber berechtigt ist, das zu tun, was er anfordert (agent authorization),
• ob eine Person die Aktion angewiesen oder genehmigt hat (delegated authority),
• ob die Aktion sicher ist oder ob der zurückgegebene Inhalt angemessen verwendet wird.

Diese Entscheidungen bleiben der eigenen Authentifizierung, Autorisierung und Policy der empfangenden Anwendung vorbehalten. Unser Blogbeitrag darüber, was signierte Anfragen von KI-Agenten belegen und was nicht, beleuchtet diese Grenze.

Häufige Missverständnisse

• "Jeder Bot wird bald signieren." Die Verbreitung wächst Client für Client. Anwendungen werden lange eine Mischung aus signiertem, deklariertem und anonymem Traffic sehen, daher brauchen sie einen klaren Umgang mit jedem dieser Fälle.
• "Eine Signatur macht einen Bot gut." Sie macht einen Bot bekannt. Bekannt ist der Ausgangspunkt für eine Policy, nicht die Policy selbst.
• "Der Draft ist endgültig." Es ist ein sich entwickelnder Internet-Draft. Entwickeln Sie gegen den aktuellen Text und rechnen Sie mit Überarbeitungen.

Wie sich Proof of Actor dazu verhält

Proof of Actor behandelt eine validierte Signatur als Evidenz mit der Grundlage Verified, beschränkt auf den Schlüssel und die Kennung, die sie belegt. Es trennt das von deklarierten Namen und inferierten Signalen und macht aus Identität nie Berechtigung. Proof of Actor ist darauf ausgelegt, signierte Anfragen zu verifizieren, während diese Standards reifen; Ihre eigenen Policies in Route entscheiden, was ein verifizierter Agent tun darf.

Sehen Sie, wie das in APIs und MCP servers passt, oder beantragen Sie frühzeitigen Zugang.

Quellen

• IETF Web Bot Auth-Arbeitsgruppe: Charter, Chairs und Status
• Dokumente der Web Bot Auth-Arbeitsgruppe: aktuelle Arbeitsgruppen- und verwandte Drafts
• draft-ietf-webbotauth-httpsig-protocol: Signature-Agent, das JWKS-Schlüsselverzeichnis und sein well-known URI (Arbeit in Fortschritt Stand November 2026)
• RFC 9421: HTTP Message Signatures: der Signaturstandard, auf dem Web Bot Auth aufbaut