Stille Agenten nutzen bereits Ihre Website

Ein stiller Agent ist eine Automatisierung, die über einen gewöhnlichen Browser oder eine Kundensitzung agiert, ohne dabei eine überprüfbare Agentenidentität preiszugeben. Es kann sich um einen legitimen Assistenten handeln, der im Auftrag des Kunden handelt, um einen nicht autorisierten Agenten, der seine Berechtigungen überschreitet, oder um eine schädliche Automatisierung, die das Verhalten eines Agenten imitiert.

Wenn menschliche und automatisierte Aktivitäten innerhalb derselben authentifizierten Sitzung stattfinden, wird es schwieriger, sie voneinander zu unterscheiden. Ohne explizite Agentenidentifikation müssen sich Unternehmen auf verhaltensbasierte und technische Signale verlassen, die nicht immer das vollständige Bild vermitteln: Wenn Sie die Erkennung lockern, um legitime Agenten zuzulassen, setzen Sie Ihr Unternehmen möglicherweise schädlicher Automatisierung aus. Und wenn Sie die Erkennung verschärfen, blockieren Sie möglicherweise Aktivitäten, die vom Kunden autorisiert wurden.

In der Geschichte des Bot‑Managements hat sich fast jede Automatisierung, die es wert war, dass Unternehmen sie unterstützen, selbst angekündigt: Such-Crawler haben ihre User Agents und ihre IP‑Bereiche angegeben. So konnte eine Website beispielsweise nach „Googlebot“ suchen, den Bot bestätigen und ihn anders behandeln als einen anonymen Scraper. Dieses Vereinbarung hat funktioniert, weil der Bot‑Betreiber erkannt werden wollte.

Doch Verbraucheragenten haben diese Vereinbarung unbeabsichtigt gebrochen. Sie wurden entwickelt, um das Internet so zu nutzen, wie es ein Mensch tut: Sie steuern einen Browser, klicken sich durch Seiten, füllen Formulare aus und bewältigen Probleme ganz wie ein Mensch.

• Muse läuft auf einer virtuellen Maschine in der Meta-Cloud mit einem integrierten Browser.

• Instinct nutzt einen persistenten Cloud-Desktop und bedient ihn mit den gespeicherten Nutzeranmeldedaten, einschließlich E‑Mail- und Zahlungsdaten.

• Dots werden als Cloud-Agent von OpenAI ausgeführt.

Aus Sicht des Servers handelt es sich bei jedem einzelnen um eine Browsersitzung: Die User‑Agent-Zeichenkette deutet auf einen Browser hin, während ihr Verhalten auf Automatisierung hindeutet.

Unternehmen berichten von zwei verschiedenen Problemen – je nachdem, ob Agenten im Banking oder im Handel eingesetzt werden.

Einfach jeden Agenten zu blockieren, ist die schnellste Lösung und lässt sich intern am einfachsten rechtfertigen. Und bei Anmeldungen und Geldtransaktionen ist diese Blockierung wahrscheinlich tatsächlich die angemessenste Sicherheitsentscheidung – zumindest derzeit. Doch wenn diese Blockierung auf die gesamte Website angewendet wird, wird aus dieser Sicherheits- auch eine Geschäftsentscheidung: Der Agent handelt im Auftrag eines Kunden, der etwas kaufen möchte, und die Blockierung hindert ihn daran. Käufer, die auf diese Sperre stoßen, kommen nicht zu dem Schluss, dass sich ihr Agent besser identifizieren muss, sondern wechseln zu einer Website, auf der der Agent funktioniert.

Schreibgeschützter Zugriff ist eine durchdachtere Variante und hat sich besser bewährt – auch wenn er nicht die umfassende Lösung bietet, wie es vielleicht den Anschein hat. Denn das Lesen eines Kontos ist nicht risikofrei, wenn der Agent anschließend auf Grundlage der gelesenen Daten Aktionen in einem anderen System ausführt. Und viele wertvolle Aktionen betreffen weder Lesevorgänge noch Geldüberweisungen, darunter Buchungen, Terminverschiebungen, Adressänderungen oder das Einlösen einer Prämie. Schreibgeschützter Zugriff verschafft also nur Zeit, anstatt sichere Richtlinien zu schaffen.

Eine einzige Kategorie „KI‑Bots“ reicht für eine Richtlinie nicht aus, da der darin enthaltene Traffic gegensätzliche Ziele verfolgt: Ein Crawler, der Ihre Produktbeschreibungen sammelt, um ein Modell zu trainieren; ein Such-Crawler, der Ihre Website indiziert, damit Ihre Marke in einer KI‑Antwort angezeigt wird; und ein Assistent, der eine einzelne Seite abruft, weil Ihr Kunde eine Frage gestellt hat, sind drei grundlegend unterschiedliche Transaktionen.

