Wie Websites KI-Browser-Agenten 2026 erkennen – und Web Bot Auth

Stand Oktober 2026 erkennen Websites KI-Browser-Agenten auf drei verschiedenen Wegen, einen pro Agententyp. Deklarierte Crawler und nutzerausgelöste Fetcher fallen über User-Agent-Strings, veröffentlichte IP-Listen und zunehmend über kryptografische Signaturen auf. Agentische Browser, die echtes Chromium steuern, sind der schwierigere Fall. Sie tragen einen ganz normalen Chrome-Fingerprint und werden daher vor allem an ihrem Verhalten erkannt: ein Cursor, der springt, statt sich zu bewegen, Text, der eingefügt statt getippt wird, Scrollen in einzelnen Sprüngen. Web Bot Auth ist die Opt-in-Lösung. Der Agent signiert seine Requests, damit eine Website ihn erkennen kann, ohne raten zu müssen.

Wie Websites KI-Browser-Agenten erkennen: drei Agententypen, drei Methoden

„KI-Bot“ ist keine einheitliche Kategorie. Wer KI-Browser-Agenten erkennen will, muss zuerst klären, welcher Typ gerade vor ihm steht, denn jeder Typ identifiziert sich anders und wird über ein anderes Signal erwischt.

1. Trainings- und Such-Crawler. Das sind Fetcher, die Seiten massenhaft einsammeln, ohne dass ein Nutzer auf das Ergebnis wartet: GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot, PerplexityBot. Sie deklarieren ein User-Agent-Token, veröffentlichen IP-Bereiche und halten sich laut Aussage ihrer Anbieter an robots.txt.
2. Nutzerausgelöste Fetcher. Eine Person stellt einem Assistenten eine Frage, und er ruft genau in diesem Moment eine Seite ab: ChatGPT-User, Claude-User, Perplexity-User, Google-Agent. Auch sie geben sich zu erkennen, doch mehrere Anbieter erklären, dass robots.txt für sie unter Umständen nicht gilt, weil ein Mensch den Request ausgelöst hat.
3. Agentische Browser. Eine echte Chromium-Instanz klickt, tippt und scrollt für den Nutzer, entweder auf dessen eigenem Rechner (Perplexity Comet, die Erweiterung Claude in Chrome, das Open-Source-Projekt browser-use) oder in der Cloud des Anbieters (ChatGPT agent, Manus). Sie sehen aus wie Browser, weil sie Browser sind.

Die Taxonomie von Cloudflare vom 1. Juli 2026 teilt denselben Traffic nach Verhalten ein: Search, Agent (handelt „in Echtzeit im Auftrag einer Person“) und Training. Der Agent-Bereich umfasst ausdrücklich sowohl „Chat-Fetch-Bots (z. B. ChatGPT-User) als auch Browser-Use-Agenten (z. B. Gemini oder Claude, die Chrome steuern)“. Gruppe 2 und Gruppe 3 teilen sich also eine Policy-Kategorie, ihre Erkennung erfordert aber völlig unterschiedliche Methoden.

Die deklarierten Agenten: User-Agent-Tokens und veröffentlichte IPs (geprüft im Oktober 2026)

Für die Gruppen 1 und 2 ist Erkennung vor allem eine Frage der Dokumentation. Jeder große Anbieter veröffentlicht seine Tokens und eine IP-Liste, gegen die man Requests prüfen kann. Ein UA-Treffer plus ein IP-Treffer ist verlässlich. Ein UA-Treffer allein ist es nicht, denn den String kann jeder senden.

Deklarationen funktionieren nur, solange sich die Anbieter daran halten. Im August 2025 berichtete Cloudflare, dass es, nachdem Websites die deklarierten Bots von Perplexity gesperrt hatten, nicht deklarierte Requests mit einem generischen Chrome-auf-macOS-User-Agent beobachtete, die von IPs außerhalb der veröffentlichten Perplexity-Bereiche und aus wechselnden ASNs kamen. Laut Cloudflare wurde dieser Traffic mit „einer Kombination aus Machine Learning und Netzwerksignalen“ identifiziert, und Perplexity flog von der Liste der verifizierten Bots. Perplexity bestritt die Darstellung. Wer auch immer recht hatte: Für Website-Betreiber heißt das, dass UA- und IP-Regeln ehrlichen Traffic erfassen. Traffic, der beschlossen hat, sich nicht zu erkennen zu geben, erfassen sie nicht.

