{"id":10639,"date":"2026-10-05T12:30:00","date_gmt":"2026-10-05T10:30:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10639"},"modified":"2026-09-25T09:45:52","modified_gmt":"2026-09-25T07:45:52","slug":"web-bot-auth-wie-agenten-anfragen-signiert-werden-und-was-die-signatur","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/cloud-ai-de\/web-bot-auth-wie-agenten-anfragen-signiert-werden-und-was-die-signatur\/","title":{"rendered":"Web Bot Auth: Wie Agenten-Anfragen signiert werden und was die Signatur belegt"},"content":{"rendered":"

Ein agentischer Browser sieht in einem Analysebericht aus wie ein Mensch, weil er einer echten Browsermaschine gleicht. Die Frage, wer da eigentlich anfragt, l\u00e4sst sich am Verhalten nur sch\u00e4tzen – oder von der Gegenseite beantworten, indem sie unterschreibt.<\/p>\n

Genau das ist Web Bot Auth. Der Mechanismus ist kurz, die Kryptografie unspektakul\u00e4r, und die interessanteste Aussage dar\u00fcber ist, was er ausdr\u00fccklich nicht belegt.<\/p>\n

\n\"Ein
F\u00fcnf Kanten sind durchgezogen und belegbar. Die sechste ist gestrichelt, weil sie nicht existiert – und sie ist die, die in Gespr\u00e4chen \u00fcber verifizierte Agenten meist gemeint ist.<\/figcaption><\/figure>\n

Was auf der Leitung liegt<\/h2>\n

Die Grundlage ist RFC 9421, die HTTP-Nachrichtensignaturen. Der Betreiber eines Agenten erzeugt ein Ed25519-Schl\u00fcsselpaar, hinterlegt den \u00f6ffentlichen Teil als JSON-Schl\u00fcsselsatz unter einem festen Pfad auf einer Domain, die er kontrolliert, und unterschreibt jede ausgehende Anfrage. Drei Header tragen das Ergebnis.<\/p>\n

Signature-Agent: \"https:\/\/beispiel-agent.de\"\nSignature-Input: sig=(\"@authority\" \"signature-agent\");\n                 created=1700000000;\n                 expires=1700011111;\n                 keyid=\"poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U\";\n                 tag=\"web-bot-auth\"\nSignature: sig=jdq0SqOwHdyHr9+r5jw3iYZH6aNGKijYp\/EstF4RQTQdi5N5YYKrD+mCT1HA1nZD\u2026\n\n  Verzeichnis   \/.well-known\/http-message-signatures-directory\n  Inhaltstyp    application\/http-message-signatures-directory+json\n\n  Die Klammer hinter sig= nennt, was unterschrieben ist. Hier sind\n  es zwei Bestandteile: der Zielhost und die Verzeichnisangabe.<\/code><\/pre>\n
Der Pr\u00fcfer liest Signature-Agent<\/code>, holt von dort das Verzeichnis, sucht darin den \u00fcber keyid<\/code> benannten Schl\u00fcssel, baut die Signaturbasis aus den in Signature-Input<\/code> benannten Bestandteilen nach und rechnet die Unterschrift nach.<\/p>\n
Was die Unterschrift belegt<\/h2>\n
Zwei Dinge, und beide sind stark. Erstens: Wer sie erzeugt hat, besitzt den privaten Schl\u00fcssel zu einem \u00f6ffentlichen, der unter einer bestimmten Domain ver\u00f6ffentlicht ist. Zweitens: Er kontrolliert diese Domain, denn sonst k\u00f6nnte er dort nichts hinterlegen. Zusammen ergibt das eine \u00fcberpr\u00fcfbare Herkunft, und die ist mehr, als eine Kennung im User-Agent je war.<\/p>\n
Dazu kommt der Ersatz f\u00fcr einen Wiedereinspielungsschutz: expires<\/code> begrenzt die G\u00fcltigkeit, und eine Unterschrift nach diesem Zeitpunkt wird verworfen. Eine mitgeschnittene Anfrage l\u00e4sst sich damit nicht beliebig lange wiederverwenden.<\/p>\n
Was sie nicht belegt<\/h2>\n
Die Unterschrift deckt benannte Bestandteile ab, im ver\u00f6ffentlichten Beispiel den Zielhost und die Verzeichnisangabe. Den Rumpf der Anfrage deckt sie nicht ab, und \u00fcber die Absicht sagt sie nichts. Sie belegt Identit\u00e4t, nicht Verhalten.<\/p>\n
Damit ist eine g\u00fcltige Unterschrift keine Erlaubnis. Ein sauber unterschriebener Agent kann denselben Inhalt abgreifen wie ein unsignierter, nur eben nachweisbar. Der Gewinn liegt nicht in der Abwehr, sondern in der Zurechenbarkeit: Wer wei\u00df, welcher Betreiber angefragt hat, kann eine Regel je Betreiber setzen – und im Streitfall belegen, wer da war.<\/p>\n
Wie sich das pr\u00fcfen l\u00e4sst<\/h2>\n
Die Pr\u00fcfung ist \u00fcberschaubar und lohnt sich als \u00dcbung, weil sie die Grenzen des Verfahrens unmittelbar zeigt. Vier Schritte: Signature-Agent<\/code> lesen und auf eine erwartete Domain pr\u00fcfen; das Verzeichnis unter dem festen Pfad holen und den Schl\u00fcssel zu keyid<\/code> heraussuchen; die Signaturbasis aus den in Signature-Input<\/code> genannten Bestandteilen in der genannten Reihenfolge zusammensetzen; die Ed25519-Pr\u00fcfung rechnen und expires<\/code> gegen die eigene Uhr halten.<\/p>\n
Der dritte Schritt ist der, an dem eigene Umsetzungen scheitern, weil die Signaturbasis zeichengenau stimmen muss. Wer sie einmal von Hand gebaut hat, versteht danach auch, warum der Rumpf nicht mitunterschrieben ist: Er m\u00fcsste daf\u00fcr vollst\u00e4ndig gepuffert werden, bevor die erste Pr\u00fcfung beginnt.<\/p>\n
Der Stand, ehrlich benannt<\/h2>\n
Beide Spezifikationen sind Internet-Drafts – die Architektur und das Verzeichnis, letzteres in der f\u00fcnften Fassung. Eine IETF-Arbeitsgruppe befasst sich seit Anfang 2026 damit, ein verabschiedetes Dokument gibt es nicht, und Entw\u00fcrfe \u00e4ndern Header-Namen und Pfade durchaus noch.<\/p>\n
Gleichzeitig pr\u00fcfen mehrere gro\u00dfe Netz- und Sicherheitsanbieter diese Unterschriften bereits im Wirkbetrieb. F\u00fcr einen einzelnen Auftritt hei\u00dft das: verstehen ja, darauf verlassen noch nicht. Und der Satz, der beim Lesen der Ank\u00fcndigungen mitzudenken ist, steht im Bild als gestrichelte Kante – eine Unterschrift beweist, wer anfragt, und niemals, was er vorhat.<\/p>\n
\n
Fragen und Antworten<\/h2>\n
Kann jemand den Header Signature-Agent einfach mit der Domain eines bekannten Betreibers f\u00fcllen?<\/h3>\n
Schreiben l\u00e4sst er sich, nur besteht er die Pr\u00fcfung nicht. Die Pr\u00fcfung holt den Schl\u00fcssel aus dem Verzeichnis genau dieser Domain, und ohne den passenden privaten Schl\u00fcssel geht die Ed25519-Pr\u00fcfung nicht auf. Weil Signature-Agent selbst zu den unterschriebenen Bestandteilen geh\u00f6rt, l\u00e4sst er sich auch nicht nachtr\u00e4glich gegen eine andere Domain tauschen.<\/p>\n
L\u00e4sst sich eine mitgeschnittene, g\u00fcltige Unterschrift vor Ablauf von expires erneut verwenden?<\/h3>\n
Innerhalb der Frist grunds\u00e4tzlich ja. expires ist nur ein Ersatz f\u00fcr einen Wiedereinspielungsschutz: Die Angabe begrenzt, wie lange eine Unterschrift gilt, verhindert aber nicht, dass dieselbe Unterschrift in dieser Zeit mehrmals vorgelegt wird. Im Beispiel liegen zwischen created und expires 11.111 Sekunden, also gut drei Stunden.<\/p>\n
Hinzu kommt, was unterschrieben ist. Im Beispiel sind es nur der Zielhost und die Verzeichnisangabe, weder Pfad noch Methode noch Rumpf. Wer die drei Header einer solchen Anfrage kennt, kann sie in dieser Zeit also auch an eine andere Adresse desselben Hosts h\u00e4ngen, und die Pr\u00fcfung geht trotzdem auf.<\/p>\n
Praktisch setzt das voraus, dass die Header \u00fcberhaupt in fremde H\u00e4nde geraten. \u00dcber HTTPS sind sie auf der Leitung verschl\u00fcsselt, sichtbar sind sie aber \u00fcberall dort, wo TLS endet, etwa bei einem CDN oder einem Reverse Proxy, und in Protokollen, die Header mitschreiben. F\u00fcr eine Regel je Betreiber hei\u00dft das: Eine g\u00fcltige Unterschrift belegt, dass der Betreiber diese Header erzeugt hat, nicht zwingend, dass er genau diese Anfrage geschickt hat.<\/p>\n
Hilft Web Bot Auth dabei, Agenten aus einem Analysebericht herauszurechnen?<\/h3>\n
Nur dort, wo die Header der Anfrage ankommen. Die Unterschrift steht in den Headern der HTTP-Anfrage, und die sieht der Server, ein vorgeschaltetes CDN oder das Server-Log. Ein Mess-Tag, das als JavaScript im Browser l\u00e4uft, kann die Header der Anfrage nicht lesen, mit der seine eigene Seite geladen wurde; ein agentischer Browser z\u00e4hlt dort deshalb weiterhin wie ein Mensch.<\/p>\n
Wer die Unterscheidung im Bericht haben will, muss sie am Server treffen: die Pr\u00fcfung dort vornehmen und ihr Ergebnis weitergeben, etwa als Kennzeichen, das die Seite an das Tag \u00fcbergibt, oder durch eine Messung auf dem Server selbst. Das setzt voraus, dass der Agent \u00fcberhaupt unterschreibt; Agenten ohne Unterschrift bleiben so unsichtbar wie zuvor.<\/p>\n<\/div>\n
\n
Quellen<\/h2>\n