Agentenverhalten als Sicherheitsanlass
Cloudflares Beitrag „Unveiling good and bad behaviors on the Agentic Internet“ ist am 7. August 2026 erschienen und trifft einen wunden Punkt moderner Websicherheit: Die alte Sortierung „Mensch gut, Bot schlecht“ reicht nicht mehr. Cloudflare beschreibt Verkehr, bei dem eine Sitzung zwischen menschlichem und agentischem Verhalten wechseln kann, etwa wenn ein Nutzer stöbert und später ein automatisierter Assistent einen Teil des Ablaufs übernimmt. Für Betreiber ist das kein philosophisches Problem, sondern ein Regelwerk-Problem mit Nebenwirkungen.
Wenn Sie jede Automatisierung blocken, beschädigen Sie nützliche Such-, Assistenz- und Integrationsflüsse. Wenn Sie alles durchlassen, bekommen Scraper, Betrugsversuche und missbräuchliche Agenten einen roten Teppich, vermutlich ohne Eintrittskarte. Julia-Wolf-kompatibel nüchtern gesagt: Das Agentic Internet wird dort gefährlich, wo Absicht, Identität und Verhalten auseinanderfallen. Deshalb verschiebt Cloudflare den Blick von punktuellen Risikoentscheidungen zu fortlaufender Vertrauensbewertung über eine Sitzung hinweg.
Was Cloudflare beobachtet
Cloudflare unterscheidet in dem Beitrag Risk und Trust nicht als einfache Endpunkte einer Linie, sondern als unabhängige, wechselseitige Werte. Risiko beschreibt, wie wahrscheinlich eine Anfrage oder Aktion schädlich ist; Vertrauen entsteht über Zeit und Reputation. Das klingt akademisch, wird aber im Betrieb sehr konkret. Eine Anfrage kann technisch verdächtig wirken und trotzdem aus einem bekannten, erwünschten Kontext stammen. Umgekehrt kann eine sauber aussehende Anfrage Teil eines Missbrauchsmusters sein, wenn das Verhalten davor und danach nicht passt.
Besonders wichtig ist Cloudflares Beispiel hybrider Sitzungen. Eine Session kann menschlich beginnen, an einen Agenten übergehen und später wieder menschlich wirken. Genau solche Wechsel sind für starre Bot-Regeln unangenehm, weil sie nicht gut in „erlauben“ oder „blockieren“ passen. Betreiber müssen also nicht nur fragen, wer vor der Tür steht, sondern was diese Entität über mehrere Schritte tut, ob die Nutzung transparent ist und ob der Zweck zum erlaubten Datengebrauch passt.
Der Beitrag nennt auch eine klare Produktlinie: BotBase soll nicht nur eine Liste guter Bots sein, sondern ein Verzeichnis bekannter Bots und Agenten mit Faktenbasis. „Verified“ wird auf zwei Bedingungen heruntergebrochen: ein Akteur erklärt ehrlich, wer er ist, und missbraucht das erworbene Vertrauen nicht. Wer dieses Vertrauen auf Cloudflares Netzwerk verletzt, soll nicht leicht erlaubt bleiben. Das ist angenehm unromantisch und deshalb brauchbar.
Warum Bot-Abwehr komplizierter wird
Der Kern des Problems liegt in der Zeitachse. Klassische Hürden wie CAPTCHAs oder einmalige Checks bewerten einen Moment. Cloudflare argumentiert, dass solche Risk-basierten Prüfungen Kontext verlieren. Precursor setzt dagegen auf kontinuierliche clientseitige Auswertung über die Sitzung. Laut Beitrag wird die JavaScript-Erkennung per CDN injiziert, wenn ein Kunde Precursor aktiviert; Betreiber müssen die Erkennung also nicht an jeder Stelle ihrer Anwendung neu einbauen.
Cloudflare beschreibt Precursor als Trust-basierte Erkennung, die Verhalten über den gesamten Ablauf einbezieht und es Bot-Entwicklern teurer machen soll, menschliche Muster über mehrere Seiten hinweg nachzubauen. Das ist keine Garantie gegen Missbrauch, aber eine wichtige Verschiebung. Angreifer müssen nicht mehr nur eine einzelne Browserprüfung passieren, sondern konsistent genug wirken, während sie klicken, navigieren, warten, beschleunigen, korrigieren und vielleicht den Fehler machen, zu perfekt zu sein. Maschinen sind bei menschlicher Unordnung traditionell eher mäßig charmant.
Die Zahlen im Beitrag sind für Betreiber relevant: Cloudflare nennt für einen 24-Stunden-Zeitraum 206 Millionen Precursor-Evaluierungsereignisse über 73.438 Zonen im Cloudflare-Netzwerk. Daraus leitet Cloudflare zwei Muster ab: Verdächtiges Verhalten taucht häufig mitten in Sitzungen auf, und Verhalten kann innerhalb einer Session zwischen menschlich und agentisch wechseln. Diese Befunde stützen die These, dass punktuelle Prüfungen allein zu grob werden.
Für Sicherheitsverantwortliche heißt das: Ein Bot-Score am Anfang einer Session ist nur ein Schnappschuss. Wertvoller ist die Frage, ob Verhalten, Geschwindigkeit, Pfadwahl und deklarierter Zweck zusammenpassen. Wenn ein Einkaufsassistent legitim für einen Nutzer agiert, sieht er anders aus als ein Scraper, der systematisch Preise, Lagerbestände oder Texte einsammelt. Beide sind automatisiert; nur einer gehört eingeladen.
Transparenz schlägt Tarnung
Gutes Agentenverhalten beginnt in Cloudflares Darstellung mit Transparenz. Ein Bot oder Agent, der ehrlich erklärt, wer er ist und was er tut, kann für Website-Betreiber wertvoll sein. Denken Sie an Suchmaschinen, Monitoring, Barrierefreiheitswerkzeuge oder nutzerbeauftragte Assistenten. Der Sicherheitsfehler wäre, alles Automatisierte reflexhaft als Feind zu behandeln. Der Geschäftsfehler wäre, unbekannte Automatisierung ohne Zweckbindung durchzuwinken.
Für Ihre Regeln bedeutet das: Erlaubnis sollte an Identität, Zweck, Datenverwendung, Frequenz und Verhalten gebunden sein. Eine interne Einordnung zu Firewall-Regeln für KI-Agenten in Unternehmen zeigt denselben Grundkonflikt aus Betreiberperspektive: Automatisierung braucht Bahnen, nicht bloß Begeisterung. Wer gute Agenten will, muss ihnen eine erkennbare Spur geben; wer schlechte bremsen will, braucht mehr als eine Blockliste mit Staubrand.
Cloudflare nennt Precursor Trace als öffentlich verfügbare Simulation, mit der Nutzer sehen können, wie Teile der Precursor-Mechanik Cursorbewegungen bewerten. Das ist auch redaktionell interessant, weil es die Debatte greifbar macht. Bot-Erkennung ist nicht nur IP-Reputation und User-Agent-Kosmetik, sondern zunehmend Verhaltensanalyse: Rhythmus, Korrekturen, Beschleunigung und Muster, die bei echten Nutzern selbstverständlich wirken und bei automatisierten Abläufen auffallen können.
Adaptive Intelligence und flexible Gegenwehr
Cloudflare kündigt im Beitrag Adaptive Intelligence als kommenden Detection Engine im Bots-ML-Bereich an. Historisch, so die Darstellung, wurden Bots-ML-Versionen als neue Modellversionen ausgerollt. Das passe schlecht zu Bots, die sich in Stunden oder Minuten anpassen. Adaptive Intelligence soll sich auf Basis beobachteter Verkehrsmuster selbst weiterentwickeln und Bot-Management-Kunden künftig ohne manuelles Upgrade die neuesten prädiktiven Erkennungen bereitstellen.
Noch spannender sind die beschriebenen Mitigationsideen für Betreiber. Cloudflare warnt vor dem „Bot Antibiotic Problem“: Immer dieselbe deterministische Antwort, etwa ein 403-Block, macht Verteidigung ausrechenbar. Als Gegenmittel nennt der Beitrag drei Richtungen: zufällige Reaktionen zwischen Block, Challenge oder Allow für verdächtigen automatisierten Verkehr; AI Labyrinth als defensive Irreführung für unerwünschte Bots; und Queuing für legitime automatisierte Zugriffe, die nicht pauschal abgewiesen, aber kontrolliert werden sollen.
Die AI-Labyrinth-Optionen sind bewusst kantig: Maze erzeugt ein endloses Netz verlinkter Seiten, Summary liefert für Crawler eine nutzlose, aber plausibel wirkende Zusammenfassung, und Poison serviert absichtlich falsche Inhalte wie Fake-Preise oder Fake-Inventar, um Trainingsdaten zu verschmutzen. Solche Maßnahmen gehören sorgfältig eingegrenzt. Falsche Inhalte sind kein Spielzeug für normale Nutzerpfade, sondern eine Verteidigungsidee gegen nicht autorisierte Bots. Wer dabei nicht trennt, vergiftet am Ende womöglich die eigene Küche.
Kontrollen für Betreiber
Für Website-Betreiber folgt daraus ein Kontrollmodell in Schichten. Erstens brauchen Sie eine erlaubte Klasse transparenter Bots und Agenten, inklusive Zweck, Frequenz, Authentisierung und Datenzugriff. Zweitens brauchen Sie Erkennung für Sitzungen, die ihren Charakter ändern. Drittens brauchen Sie abgestufte Reaktionen: erlauben, verzögern, herausfordern, begrenzen, irreführen oder blockieren. Der entscheidende Punkt ist nicht maximale Härte, sondern passende Härte.
Dabei hilft ein Datenmodell, das BotBase-ähnlich Fakten sammelt: bekannte Agenten, deklarierte Identität, beobachtetes Verhalten, Missbrauchsfälle, Ausnahmen, Business Owner und Ablaufdatum. Ohne Besitzer werden Ausnahmen alt, und alte Ausnahmen sind die Lieblingspflanzen von Angreifern. Auch der Digital-Magazin-Kontext zum Claude-Code-Leak im Enterprise-Umfeld zeigt, wie schnell Automatisierung, Zugriff und Datenabfluss zusammenstoßen können, wenn Grenzen nicht sauber gezogen sind.
Wichtig ist außerdem Kommunikation. Wenn Sie legitime Agenten zulassen möchten, müssen Sie für Partner, Entwickler und Nutzer verständlich machen, welche Wege akzeptiert werden. Heimliche Automatisierung sollte teurer sein als ehrliche Deklaration. Genau diese Anreizlogik steckt in Cloudflares Betonung von Transparenz: Gute Akteure bekommen weniger Reibung, schlechte verlieren Vertrauen. Das ist unspektakulär und im besten Sinne administrierbar.
Wo die Daten nicht alles beweisen
Die genannten 206 Millionen Evaluierungsereignisse und 73.438 Zonen sind starke Beobachtungswerte aus Cloudflares Netzwerk, aber sie sind kein Freibrief für pauschale Schlussfolgerungen über jedes einzelne Webangebot. Andere Branchen, Zielgruppen und Regionen können andere Muster zeigen. Der Beitrag belegt Cloudflares Sicht auf sein Messfeld und liefert konkrete Produkt- und Strategiepunkte; Ihre eigene Policy muss dennoch an Traffic, Risikoappetit, Datenschutz und Geschäftsmodell angepasst werden.
Gerade Verhaltensanalyse verlangt saubere Governance. Wer Sitzungssignale auswertet, sollte festlegen, welche Daten erhoben werden, wie lange sie bleiben, wer Ausnahmen genehmigt und wie Fehlklassifikationen korrigiert werden. Sicherheit wird sonst schnell zur Blackbox, und Blackboxen haben die unangenehme Eigenschaft, erst im Streitfall plötzlich sehr sichtbar zu werden. Das Agentic Internet braucht deshalb nicht nur neue Bot-Erkennung, sondern auch nachvollziehbare Regeln für den Umgang mit legitimer Automatisierung.
Der nächste Schutztest
Ein praktischer Start ist ein 30-Tage-Test mit drei Listen: erwünschte Automatisierung, unerwünschte Automatisierung und unklare Grenzfälle. Messen Sie, welche Sitzungen mitten im Ablauf kippen, welche User Journeys unter Schutzmaßnahmen leiden und welche Bot-Klassen geschäftlich erwünscht sind. Danach entscheiden Sie nicht abstrakt über „Agenten“, sondern über konkrete Flüsse: Suche, Vergleich, Checkout, Monitoring, Scraping, Betrug, Account-Takeover-Versuche und Support-Automatisierung.
Cloudflares Beitrag macht die Richtung deutlich: Vertrauen entsteht nicht durch eine einzelne Türkontrolle, sondern durch Verhalten über Zeit. Für Betreiber ist das lästig, aber fair. Das Netz wird nicht weniger agentisch, nur weil Regeln von gestern einfacher waren. Wer gute Agenten erkennen, schlechte bremsen und hybride Sitzungen sauber behandeln will, braucht jetzt ein Trust-Modell, das Technik, Zweck und Verantwortung zusammenbringt. Alles andere ist nur ein CAPTCHA mit nostalgischem Beigeschmack.
Am Ende sollten Sie die Ergebnisse nicht nur in Security-Metriken, sondern in Produktentscheidungen übersetzen. Welche legitimen Agenten verbessern Nutzerwege? Welche automatisierten Zugriffe belasten Infrastruktur oder verletzen Nutzungsbedingungen? Welche Signale dürfen eine harte Sperre auslösen, und wo reicht Drosselung? Diese Fragen sind unbequem, aber deutlich billiger als eine Bot-Politik, die entweder jeden Gast misstrauisch mustert oder die Haustür aus Prinzip offen lässt.
Was halten Sie von dem Thema? Hier können Sie mit anderen Leserinnen und Lesern ins Gespräch gehen.
Mitreden & diskutieren
Ihre Meinung zählt — teilen Sie Gedanken, Fragen oder Erfahrungen zu diesem Artikel.