Seit Jahren bestand die einzige Möglichkeit für einen automatisierten Client, einer Website mitzuteilen, wer er ist, im Wesentlichen aus einem Namen im User-Agent-Header und, bei wenigen großen Betreibern, aus einer veröffentlichten IP-Adressliste oder einer Reverse-DNS-Prüfung. Namen lassen sich leicht kopieren. Netzwerkliste decken nur die Betreiber ab, die sie pflegen. Da KI-Agenten beginnen, im Web für echte Personen zu handeln, ist diese Lücke zu einem Produktproblem geworden, nicht nur zu einem Sicherheitsproblem.
Web Bot Auth ist der führende Versuch, diese Lücke zu schließen. Es gibt automatisierten Clients eine Möglichkeit, ihre Requests mit einem Key zu signieren, den sie kontrollieren und veröffentlichen, sodass eine Website die Signatur prüfen kann, statt einem Namen zu vertrauen. Dieser Erläuterungstext richtet sich an Produktmanager und Engineering-Verantwortliche, die verstehen müssen, was es ist, was sich dadurch ändert und was nicht, ohne die Spezifikationen vollständig lesen zu müssen.
Die Kurzfassung
- Was es ist: eine IETF-Arbeitsgruppe, webbotauth, und der Ansatz, den sie für die Authentifizierung automatisierter HTTP-Clients standardisiert.
- Wie es funktioniert: Der Client signiert Teile jedes Requests mit HTTP Message Signatures (RFC 9421) und verweist auf ein Verzeichnis seiner öffentlichen Keys. Die Website ruft den Key ab und prüft die Signatur.
- Was es belegt: welcher Key den Request signiert hat und dass die signierten Teile unterwegs nicht verändert wurden.
- Was es nicht belegt: dass der Agent für die angefragte Handlung autorisiert ist, dass er für einen bestimmten Nutzer handelt oder dass er sich korrekt verhält.
- Status im November 2026: RFC 9421 ist ein veröffentlichter Proposed Standard. Das Web Bot Auth-Protokolldokument ist ein Working-Group Internet-Draft und noch kein RFC.
- Was zu tun ist: Planen Sie, gültige Signaturen als starken Nachweis zu behandeln, unsignierten Traffic weiterhin zu verarbeiten und Autorisierungsentscheidungen in Ihrem eigenen Code zu belassen.
Was die IETF-Arbeit zu Web Bot Auth ist
Die IETF hat die Web Bot Auth-Arbeitsgruppe damit beauftragt, Methoden zur kryptografischen Authentifizierung automatisierter Clients und zur Bereitstellung zusätzlicher Informationen über die dahinterstehenden Betreiber zu standardisieren. Das Charter konzentriert sich auf Websites, die hauptsächlich Menschen dienen, und nennt eine breite Gruppe von Clients im Scope: Crawler, Web-Archive, Link-Checker, KI-Trainings-Crawler und KI-Agenten, die im Auftrag von Endnutzern handeln.
Zwei Ausschlüsse im Charter sind für Produktteams erwähnenswert. Die Authentifizierung von Endnutzern ist nicht im Scope, es geht also nicht darum, eine Person anzumelden. Auch das Nachverfolgen der Reputation von Bots ist nicht im Scope, daher sagt der Standard Ihnen, wer einen Request signiert hat, nicht, ob dieser Betreiber vertrauenswürdig ist.
Das Charter nennt drei Arten von Ergebnissen:
- Standards-Track-Dokumente zu Techniken, um automatisierte Clients gegenüber für Menschen gebauten Websites zu authentifizieren.
- Standards-Track-Dokumente dazu, mehr Informationen über einen anfragenden Bot über einen vorhandenen Identifikator wie einen Domainnamen oder eine URL zu übermitteln.
- Best Current Practice- oder Informationsdokumente zu operativen Themen wie Key-Management, Lebenszyklus und Bereitstellung.
Stand der Dokumente im November 2026
Im November 2026 hat die Arbeitsgruppe ein angenommenes Working-Group-Dokument: draft-ietf-webbotauth-httpsig-protocol, mit dem Titel "HTTP Message Signatures for automated traffic", in Revision 01 vom 29. Oktober 2026. Es ist ein Internet-Draft, also ein Dokument in Arbeit, das sich noch ändern kann. Es ist kein RFC.
Mehrere individuelle Drafts sind ebenfalls mit der Gruppe verbunden und werden diskutiert, darunter Vorschläge für ein Registry- und Agent-Card-Format, anonyme Bot-Authentifizierung, ein JSON-Format zur Veröffentlichung der IP-Ranges automatisierter Clients und ein Header für signierte Agent-Metadaten. Individuelle Drafts sind Vorschläge; keiner von ihnen wurde bis zu diesem Datum von der Gruppe übernommen.
Das Charter setzte 2026 Meilensteine für die Weiterleitung von Spezifikationen an die IESG zur Genehmigung. Im November 2026 bleibt das Protokolldokument ein Working-Group-Draft. Den aktuellen Stand finden Sie auf der IETF-Datatracker-Seite der Arbeitsgruppe und im Protokolldraft.
Wie HTTP Message Signatures funktionieren
Web Bot Auth baut auf RFC 9421, HTTP Message Signatures auf, der im Februar 2024 als Proposed Standard veröffentlicht wurde. RFC 9421 ist ein allgemeiner Mechanismus: Er definiert, wie ausgewählte Teile einer HTTP-Nachricht signiert werden und wie die Signatur in Headern übertragen wird. Web Bot Auth profiliert ihn für automatisierte Clients.
In einfachen Worten funktioniert ein signierter Agent-Request so:
- Der Betreiber erzeugt ein Schlüsselpaar. Er hält den privaten Key geheim und veröffentlicht den öffentlichen Key.
- Der Client wählt aus, was signiert wird. Er wählt Komponenten des Requests, etwa den Ziel-Host oder die URI und einen Erstellungszeitpunkt. Der aktuelle Draft verlangt, dass die Authority oder die Ziel-URI abgedeckt wird, damit eine Signatur für eine Website nicht einfach gegen eine andere wiederverwendet werden kann.
- Der Client signiert und sendet. Der Request enthält einen
Signature-Input-Header, der beschreibt, was signiert wurde und mit welchem Key, sowie einenSignature-Header mit dem Signaturwert. Der Draft verwendet einweb-bot-auth-Tag und erwartet für jede Signatur Erstellungs- und Ablaufzeiten. - Die Website prüft. Sie findet den öffentlichen Key, rekonstruiert die signierten Komponenten aus dem erhaltenen Request und prüft die Signatur. Wenn die Prüfung erfolgreich ist, wurde der Request vom Inhaber dieses Keys signiert und die abgedeckten Teile wurden nicht verändert.
Der Draft erlaubt es einer Website außerdem, eine Signatur anzufordern. Eine Origin kann einen Accept-Signature-Header, typischerweise mit einer Ablehnung, senden, um mitzuteilen, dass sie signierte Requests möchte.
Die Idee des Key-Verzeichnisses
Eine Signatur ist nur nützlich, wenn die Website den richtigen öffentlichen Key finden kann. Web Bot Auth beantwortet das mit einem Key-Verzeichnis.
Im aktuellen Working-Group-Draft fügt der Client einen Signature-Agent-Header hinzu, der eine HTTPS-URL enthält. Diese URL liefert ein Verzeichnis der öffentlichen Keys des Betreibers als JSON Web Key Set. Die Website ruft das Verzeichnis ab, wählt den Key aus, der zur Key-ID in der Signatur passt, und prüft. Der Draft definiert außerdem einen Well-Known-Pfad, /.well-known/http-message-signatures-directory, über den ein Betreiber sein Verzeichnis bereitstellen kann.
Die nützliche Idee für Produktteams ist, dass die URL zur Identität wird. Ein Agent-Betreiber wird darüber identifiziert, wo er seine Keys veröffentlicht, und damit wird die Signatur an eine Domain gebunden, die der Betreiber kontrolliert. Key-Rotation funktioniert, indem ein neuer Key zusammen mit dem alten veröffentlicht und der alte später entfernt wird.
Prüfende Websites müssen Verzeichnisse sorgfältig handhaben: nach den normalen HTTP-Regeln cachen, Größenlimits und Timeouts setzen und Abrufe von privaten Netzwerkadressen vermeiden. Das sind typische Engineering-Anforderungen, und genau deshalb bevorzugen viele Teams eine Komponente, die die Prüfung für sie übernimmt.
Was eine gültige Signatur belegt und was nicht
Das ist der wichtigste Abschnitt für alle, die eine Produktpolicy schreiben.
Eine gültige Signatur belegt:
- Der Request wurde vom Inhaber eines bestimmten privaten Keys signiert.
- Dieser Key wird unter einer Verzeichnis-URL veröffentlicht, die der Betreiber kontrolliert.
- Die signierten Teile des Requests wurden unterwegs nicht verändert, und die Signatur liegt innerhalb ihres Gültigkeitsfensters.
Eine gültige Signatur belegt nicht:
- Dass der Agent autorisiert ist, die Aktion auszuführen. Identifizierbarkeit ist keine Berechtigung. Siehe Agent-Autorisierung.
- Dass der Agent für eine bestimmte Person oder innerhalb der von dieser Person übertragenen Befugnis handelt. Siehe delegierte Autorität.
- Dass der Betreiber vertrauenswürdig ist oder dass der Agent sich korrekt verhalten wird. Reputation ist ausdrücklich nicht im Scope der Arbeitsgruppe.
- Irgendetwas über Requests, die nicht signiert sind. Unsignierter Traffic braucht weiterhin eine eigene Behandlung.
Behandeln Sie eine gültige Signatur als starken Nachweis dafür, wer einen Request gesendet hat, und lassen Sie dann Ihre eigene Zugriffskontrolle entscheiden, was dieser Absender tun darf.
Was Produktteams dazu tun sollten
Sie müssen nicht auf ein RFC warten, um zu planen. Signierter Agent-Traffic ist etwas, worauf Sie sich jetzt vorbereiten können, mit der Erwartung, dass sich einige Details des Drafts noch ändern können.
1. Messen, bevor Sie entscheiden
Finden Sie heraus, wie viel Ihres Traffics automatisiert ist, welche Routen Agenten nutzen und wie viel davon signiert ist. Beginnen Sie im Beobachtungsmodus, damit sich für Ihre Nutzer nichts ändert.
2. Evidenz von Policy trennen
Dokumentieren Sie getrennt, was die Evidenz sagt, verified, declared, inferred oder unknown, und was Sie daraus machen. So bleiben Policies lesbar und Sie können sie strenger oder lockerer machen, ohne die Instrumentierung neu aufzusetzen. Der Eintrag evidence basis erklärt die vier Ebenen.
3. Verified Agents einen besseren Pfad geben
Wo es sinnvoll ist, bieten Sie verified Agents strukturierte Inhalte oder einen agentenfreundlichen Flow an, statt Seiten, die für Menschen gebaut wurden. Der Leitfaden zu strukturierten Inhalten für KI-Agenten beschreibt die Muster.
4. Autorisierung in Ihrem Code belassen
Nutzen Sie die Signatur, um zu wissen, wer fragt. Nutzen Sie Ihre bestehenden Berechtigungen, Scopes und Bestätigungen, um zu entscheiden, was derjenige tun darf. Aktionen mit hoher Auswirkung können weiterhin eine Bestätigung durch einen Menschen erfordern, ganz gleich, wer den Request signiert hat. Siehe sensible Aktionen schützen, ohne Agenten zu blockieren.
5. Auf unsignierten und Unknown Traffic vorbereiten
Die Unterstützung für Signaturen variiert je nach Agent und Tool, daher sollten Sie eine Zeit lang mit einer Mischung aus signierten und unsignierten Requests rechnen. Legen Sie pro Route fest, was mit declared, inferred und Unknown Traffic passiert, statt sich für eine einzige Regel für die gesamte Website zu entscheiden. Der Leitfaden zu Unknown Traffic behandeln führt Sie durch das Vorgehen.
Wie Proof of Actor Web Bot Auth nutzt
Proof of Actor sagt Ihrer Anwendung bei jeder Interaktion, wer oder was handelt, Human, Human + AI, Agent oder Unknown, und nennt die Evidenzbasis. Web Bot Auth-Signaturen sind eine der stärksten Evidenzquellen.
Wenn ein Agent seinen Request mit HTTP Message Signatures signiert, prüft Proof of Actor die Signatur gegen den veröffentlichten Key des Betreibers. Wenn die Prüfung erfolgreich ist, erhält das Ergebnis eine verified-Basis, zusammen mit der Evidenz, die Ihr Team prüfen kann. Wenn ein Client sich nur in einem Header selbst benennt, ist das Ergebnis declared. Wenn die Schlussfolgerung auf Verhaltens- oder Kontextsignalen beruht, ist sie als inferred gekennzeichnet. Wenn die Evidenz nicht ausreicht, ist das Ergebnis Unknown.
Ihre Anwendung entscheidet, was mit diesem Kontext geschieht. Policies werden pro Route, pro Actor-Klasse und pro Basis geschrieben, mit Ergebnissen wie allow, adapt, challenge, review und rate-limit. Standardmäßig wird nichts durchgesetzt: Sie prüfen eine Policy gegen echten Traffic vorab und setzen sie Route für Route in Ihrem eigenen Code durch.
Founding-Teams können Evidenz über Node.js-Middleware, Next.js, eine Edge-Integration, einen Browser-Collector auf freigegebenen Seiten, die allgemeine HTTP API oder eine MCP server-Integration erfassen. Siehe Integrationen und den Leitfaden zu signierte Agent-Requests prüfen für die praktischen Schritte.
Proof of Actor folgt derselben Grenze wie der Standard: Eine verifizierte Signatur sagt Ihnen, welcher Key den Request signiert hat, nicht ob der Agent autorisiert ist. Die Autorisierung bleibt bei Ihnen. Die Seite Evidenz und Grenzen beschreibt genau, was jedes Ergebnis unterstützen kann und was nicht.
Jetzt starten
Proof of Actor befindet sich in der privaten Beta. Ausgewählte Founding-Developer-Teams können bis zu 12 Monate kostenlosen Zugang innerhalb vereinbarter Nutzungslimits erhalten, ohne automatische Abrechnung. Frühen Zugang beantragen und uns mitteilen, welche Routen Sie von signierten Agenten erwarten und was Sie mit ihnen tun möchten.