Warum agentische Browser an UA- und IP-Regeln vorbeikommen

Ein agentischer Browser auf dem Laptop eines Nutzers sendet dessen Chrome-User-Agent, den TLS- und HTTP/2-Fingerprint von Chrome und die private IP des Nutzers. Im Request gibt es schlicht nichts, worauf eine UA- oder IP-Regel anspringen könnte. Cloud-gehostete Agenten sind nur teilweise leichter zu erkennen: Ihre IPs gehören Cloud-Anbietern, aber das gilt auch für VPN-Nutzer, Firmen-Proxys und die Automatisierungstools, die Sie ohnehin zulassen.

Das FP-Agent-Paper (Wang, Shafiq und Vekaria, arXiv 2605.01247, Mai 2026) hat das direkt gemessen. Es schickte sieben Agenten (den Atlas-Browser und ChatGPT agent von OpenAI, Claude for Chrome, Perplexity Comet, Manus, Browser Use und Skyvern) parallel zu menschlichen Teilnehmern durch Aufgaben wie Flugbuchung, Online-Shopping und Forenbeiträge. In der Fallstudie zu Cloudflare wurde „nur Manus von Cloudflare vollständig blockiert, während die anderen sechs Browsing-Agenten die Aufgaben erfolgreich abschließen“. Browser-Fingerprints allein erreichten bei der Unterscheidung der Klassen einen F1-Wert von 0,7969. Die Autoren stellten fest, dass die Fingerprints „mit ihrer zugrunde liegenden Ausführungsumgebung korrelieren“: Lokale Agenten übernehmen einfach die des Host-Rechners.

Eine Korrektur für alle, die mit Material aus 2025 arbeiten: OpenAI hat den Atlas-Browser am 9. August 2026 eingestellt und das Agenten-Browsing in seine Desktop-App integriert. Die Atlas-Ergebnisse des Papers bleiben trotzdem relevant, weil sie ein Muster lokaler Agenten beschreiben, das auch andere Produkte zeigen.

Signale, die agentische Browser weiterhin verraten

Bei agentischen Browsern verrät das Verhalten weit mehr als die Umgebung. Der FP-Agent-Klassifikator kombinierte Verhaltens- und Browser-Merkmale und erreichte auf dem Datensatz des Papers einen F1-Wert von 1,0000. Das ist ein Laborergebnis mit sieben Agenten und drei Aufgaben, keine Erkennungsrate aus dem Produktivbetrieb, aber die Richtung deckt sich mit dem, was Anbieter berichten.

Cursor-Geometrie und Eingaberhythmus

Das klarste Signal im Paper: „Browsing-Agenten zeigen keinerlei Mausbewegungen, sondern teleportieren direkt zur Klickposition.“ Ebenso markant ist das Tippen. Atlas, ChatGPT agent und Comet fügten Text ein, und das Strg+V von ChatGPT agent ergab „hohe Haltelatenzen … mit durchschnittlich 66,58 ms“. Browser Use, Skyvern und Manus tippten tatsächlich Tastenanschläge, mit mittleren Latenzen zwischen zwei Tasten von 5,31 ms, 9,52 ms und 1,39 ms, während Menschen „deutlich höhere Latenzen zwischen den Tasten … zusammen mit wesentlich größerer Varianz“ zeigten. Scrollen erschien als „diskrete Sprünge“ statt als kontinuierliche Mausradbewegung.

