Google testet Web Bot Auth – was das für kryptografische Bot-Verifikation bedeutet

Warum User-Agent-Strings nie ausreichend waren

Jeder HTTP-Client kann sein User-Agent-Feld auf „Googlebot", „GPTBot" oder eine beliebige andere Crawler-Identität setzen. Es gibt keine im HTTP-Standard verankerte Verifikationsschicht. Web-Server, die die Identität eines Crawlers bestätigen wollen, haben derzeit zwei Optionen: Reverse-DNS-Lookups — langsam, unvollständig und im großen Maßstab teuer — oder IP-Allowlisten, die spröde sind und bei jeder Änderung der Crawler-Infrastruktur manuell gepflegt werden müssen.

Keiner dieser Ansätze skaliert in einem Ökosystem, in dem gleichzeitig Hunderte eigenständiger KI-Crawler existieren, Identitätsvortäuschung reale kommerzielle Konsequenzen hat und das Volumen automatisierter Anfragen den menschlichen Traffic zunehmend übersteigt. Das Problem ist struktureller Natur, nicht operativer. User-Agent-Strings wurden als informationelle Hinweise entworfen, nicht als Authentifizierungstoken. Ihr Einsatz als Identitätsschicht ist ein architektonischer Kategorienfehler.

Web Bot Auth: Anfragen signieren statt Identität deklarieren

Googles experimenteller Standard baut auf RFC 9421 (HTTP Message Signatures) auf. Wenn ein konformer Bot eine Anfrage stellt, signiert er die HTTP-Nachricht mit einem privaten Schlüssel. Der zugehörige öffentliche Schlüssel wird in einem JWKS-Verzeichnis an einem Well-Known-Endpoint veröffentlicht — strukturell analog zu OAuths /.well-known/jwks.json-Muster. Der Signature-Agent-Header in der Anfrage identifiziert, welches Schlüsselpaar verwendet wurde.

Die Verifikation ist deterministisch: Der empfangende Server fragt den JWKS-Endpoint ab, ruft den öffentlichen Schlüssel ab und prüft die Signatur gegen die Anfrage. Kein Reverse-DNS-Lookup. Keine IP-Allowliste. Der Bot besitzt entweder den zum veröffentlichten JWKS-Eintrag passenden privaten Schlüssel oder nicht. Der Identitätsnachweis ist entweder kryptografisch gültig oder er ist es nicht. Es gibt keine probabilistische Grauzone.

Dasselbe Sicherheitsmodell, in umgekehrter Richtung angewendet

Web Bot Auth fragt: Wie kann ein Server verifizieren, dass ein Crawler der ist, der er vorgibt zu sein? Das Sovereign Validation Protocol adressiert die inverse Frage: Wie kann ein Crawler verifizieren, dass eine Infrastruktur zu der Entität gehört, die sie zu repräsentieren behauptet?

Beide Antworten sind strukturell identisch. Veröffentliche ein kryptografisches Schlüsselpaar an einem auffindba­ren Endpunkt. Signiere Identitätsbehauptungen mit dem privaten Schlüssel. Verifiziere mit dem öffentlichen Schlüssel. Kein vertrauenswürdiger Dritter erforderlich. Kein probabilistisches Schlussfolgern. Die Verifikation gelingt oder sie gelingt nicht.

SOVP implementiert dies über Ed25519-Signaturen, am DNS-Layer verankert. Der öffentliche Schlüssel wird als DNS-TXT-Eintrag veröffentlicht. Jeder Agent, der die Infrastruktur abfragt, kann den Identitätsnachweis unabhängig verifizieren, indem er den DNS-Eintrag auflöst und die Signatur prüft. Das technische Substrat unterscheidet sich von JWKS — DNS statt HTTP — aber die Sicherheitsarchitektur ist identisch: kryptografischer Beweis statt Selbstdeklaration.

"Zwei Protokolle, zwei Richtungen, ein Modell: die Deklaration durch einen Beweis ersetzen, den die andere Seite ohne Vertrauen verifizieren kann."

Das ist kein Zufall. Es spiegelt eine strukturelle Anforderung jedes Systems wider, in dem automatisierte Einheiten im großen Maßstab ohne menschliche Vermittler interagieren. Wenn keine Seite Identitätsfragen an einen menschlichen Reviewer delegieren kann, ist Mathematik der einzige zuverlässige Mechanismus. Googles Vorschlag und SOVPs bestehende Implementierung gelangen unabhängig voneinander zur selben Schlussfolgerung.

Ausblick für Infrastrukturbetreiber

Wenn Web Bot Auth Adoption erreicht, wird das Bot-Interaktionsmodell auf beiden Seiten kryptografisch verifizierbar. SOVPBot/1.0 — der Infrastruktur-Scanner hinter SOVP-Audits — ist architektonisch darauf vorbereitet, einen JWKS-Endpoint unter /.well-known/ zu veröffentlichen, der mit diesem Standard konform ist. Die Implementierung des Signature-Agent-Headers würde es Web-Servern ermöglichen, SOVPBot-Anfragen unabhängig zu verifizieren, anstatt auf User-Agent-String-Matching angewiesen zu sein.

Breiter betrachtet: Der Vorschlag ist ein Richtungssignal. Kryptografische Identität für automatisierte Systeme ist keine Randbedingung spezialisierter Protokolle. Es ist die Richtung, in die sich die Infrastrukturschicht ökosystemweit bewegt. Die Frage für Infrastrukturbetreiber lautet nicht, ob dieser Übergang stattfinden wird — sondern ob die eigene Infrastruktur darauf ausgelegt ist, daran teilzunehmen.

Für die Protokollspezifikation, die Infrastruktur-Identität auf der eingehenden Seite regelt — wie Ihre Infrastruktur gegenüber abfragenden Agenten ihre Identität beweist — siehe das Sovereign Validation Protocol. Zur strukturellen Lücke zwischen deklarativen Dateien und kryptografischem Beweis: llms.txt ist eine Deklaration, kein Beweis.