Web Bot Auth: Identität für KI-Agenten

Im Internet des Jahres 2026 übersteigt das Volumen des maschinellen Traffics den menschlichen Datenverkehr bei Weitem. Autonome Software-Agenten, RAG-Scraper, Research-Bots und traditionelle Suchmaschinen-Crawler steuern tagtäglich Milliarden URLs an. Für Webmaster und IT-Sicherheitsverantwortliche entsteht daraus ein existenzielles Dilemma: Wie unterscheidet man legitime, geschäftskritische KI-Systeme (die Markenbekanntheit und Traffic bringen) von aggressiven, ressourcenfressenden Datendieben?

Jahrzehntelang verließ sich die Web-Industrie auf das Prinzip des guten Glaubens: Ein Crawler schickte den Header User-Agent: Googlebot/2.1 mit, und der Webserver vertraute darauf. Im Zeitalter massenhafter LLM-Scraper ist dieses Vorgehen grob fahrlässig. Jeder einfache Python-Crawl kann diesen Header mit einer Zeile Code fälschen.

Die zukunftssichere Antwort der Internet Engineering Task Force (IETF) und von Infrastruktur-Riesen wie Cloudflare und Google lautet Web Bot Auth.

Jörg Zimmer

Senior SEO & AI Search Consultant

„AI generierte Website zu 100% mit Agenten erstellt. Muss ich da was kennzeichnen?“

Was ist Web Bot Auth?

Web Bot Auth ist ein kryptografisches Authentifizierungs-Framework für automatisierte HTTP-Clients. Anstatt bloße Behauptungen im Header aufzustellen, signiert der anfragende Bot wesentliche Bestandteile seines HTTP-Requests mit einem privaten kryptografischen Schlüssel (typischerweise Ed25519).

Die technische Grundlage bildet der Standard RFC 9421 (HTTP Message Signatures). Beim Eintreffen des Requests liest der Webserver oder die Edge-WAF (Web Application Firewall) die Signatur aus und gleicht sie mit dem öffentlich publizierten Schlüsselbund (JSON Web Key Set / JWKS) des jeweiligen Bot-Betreibers ab.

Stimmt die mathematische Signatur, ist zweifelsfrei bewiesen:

1. Authentizität: Der Request stammt tatsächlich von der deklarierten Organisation (z. B. Google, OpenAI oder Anthropic).
2. Integrität: Weder die Ziel-URL noch kritische Header wurden während der Übertragung manipuliert.

Das Ende von Forward-Confirmed Reverse DNS (FCrDNS)

Lange Zeit galt das sogenannte Forward-Confirmed Reverse DNS (FCrDNS) als Goldstandard der Bot-Verifizierung. Bei diesem dreistufigen Verfahren ermittelt der Server über einen PTR-Lookup den Hostnamen der anfragenden IP-Adresse und prüft anschließend über einen A-Record-Lookup, ob der Hostname wieder auf dieselbe IP auflöst.

In der modernen Multi-Cloud- und Kubernetes-Welt stößt FCrDNS an unüberwindbare Grenzen:

• Latenz: Zusätzliche DNS-Lookups bei jedem einzelnen Bot-Request erzeugen erhebliche Latenzzeiten und belasten Resolver-Infrastrukturen.
• Dynamische IP-Pools: Große KI-Cluster skalieren sekündlich über tausende kurzlebige Cloud-IPs, deren PTR-Records oft nicht synchronisiert sind.
• Komplexität: Administratoren müssen fehleranfällige IP-Allowlisten pflegen.

Web Bot Auth löst all diese Probleme: Die Signatur reist direkt im HTTP-Request mit. Ein DNS-Lookup entfällt komplett, da der Server den öffentlichen JWKS-Schlüsselbund global cachen kann.

Vergleichstabelle: User-Agent vs. FCrDNS vs. Web Bot Auth (RFC 9421)

Die Anatomie eines RFC 9421 Bot-Requests

Ein standardkonformer Request unter Web Bot Auth enthält spezifische Signatur-Header:

GET /artikel/kuenstliche-intelligenz HTTP/1.1
Host: teleschmie.de
User-Agent: Mozilla/5.0 (compatible; CertifiedAiBot/1.0; +https://aibot.example/info)
Date: Fri, 04 Sep 2026 01:20:00 GMT
Signature-Input: sig1=("@method" "@target-uri" "@authority" "date");keyid="aibot-key-2026-01";alg="ed25519";created=1788475200
Signature: sig1=:K8z...geheime_kryptografische_signatur_bytes...=:
Accept: text/html, text/markdown

Die Validierung läuft in drei Schritten ab:

1. Der Server extrahiert die deklarierten Komponenten (@method, @target-uri, @authority, date) und setzt den Signatur-Basistext deterministisch zusammen.
2. Er ruft anhand der keyid den öffentlichen Schlüssel aus dem Zwischenspeicher des deklarierten JWKS ab.
3. Die Signatur wird mathematisch verifiziert. Schlägt die Prüfung fehl, wird die Anfrage mit HTTP 403 Forbidden oder HTTP 401 Unauthorized abgewiesen.

Universelles Node.js-Beispiel: Signatur-Validierung auf Server-Ebene

Das folgende neutrale Skript veranschaulicht die serverseitige Verifizierung einer HTTP-Signatur mit Standard-Kryptografie:

// verify-bot-signature.mjs - Universelle RFC 9421 Validierung
import crypto from 'crypto';

/**
 * Überprüft eine Ed25519 HTTP Message Signature.
 * @param {string} signatureBase - Der standardisierte Komponenten-String
 * @param {string} signatureBase64 - Der empfangene Signatur-Header
 * @param {string} publicKeyPem - Der öffentliche Schlüssel des Bot-Betreibers
 */
export function verifyBotRequest(signatureBase, signatureBase64, publicKeyPem) {
  try {
    const signatureBuffer = Buffer.from(signatureBase64, 'base64');
    const isVerified = crypto.verify(
      null,
      Buffer.from(signatureBase, 'utf-8'),
      publicKeyPem,
      signatureBuffer
    );
    return isVerified;
  } catch (error) {
    console.error('Kryptografischer Validierungsfehler:', error.message);
    return false;
  }
}

// Beispiel-Aufruf (neutrales Setup)
const sampleSignatureBase = '"@method": GET\n"@target-uri": https://teleschmie.de/\n"date": Fri, 04 Sep 2026 01:20:00 GMT';
console.log('Validierungs-Funktion für Web Bot Auth bereit.');

Anatomie der HTTP-Signatur-Header nach RFC 9421

Für die praktische Umsetzung im Proxy oder Application Gateway müssen drei zentrale Header präzise deklariert und ausgewertet werden:

• Signature-Input: Definiert die abgedeckten Header-Komponenten, den Algorithmus (sig1=("@method" "@target-uri" "date");alg="ed25519"), den Erstellungszeitpunkt (created) und den Schlüssel-Identifikator (keyid).
• Signature: Beinhaltet den Base64-kodierten Signatur-String (sig1=:dGhpcyBpcyBhIHZhbGlk...:), der vom kryptografischen Verifizierer geprüft wird.
• Content-Digest (optional bei Payloads): Sichert POST- oder PUT-Anfragen (etwa bei A2A-Agenten-Transaktionen) gegen Manipulationen im Request-Body durch SHA-256 oder SHA-512 Hashwerte ab.

Im Gegensatz zu Legacy-Methoden wie Reverse DNS (FCrDNS), die pro Request bis zu zwei langsame DNS-Lookups erforderten und moderne Anycast-IP-Pools von Cloud-Anbietern überforderten, erfolgt die Auswertung von RFC 9421 lokal auf Serverebene innerhalb von wenigen Mikrosekunden.

Die 3 häufigsten Fehler bei der Bot-Verifizierung

In der Praxis führen Fehlkonfigurationen oft zur unbeabsichtigten Selbstsperre oder zu massiven Performance-Einbußen:

1. Reine User-Agent-Sperren ohne Signaturprüfung: Webmaster blockieren unbedarft User-Agents, die legitime KI-Crawler imitieren, während sich bösartige Scraper schlicht als gewöhnlicher Google Chrome Desktop-Browser tarnen und ungehindert scrapen.
2. Fehlendes Caching der JWKS-Schlüssel: Wer bei jeder eingehenden HTTP-Signatur einen externen HTTP-Request zum Schlüssel-Endpoint des Bot-Anbieters schickt, erzeugt einen massiven Server-Engpass. Öffentliche Schlüssel müssen stets serverseitig zwischengespeichert werden.
3. Blockieren legitimer RAG-Bots mit Replay-Attack-Filtern: Strikte Timestamp-Validierungen können fehlschlagen, wenn Server-Uhren nicht exakt via NTP synchronisiert sind. Liegt der created-Timestamp wenige Sekunden in der Zukunft, verwerfen übereifrige Firewalls den legitimen Bot.

Strategische Bedeutung für Agent Readiness

Web Bot Auth bildet das sicherheitstechnische Rückgrat moderner Agent Readiness. Erst wenn zweifelsfrei feststeht, welche Identität hinter einer Maschinen-Anfrage steht, können nachgelagerte Schnittstellen wie RFC 8288 Link-Header, DNS-AID und auth.md risikolos geöffnet werden. Im Zusammenspiel mit dem A2A Protocol entsteht ein transparentes Ökosystem, in dem verifizierte Agenten autonom geschäftliche Mehrwerte stiften, ohne die IT-Infrastruktur zu gefährden.

Welche Analysetools Ihnen dabei helfen, KI-Bot-Aktivitäten transparent auszuwerten, erfahren Sie in unserem Überblick über die Top 9 AI Visibility Tools. Die Kosten für Edge-Sicherheit und Bot-Management lassen sich präzise im SEO-Tool Kostenrechner kalkulieren.