Im August 2026 haben wir diese Kategorie im Akamai Bot Directory in drei Unterkategorien aufgeteilt:

• KI-Trainings-Crawler: Sammeln Inhalte in großem Umfang, um Modelle zu trainieren (z. B. GPTBot, ClaudeBot und Meta‑ExternalAgent).

• KI-Such-Crawler: Indizieren Websites für KI‑Suche und Quellenangaben (z. B. OAI‑SearchBot, Claude-SearchBot und PerplexityBot).

• KI-Fetcher und -Agenten: Greifen in Echtzeit auf eine Seite zu, um eine Frage zu beantworten oder eine Aufgabe zu erledigen (z. B. ChatGPT‑User, ChatGPT Agent, GoogleAgent-Mariner und mutmaßliche stille Agenten).

Diese Unterteilung bietet Unternehmen eine detailliertere Kontrolle über Maßnahmen, die sich andernfalls widersprechen würden: Sie können Trainings-Crawler einschränken, um Inhalte zu schützen, für die das Unternehmen keine Lizenz besitzt; können Such-Crawler zulassen, damit die Inhalte in KI‑Antworten sichtbar bleiben; und können Echtzeitagenten als den Kundentraffic behandeln, der sie in der Regel sind – eine Richtlinie pro Kategorie, festgelegt vom Unternehmen.

Die Transparenz muss sich zudem über den Katalog hinaus erstrecken: Der Traffic, der Banken Sorgen bereitet, betrifft nicht das bloße Stöbern im Katalog, sondern die Aktivitäten angemeldeter Nutzer. Die Überwachung der Agentenaktivitäten in authentifizierten Sitzungen unterscheidet sich von der Nachverfolgung auf Inhaltsseiten – und Unternehmen benötigen beide Perspektiven, bevor sie beginnen können, das Risiko zu managen.

Kategorien zeigen, welche Art von Traffic eingegangen ist. Als Nächstes stellt sich die Frage, woher Sie Ihr Wissen über jeden einzelnen Agenten beziehen – und darauf gibt es zwei sehr unterschiedliche Antworten:

Einige Agenten geben sich auf eine Weise zu erkennen, die überprüft werden kann. Sie veröffentlichen einen Schlüssel, signieren ihre Anfragen und können an der Edge verifiziert werden, statt ihnen einfach glauben zu müssen. Diese Agenten sind bekannt und ein bekannter Agent kann seine eigene Richtlinie erhalten – auch beim Bezahlvorgang –, da die Erkennung nicht von etwas abhängt, das kopiert werden kann.

Alles andere wird abgeleitet. Wir ordnen Agenten anhand beobachteter Merkmale zu und kennzeichnen sie als „verdächtig“. Deshalb enthalten Berichte Einträge wie „Muse‑Agent (verdächtig)“ anstelle einer bestätigten Identität. Diese Kennzeichnung ist wirklich nützlich: Sie verrät Ihnen, dass ein Agent Ihre Website erreicht, wie viel Traffic er ungefähr verursacht und wohin er navigiert. Sie sagt Ihnen jedoch nicht, dass die nächste Anfrage mit demselben Muster von demselben Agenten stammt – und eine Richtlinie, die auf dieser Annahme basiert, wird letztendlich Zugriff auf etwas gewähren, das Sie nicht beabsichtigt haben.

Verhaltensbasierte Risikobewertung ist das, was übrig bleibt, wenn keine Zuordnung möglich ist. Und sie ist die Kontrolle, die auch dann noch funktioniert, wenn Agenten Täuschungstechniken einsetzen. Indem die Bewertung untersucht, wie sich eine Sitzung verhält – statt als was sie sich ausgibt –, greift sie sowohl bei Agenten, die wie ein Browser wirken sollen, als auch bei Reseller-Bots, die wie ein Käufer wirken sollen.

Das ist auch der Grund, warum legitime Agenten manchmal an der Kasse gestoppt werden. Dieses Ergebnis entspricht der vorgesehenen Funktionsweise des Systems: Solange sich Agenten nicht authentifizieren können, landet ein Teil des legitimen Agententraffics in der Kategorie „Nicht verifiziert“.

Die logische Konsequenz für Sicherheitsteams besteht darin, die beiden Signale – Kategorie/Kennzeichnung und Verhalten – gemeinsam zu betrachten. Kategorie und Kennzeichnung geben Aufschluss darüber, wer in welchem Umfang auf die Seite zugreift, während das Verhalten Aufschluss darüber gibt, was diese Sitzung gerade tut. Keines von beiden reicht allein aus, um Richtlinien festzulegen.

Eine Katalogseite und eine Checkout-Seite bergen unterschiedliche Risiken. Ein Agent, der für einen Kunden Produktbeschreibungen liest, tut etwas, was Standardbrowser schon immer getan haben. Unternehmen wünschen sich diesen Traffic in der Regel, weil er zu Verkäufen führt und weil KI‑Assistenten zusehends dazu eingesetzt werden, Produkte zu entdecken.