Precursor von Cloudflare (am 13. Juli 2026 für Enterprise Bot Management angekündigt, bis zur allgemeinen Verfügbarkeit im Laufe des Jahres kostenlos im Rollout) ist eine Produktivversion derselben Idee. Es injiziert clientseitiges JavaScript, das „Zeigerbewegungen, Tastaturaktivität, Fokuswechsel und Sichtbarkeit“ erfasst und pro Session aufsummiert, sodass ein Bot seine Verhaltenshistorie nicht durch Neuladen der Seite oder eine neue Challenge zurücksetzen kann. Die Prämisse: „Was sich weiterhin schwer nachahmen lässt, ist konsistentes menschliches Verhalten über die Zeit.“

Automatisierungs- und Erweiterungsartefakte

Manche Agenten hinterlassen Spuren in der Seite selbst. Die Analyse der Claude-Chrome-Erweiterung von CHEQ aus dem Februar 2026 ergab, dass sie die Seite über die chrome.debugger-API steuert, sodass ihre synthetischen Klicks als vertrauenswürdige Events gelten. Solange sie aktiv ist, injiziert sie allerdings DOM-Elemente mit IDs wie claude-agent-stop-container und claude-agent-animation-styles, und das Style-Element bleibt oft auch nach dem Ende des Agenten erhalten. Die Untersuchung von HUMAN Security zu Atlas und Comet berichtet ebenfalls von DOM-Artefakten der internen Comet-Erweiterung und hält fest, dass Comet „kein verifizierbares Identitätssignal pro Request liefert“.

Bauen Sie keine Strategie auf einzelnen Artefakten auf. Castle hat dokumentiert, wie ein weit verbreiteter CDP-Erkennungstrick (ein Getter auf Error.stack, der auslöst, wenn ein Automatisierungsclient die Runtime-Domain aktiviert hat) nach V8-Änderungen im Mai 2025 stillschweigend nicht mehr funktionierte. Ein Anbieter kann eine DOM-ID mit einem einzigen Release umbenennen. Behandeln Sie Artefakte als unterstützende Indizien, die ein Verhaltensmodell gewichtet, niemals als alleiniges Urteil.

Konsistenz der Umgebung und Egress

Cloud-gehostete Agenten verraten mehr darüber, wo sie laufen. Im Paper meldete ChatGPT agent abwechselnd die Plattformen „Linux x86_64 und MacIntel“. Ein von Simon Willison veröffentlichter mitgeschnittener Request zeigt dasselbe: einen Chrome-User-Agent für macOS, gesendet mit Sec-Ch-Ua-Platform: "Linux". Manus zeigte ein festes „Linux x86_64“ mit „4 GB RAM und 6 CPU-Kernen“. Eine Diskrepanz zwischen UA und Client Hints plus ein Cloud-ASN ist für sich genommen kein Beweis, zusammen aber ein starkes Indiz. Unser Erklärartikel zu Browser-Fingerprinting zeigt, wie solche Konsistenzprüfungen aufgebaut sind.

Web Bot Auth: signierte statt erratene Agenten

Mit Web Bot Auth kann ein Agent nachweisen, wer ihn betreibt. Er signiert jeden Request mit HTTP Message Signatures (RFC 9421) und veröffentlicht seine öffentlichen Schlüssel unter einer Well-known-URL, sodass eine Website den Betreiber kryptografisch prüfen kann, statt ihn aus UA, IP oder Verhalten abzuleiten. Die Arbeit bei der IETF ist noch ein Entwurf. Die Arbeitsgruppe webbotauth hat ihr Protokolldokument als draft-ietf-webbotauth-httpsig-protocol übernommen (Revision -00 vom 1. September 2026, Autoren von Cloudflare und Google). Produktive Deployments sind dem Standard bereits voraus.

Ein echter signierter Request, entschlüsselt

Hier die Signatur-Header aus dem ChatGPT-agent-Request, den Simon Willison im August 2025 mitgeschnitten hat (die Nonce ist hier gekürzt):

