Ein wachsendes Praxisproblem in Web-, Cloud- und DevOps-Teams klingt zunächst harmlos: Immer mehr Traffic gibt sich als AI-Crawler aus. Betreiber wollen legitime Bots von OpenAI, Anthropic, Google, Perplexity oder anderen Anbietern nicht pauschal blockieren, weil diese Crawler Inhalte für Suche, Assistenten oder Zitierfunktionen erfassen können. Also landen Ausnahmen in WAF-Regeln, Bot-Management-Policies, Rate-Limits oder Log-Dashboards. Genau dort entsteht die Schwachstelle: Viele Regeln prüfen nur den User-Agent – also eine frei wählbare Textzeile im HTTP-Request.
GreyNoise hat am 28. August 2026 eine aktuelle Messung veröffentlicht, die zeigt, wie Angreifer diese Lücke ausnutzen. Automatisierte Scanner tarnten sich als AI-Crawler und fragten keine Inhalte, sondern typische Secret- und Konfigurationspfade ab: .env-Dateien, Cloud-Zugangsdaten, private Schlüssel und Passwortspeicher. Help Net Security griff die Analyse am 31. August auf. Das Thema ist für Unternehmen relevant, weil es nicht um ein exotisches KI-Modellproblem geht, sondern um eine alte Web-Sicherheitsannahme, die durch den AI-Crawler-Boom plötzlich operativ wichtig wird.
Was technisch passiert
Jeder HTTP-Client kann behaupten, er sei ein Browser, ein Suchmaschinenbot oder ein AI-Crawler. Der User-Agent ist keine Identität, sondern eine selbst gesetzte Zeichenkette. Ein Request mit ClaudeBot, GPTBot oder ChatGPT-User beweist daher genauso wenig wie ein Request mit Googlebot. Legitimes Crawling lässt sich nur über zusätzliche Signale prüfen: veröffentlichte IP-Ranges, Reverse-DNS/Forward-DNS-Prüfung, konsistentes Verhalten und die angefragten Pfade.
GreyNoise beschreibt einen Cluster, in dem 13 AI-Crawler-Namen von acht Unternehmen imitiert wurden. Besonders auffällig: Sechs Crawler-Namen von vier Anbietern kamen zwischen dem 28. Juli und dem 23. August 2026 über denselben HTTP-Client-Fingerprint. Dieser Fingerprint hatte in den 90 Tagen bis zum 23. August mehr als 1.500 verschiedene User-Agent-Strings verwendet, überwiegend normale Browserkennungen. Die sechs AI-Crawler-Namen wurden von 824 IP-Adressen aus gesendet und erschienen in nahezu identischem Volumen.
Das Verhalten passte nicht zu echten Crawlern. Innerhalb dieses Clusters wurde laut GreyNoise kein einziges Mal /robots.txt angefragt. Genau diese Datei ist für legitime Crawler zentral, weil sie dort Regeln der Website lesen. Zum Vergleich maß GreyNoise echten Anthropic-Crawler-Traffic im selben Zeitraum: Bei diesem war /robots.txt der meistangefragte Pfad und machte zwölf Prozent des Traffics aus; Credential-Dateien wurden dort nicht angefragt.
Zahlen und belastbare Fakten
Die wichtigste Zahl ist nicht nur die Menge, sondern die Identitätsprüfung: GreyNoise prüfte alle 824 Adressen gegen die veröffentlichten Adresslisten der betroffenen Crawler-Anbieter. Keine der Adressen passte. Gleichzeitig sah GreyNoise im selben Zeitraum echte Sessions mit ClaudeBot-Kennung aus Anthropic-publizierten IP-Bereichen. Der Name allein trennt also legitimen von bösartigem Traffic nicht; die Kombination aus Name, Quelladresse und Verhalten tut es.
Die Scanner zielten auf Pfade wie /.env, /.env.production, /.env.bak und /.aws/credentials. GreyNoise betont ausdrücklich, dass die Messung nicht beweist, dass eine Organisation tatsächlich Dateien ausgeliefert hat oder kompromittiert wurde. Das ist ein wichtiger Punkt: Die Daten zeigen aktive Suche nach Secrets, nicht automatisch erfolgreiche Exfiltration. Für Verteidiger reicht der Befund dennoch, weil ein einziger 200-Response auf einem solchen Pfad ein Incident ist, kein normaler Webfehler.
Eine zweite, unabhängige Beobachtung stützt das Muster. Dominic Plouffe veröffentlichte am 14. August eine Log-Analyse eigener Webserverdaten: Von 13.670 Credential-Probes, die unter einem benannten Crawler-User-Agent liefen, kam nach seiner Prüfung keiner von einer verifizierten Vendor-Adresse. In seiner Stichprobe entfielen unter anderem 71,9 Prozent des Traffics mit angeblicher Googlebot-Kennung auf .env-Suchen. Diese Einzelmessung ist nicht repräsentativ für das ganze Internet, aber sie bestätigt den operativen Kern: Crawler-Namen werden als Tarnung für Secret-Scanning missbraucht.
Warum AI-Crawler das Problem verschärfen
Crawler-Impersonation ist nicht neu. Neu ist die betriebliche Unsicherheit rund um AI-Crawler. Viele Organisationen haben in den letzten Monaten hastig entschieden, welche AI-Bots Inhalte lesen dürfen, welche blockiert werden und welche für Support-, Such- oder Marken-Sichtbarkeit erwünscht sind. Dadurch entstehen neue Allowlisten und neue Management-Reports. Wenn diese Reports nur nach User-Agent gruppieren, wird bösartiger Scan-Traffic plötzlich als „AI-Bot-Traffic“ gezählt. Wenn Policies AI-Crawler von Challenges oder Rate-Limits ausnehmen, wird ein gefälschter Header zum Passierschein.
Das Problem betrifft auch DevSecOps-Prozesse. .env-Dateien und Cloud-Credential-Pfade gehören nie ins Webroot, trotzdem landen sie durch schlechte Deployments, Debug-Konfigurationen, falsch konfigurierte Static-Hosting-Jobs oder kopierte Projektverzeichnisse immer wieder öffentlich. Mit AI-Agenten kommen zusätzliche sensible Dateien hinzu: MCP-Konfigurationen, lokale Assistant-Settings, Editor-Integrationen oder Continue-/Coding-Agent-Konfigurationen können API-Keys, Model-Gateway-Tokens oder interne Endpunkte enthalten. Sobald Scanner solche Pfade systematisch abfragen, verkürzt sich das Zeitfenster zwischen Fehl-Deployment und Credential-Diebstahl.
Konkrete Implikationen für Unternehmen
Erstens sollten Web- und Security-Teams jede Regel prüfen, die Crawler anhand des User-Agent privilegiert. Eine Allowlist darf nicht „enthält GPTBot“ oder „enthält ClaudeBot“ heißen. Sie muss den konkreten Crawler-Namen gegen die vom Anbieter veröffentlichte IP-Liste oder eine belastbare DNS-Prüfung validieren. Wo Anbieter mehrere Crawler-Typen getrennt dokumentieren, muss auch die passende Liste verwendet werden.
Zweitens gehören Secret-Pfade in ein eigenes Monitoring. Requests auf /.env, /.aws/credentials, /.git/config, private Schlüsseldateien, Backup-Varianten und agentenspezifische Konfigurationsdateien sollten unabhängig vom User-Agent alarmieren. Ein echter Crawler hat keinen legitimen Grund, solche Pfade zu lesen. Noch wichtiger: Die Response-Codes müssen ausgewertet werden. Viele 404-Scans sind Hintergrundrauschen; ein 200 auf einem Secret-Pfad ist ein Credential-Rotation-Fall.
Drittens sollten Dashboards AI-Crawler-Traffic nicht blind nach Namen zählen. Aussagekräftig ist die Trennung nach verifiziertem Bot, angefragtem Inhalt, Operationspfaden wie robots.txt oder sitemap.xml und Scan-Pfaden. Sonst entsteht ein falsches Lagebild: Management sieht wachsenden AI-Crawler-Traffic, während die Security in Wahrheit einen Credential-Scanner misst.
Viertens müssen Build- und Deployment-Pipelines verhindern, dass Projektwurzeln ungefiltert ins Web gelangen. Dazu gehören Deny-Listen für Secret-Dateien, positive Artefaktlisten, CI-Prüfungen vor Uploads, Secret-Scanning im Artefakt und serverseitige Regeln, die dotfiles und bekannte Credential-Pfade grundsätzlich blockieren. Für agentische Entwicklerumgebungen sollten zusätzlich MCP-, Assistant- und Editor-Konfigurationen in die Prüfpfade aufgenommen werden.
Risiken und Grenzen der Quellenlage
Die GreyNoise-Daten zeigen Netzwerkbeobachtungen, keine vollständige Attribution. Wer hinter den Scannern steht, bleibt offen. Ebenso ist nicht belegt, wie viele Server tatsächlich Secrets ausgeliefert haben. Auch einzelne Blog-Loganalysen wie die von Plouffe sind wertvoll, aber nicht repräsentativ. Man sollte daraus keine globale Opferzahl ableiten.
Trotzdem ist die Verteidigungslogik robust. Sie hängt nicht davon ab, welcher Akteur die Scans betreibt. Ein User-Agent ist keine Identität. Credential-Pfade gehören nicht öffentlich erreichbar. Und eine Bot-Ausnahme, die auf einer selbst behaupteten Zeichenkette basiert, ist keine Sicherheitskontrolle.
Fazit
Gefälschte AI-Crawler sind kein neues Super-KI-Risiko, sondern ein klassischer Vertrauensfehler im neuen Gewand. Unternehmen haben begonnen, AI-Crawler operativ zu behandeln wie legitime Infrastrukturpartner. Genau deshalb wird ihre Identität interessant für Angreifer. Die richtige Antwort ist nüchtern: Crawler verifizieren, nicht nur benennen; Secret-Pfade unabhängig vom Bot-Namen alarmieren; Deployments gegen versehentliche Konfigurationslecks härten; und AI-Traffic-Dashboards so bauen, dass sie Scanner nicht als Nachfrage nach Inhalten missverstehen.
Quellen: GreyNoise, „Threat Actors Are Posing as OpenAI, Anthropic and DeepSeek to Target Credentials and Secrets“, 28. August 2026; Help Net Security, „Threat actors are posing as AI crawlers to hunt for exposed credentials“, 31. August 2026; Dominic Plouffe, „Credential Scanners Are Wearing Crawler Costumes“, 14. August 2026.