Doch wenn dieser Agent eine Bestellung aufgibt, führt er damit eine Aktion durch, die Bestände und Geld bewegt – und das verdient dieselbe sorgfältige Prüfung, die bei jeder Automatisierung angewendet wird. Die Anmeldung liegt näher am Bezahlvorgang als am Katalog. Das gilt auch für alle Aktivitäten, die Änderungen an Konten durchführen.

Das bedeuten ausgewählte Aktionen in der Praxis:

• Eine Richtlinie für Inhalte, bei der der Großteil des KI‑Traffics überwacht oder zugelassen werden kann

• Eine andere Richtlinie für Transaktionen, die jede Anfrage im Hinblick auf Automatisierung bewertet – unabhängig davon, wie sich diese Automatisierung selbst bezeichnet

• Eine dritte Richtlinie für die Authentifizierung, bei der es nicht darum geht, ob die Sitzung automatisiert ist, sondern ob die dahinter stehende Person der Kontoinhaber ist und ob es sich um eine erkennbare Aktion handelt

Mit diesem Setup sieht das Ergebnis so aus, wie es die meisten Einzelhändler bereits gewohnt sind: Ein Agent kann für einen Kunden im Katalog stöbern, wird jedoch beim Kaufversuch gestoppt. So können Kunden ungehindert Produkte entdecken, bestehende Kontrollen werden dort angewendet, wo Geld im Spiel ist, und das Unternehmen behält die Freiheit, seine Entscheidung für jeden einzelnen Endpoint zu ändern, ohne die gesamte Richtlinie neu aufrollen zu müssen.

Die gleiche Logik beantwortet die Frage, die uns am häufigsten gestellt wird: Wie kann man einem bestimmten Agenten erlauben, einen Kauf abzuschließen? Die Antwort ist keine Ausnahmeregelung, die für eine bestimmte Signatur erstellt wurde – denn die Regelung gilt auch für alles, was diese Signatur imitiert. Stattdessen liegt die Antwort in Authentifizierung und Verifizierung: Sobald ein Agent nachweist, wer er ist, kann er seine eigene Richtlinie erhalten – auch an der Kasse –, und das Unternehmen kann anhand dieser Verifizierung Zugriff gewähren, statt sich auf ein Muster zu verlassen.

Jeder Aspekt dieses Problems ist auf dasselbe fehlende Puzzleteil zurückzuführen: Ein Agent kann nicht nachweisen, wer er ist oder für wen er arbeitet, sodass Websites auf Schlussfolgerungen zurückgreifen müssen – doch bloße Schlussfolgerungen können nicht die zuverlässige Entscheidungsfindung unterstützen, die Unternehmen benötigen.

Dieses fehlende Puzzleteil wird gerade entwickelt. Mit Web Bot Auth, einem Entwurf der Internet Engineering Task Force, den wir unterstützen, kann ein Agent seine Anfragen signieren, sodass eine Website den Ursprung kryptografisch verifizieren kann, anstatt sich auf einen Header verlassen zu müssen.

Das Trusted Agent Protocol von Visa basiert auf demselben Signaturverfahren, das auch für Zahlungen verwendet wird. Wir haben es integriert, damit Händler erkennen können, ob ein Agent lediglich die Seite durchsucht oder eine Zahlung durchführt, und den Agenten dem Kunden zuordnen können, den er vertritt. Know Your Agent von Skyfire fügt eine Identitätsebene hinzu, die einen Agenten an verifizierte Unternehmen oder Nutzer bindet. Gleichzeitig sind wir auch dem Experian Agent Trust-Ökosystem beigetreten. Im Juni 2026 haben wir diese Komponenten zu einem agentischen Sicherheitsframework kombiniert, das Identität, Beobachtbarkeit, Vertrauen und Edge-Durchsetzung abdeckt.

Die vier Schritte, die Sie jetzt unternehmen können, lauten:

1. Finden Sie heraus, welche Agenten bereits auf Ihre Website zugreifen.

2. Legen Sie Richtlinien auf Endpoint-Basis fest.

3. Machen Sie die Zulassung von einer Verifizierung abhängig.

4. Unterstützen Sie das Stöbern, während Identitätslösungen entwickelt werden.

Am Ende werden nicht die Unternehmen erfolgreich sein, die richtig erraten, welchen Agenten sie vertrauen können, sondern diejenigen, die erkennen können, welche Agenten ankommen; die wissen, in welchem Umfang sie diese Agenten verifizieren können; und die an einem Endpoint Maßnahmen ergreifen können, ohne den Rest zu beeinträchtigen.

Wenn Sie Ihre aktuellen KI‑Traffic-Kategorien und Transaktionsrichtlinien besprechen möchten, wenden Sie sich an einen Akamai-Experten.