Signature-Agent: "https://chatgpt.com"
Signature-Input: sig1=("@authority" "@method" "@path" "signature-agent");created=1754340838;keyid="otMqcjr17mGyruktGvJU8oojQTSMHlVm7uO-lrcqbdg";expires=1754344438;nonce="_8jbGwfL…";tag="web-bot-auth";alg="ed25519"
Signature: sig1=:…:

• Signature-Agent nennt, wer für den Request bürgt. Der Prüfer ruft https://chatgpt.com/.well-known/http-message-signatures-directory ab, um die Schlüssel zu erhalten.
• Die abgedeckten Komponenten (@authority, @method, @path, signature-agent) binden die Signatur an diesen Host, diese Methode und diesen Pfad. Eine auf einer Website abgegriffene Signatur lässt sich nicht gegen eine andere wiederverwenden.
• expires − created = 3600: Die Signatur ist eine Stunde gültig, und mit der nonce kann ein Prüfer exakte Wiederholungen innerhalb dieses Zeitfensters ablehnen.
• tag="web-bot-auth" und alg="ed25519" entsprechen den Anforderungen von Cloudflare: Ed25519-Schlüssel, das Tag web-bot-auth und mindestens @authority und signature-agent als abgedeckte Komponenten. keyid ist der JWK-Thumbprint des Schlüssels.

Der UA in genau diesem Request war ein gewöhnliches Desktop-Chrome. Ohne Prüfung der Signatur sieht der Request aus wie jeder andere Browser.

Wer heute tatsächlich signiert

Wir haben am 3. Oktober 2026 /.well-known/http-message-signatures-directory auf den Domains der wichtigsten Agentenanbieter abgefragt. chatgpt.com lieferte einen Ed25519-Schlüssel mit "signature_agent":"https://chatgpt.com", allerdings unter einer anderen keyid als im Mitschnitt von 2025, der Schlüssel wurde also rotiert. agent.bot.goog lieferte Ed25519-Schlüssel; laut Googles Dokumentation „experimentiert“ Google für Google-Agent „mit dem Web-Bot-Auth-Protokoll unter der Identität https://agent.bot.goog“. Auch browserbase.com lieferte Schlüssel (Browserbase gehörte im August 2025 zur ersten Signed-Agents-Kohorte von Cloudflare, neben ChatGPT agent, Goose von Block und Anchor Browser). Derselbe Pfad lieferte auf claude.ai, claude.com, anthropic.com, perplexity.ai und browser-use.com einen 404 oder eine HTML-Seite. Eine fehlende Datei unter diesem Pfad beweist nicht, dass ein Anbieter nie etwas signiert, aber keiner von ihnen veröffentlicht dort ein Verzeichnis oder dokumentiert Signaturen auf seinen Bot-Seiten.

Auf der Prüferseite validiert Cloudflare Signaturen an der Edge. Seit dem 1. Juli 2026 hat das Unternehmen signierte Agenten in die Verified Bots integriert, mit einem neuen Feld Direct vs. Intermediary, das festhält, ob ein einzelner Betreiber den Bot steuert oder viele Endnutzer. Agent Trust von DataDome kombiniert Web Bot Auth, offizielle IP-Listen und Reverse DNS mit Intent-Modellen. Beide werten eine Signatur als Identitätsnachweis, nicht als Beleg guter Absichten.

Agententyp → Identifikation → Erkennung → typische Policy

Was das für Website-Betreiber bedeutet

Entscheiden Sie pro Kategorie und pro Endpunkt, nicht einmal pauschal für „KI“. Was auf einem öffentlichen Artikel in Ordnung ist, ist es auf einem Login-Formular womöglich nicht.

• Erst prüfen, dann entscheiden. Gleichen Sie bei deklarierten Bots den UA mit den IP-Listen ab und prüfen Sie bei signierten Agenten die Signatur. Unverifizierter Traffic, der sich als GPTBot ausgibt, ist schlicht Traffic mit gefälschtem UA.
• Zulassen, sperren oder abrechnen. Die Steuerungen von Cloudflare funktionieren in allen Tarifen pro Kategorie. Pay per Crawl beantwortet nicht zahlende Crawler mit HTTP 402, befand sich zum Zeitpunkt der Erstellung aber noch in einer geschlossenen Beta.
• Aktionen schützen, nicht Seiten. Das eigentliche Risiko lokaler agentischer Browser liegt in dem, was sie innerhalb authentifizierter Sessions tun. Setzen Sie verhaltensbasiertes Scoring und zusätzliche Prüfungen bei Checkout, Kontoänderungen und Formularübermittlungen ein. Unser Artikel zu den Interna von Turnstile erklärt, wie das Challenge-Scoring dabei ins Bild passt.
• Rechnen Sie mit Fehlalarmen in beide Richtungen. Auch Barrierefreiheitstools fügen Text ein und verschieben den Fokus ohne Maus. „Keine Mausbewegung“ allein sollte keine Session sperren.

Was das für Entwickler von Agenten bedeutet

Identifizieren Sie sich ehrlich, signieren Sie, wenn möglich, und nutzen Sie Proxys für Geografie und Lastverteilung, nicht um wie ein Mensch auszusehen. Die Erkennung entwickelt sich in Richtung „signierte Agenten verifizieren, den Rest nach Verhalten bewerten“. Einen Agenten zu tarnen wird immer teurer, ehrlich zu bleiben immer günstiger.

• Geben Sie sich zu erkennen. Verwenden Sie für serverseitige Fetcher ein aussagekräftiges UA-Token mit Kontakt-URL. Wenn Sie einen Agentendienst betreiben, veröffentlichen Sie ein Schlüsselverzeichnis und signieren Sie Requests. Die Dokumentation von Cloudflare und quelloffene web-bot-auth-Bibliotheken decken die Einrichtung mit Ed25519 ab.
• Respektieren Sie robots.txt und websitespezifische Agentenregeln für alles, was nicht direkt von einem Nutzer ausgelöst wird, und halten Sie die Request-Raten in vernünftigem Rahmen. Beides ist Voraussetzung für die Verifizierung durch Cloudflare.
• Nutzen Sie Proxys aus den richtigen Gründen. Residential-Exits liefern korrekte Ergebnisse auf Länderebene und verhindern, dass sich eine ganze Agentenflotte auf eine einzige Cloud-IP drängt. Für Verhaltensmodelle machen sie einen Agenten nicht unsichtbar, und sie zu nutzen, um eine Website zu umgehen, die Agenten gesperrt hat, ist genau das Verhalten, das Cloudflare anführte, als es Perplexity von seiner Verified-Liste strich. Unser Praxisleitfaden zur Proxy-Einrichtung für KI-Agenten behandelt die Konfiguration. Die besten Proxys für KI-Agenten vergleicht IP-Typen für diese Workloads.
• Halten Sie bei Challenges an. Wenn ein Agent auf ein CAPTCHA oder einen 403 eines Bot-Management-Anbieters stößt, hat die Website eine Entscheidung getroffen. Übergeben Sie an einen Menschen, statt es erneut zu versuchen.

Was Web Bot Auth nicht löst

Eine Signatur belegt, wer den Agenten betreibt, nicht worum der Nutzer ihn gebeten hat. Wie Castle in seiner Anleitung zu den Operator-Signaturen schreibt, bestätigt die Prüfung die Herkunft, „beweist aber nicht die Absicht des Nutzers“. Auch ein signierter Agent lässt sich auf Credential Stuffing, Scalping oder einen per Prompt Injection ausgelösten Kauf ansetzen. Deshalb legen das Intermediary-Label von Cloudflare und die Trust-Scores von DataDome weiterhin Verhalten über die Identität. Für den schwierigsten Fall, lokale agentische Browser, bringt Signieren ohnehin nichts, denn sie senden derzeit überhaupt nichts, was sich prüfen ließe. Solange diese Produkte nicht signieren oder Websites sich allein auf Cursor-Geometrie und Timing stützen, bleibt ihre Erkennung eine Frage der Wahrscheinlichkeit, nicht des Beweises.