Betrug durch KI-Shopping-Agents beim Checkout: Bot-Betrug per IP stoppen, ohne echte Verkäufe zu blockieren

Ihr am besten konvertierender Checkout-Traffic und Ihr teuerster Betrug kommen inzwischen aus denselben Arten von Netzwerken. Adobe stellte fest, dass KI-Traffic auf US-Händlerseiten im März 2026 „42 % besser konvertierte“ als menschliche Besucher, ein Jahr nachdem er 38 % schlechter konvertiert hatte (Adobe-Daten via TechCrunch). Gleichzeitig überschritt automatisierter Traffic 2025 die Marke von 53 % des gesamten Web-Traffics (Imperva 2026 Bad Bot Report).

HUMAN Security berichtet, dass „2,3 % der agentischen Aktivität inzwischen auf Checkout-Seiten stattfinden“ und dass „nur ein halbes Prozent“ die Rate harmloser Automatisierung von der bösartiger Automatisierung trennt (HUMAN, März 2026). Verhalten allein trennt sie nicht.

Unten finden Sie vier echte Abfragen, warum der Abgleich des User-Agents Ihre Aufgabe ist, und eine Zuordnung von Score zu Aktion, die echte Verkäufe über Agents erhält.

Warum das Blockieren von Rechenzentrums- und Proxy-IPs beim Checkout in beide Richtungen scheitert

Eine pauschale Rechenzentrumssperre scheitert, weil sie zugleich löchrig und teuer ist. Löchrig ist sie, weil die teuren Angriffe keine Rechenzentrumsadresse brauchen. HUMAN schreibt: „Das Carding-Volumen ist seit 2022 um 250 % gestiegen“, und „Versuche, Konten nach dem Login zu kompromittieren, haben sich im Jahresvergleich mehr als vervierfacht“ (HUMAN). GeoIPHub erkennt keine Residential Proxys, Betrug von Heimanschlüssen müssen also Ihre Velocity- und Zahlungsdaten erfassen. Unser Erklärartikel zu Betrug über Residential Proxys erläutert, warum.

Teuer ist sie, weil sie Menschen trifft, denen Sie etwas verkaufen wollen:

• Echte Agents laufen in Cloud-Netzwerken. Die verifizierte ChatGPT-User-Adresse unten liegt in Microsofts AS8075 und ist mit datacenter_ip markiert.
• Nutzer von Apple iCloud Private Relay teilen sich Relay-Egress-Adressen, die in Partnernetzwerken wie Cloudflare laufen.
• Carrier-Grade NAT setzt viele Teilnehmer hinter eine Adresse. RFC 6598 reserviert dafür 100.64.0.0/10 als gemeinsam genutzten Adressraum. Cloudflare hat gemessen, dass „CGNAT-IPs dreimal häufiger von Rate-Limiting betroffen sind als Nicht-CGNAT-IPs“, während die durchschnittliche Bot-Rate bei CGNAT-Adressen niedriger lag, 7 % gegenüber 13,1 % (Cloudflare).

Der Verbindungstyp ist also ein gewichteter Eingabewert, niemals eine harte Ablehnung. Unser Hub zur Bot-Erkennung per IP zeigt anhand von fünf echten Abfragen, was jedes IP-Flag beweisen kann und was nicht.

Vier Aufrufer beim Checkout, vier Abfragen: was wir am 23.10.2026 gesehen haben

Eine verifizierte Agent-Adresse erhält 0 und allow, und fast jeder Cloud-Server ebenso. Wir haben am 23. Oktober 2026 zwischen 05:03:52 und 05:04:07 UTC vier Abfragen ohne Schlüssel ausgeführt, jeweils im Abstand von 5 Sekunden:

• ChatGPT-User: 104.208.184.193, der erste Host von 104.208.184.192/28, dem ersten Präfix in OpenAIs chatgpt-user.json. Wir haben die Datei um 05:03 UTC abgerufen. Sie enthielt 234 IPv4-Präfixe, kein IPv6, mit einer creationTime vom 20.10.2026.
• Von Nutzern ausgelöster Google-Fetcher: 107.178.192.1, innerhalb von 107.178.192.0/27 in Googles user-triggered-fetchers.json.
• Gewöhnlicher Cloud-Server: 45.33.32.156, scanme.nmap.org, ein öffentlicher Testhost bei Linode. Er ist kein Agent.
• iCloud Private Relay: 104.28.46.99, eine Relay-Egress-Adresse von Apple bei Cloudflare.

Hier ist die ChatGPT-User-Abfrage, gekürzt, mit erhaltener Verschachtelung und unveränderten Werten:

Zwei Hosting-Signale schlugen an, datacenter_ip und no_ptr_datacenter. Das entlastende Signal verified_crawler drückte die Summe auf 0. Diese Adresse hat kein Reverse DNS, weder live noch gespeichert, OpenAIs Bereichsdatei ist also der einzige Beleg. Der Google-Fetcher zeigt dasselbe Muster mit 0, nur dass sein Hostname auflöst, weshalb rdns_hosting statt no_ptr_datacenter anschlägt.

Entscheidend ist die Zeile des Cloud-Servers. Seine 10 stammen allein aus datacenter_ip, innerhalb des Bereichs allow (25 oder weniger). Wäre diese Anfrage mit einem ChatGPT-User-User-Agent angekommen, würde der Score trotzdem allow sagen. Nur verified: false und name: "none" zeigen, dass die Behauptung falsch ist. Deshalb steht in der Entscheidungsspalte Zusatzprüfung, nicht Durchlassen.

Die Relay-Adresse erhielt 9, mit relay_ip als einziger Methode. Relays sind bei 60 gedeckelt, ein Nutzer von Private Relay kann block also nie erreichen. Unsere Geolokalisierung nennt Luanda, Angola, doch Apples Egress-Feed nannte bei unserer Prüfung am 12.10.2026 Lusaka, Sambia, beurteilen Sie Relay-Nutzer also auf Länderebene.

Um 05:09 UTC haben wir außerdem 136.121.16.1 abgefragt, den ersten IPv4-Host in Googles user-triggered-agents.json. Diese Datei umfasst Google-Agent, der laut Google „von Agents auf Googles Infrastruktur genutzt wird, um auf Anfrage von Nutzern im Web zu navigieren und Aktionen auszuführen“ (Google). Die Adresse kam als GoogleUserTriggeredAgent verifiziert zurück, Score 0, allow. Dabei schlug auch fcrdns_mismatch an, obwohl ein live ausgeführtes dig ihren Hostnamen forward-bestätigt. Das ist unser Bug; er hat den Score nicht verändert, und wir haben ihn erfasst.

Das sind fünf Abfragen an einem einzigen Vormittag, kein Benchmark. Bereiche verschieben sich, führen Sie die Abfragen also erneut aus, bevor Sie einen Wert übernehmen.

Der Abgleich des User-Agents ist Aufgabe Ihres Codes, nicht der API

Die API belegt, welchem Bot eine Adresse gehört, und Ihr Code belegt, dass die Anfrage genau diesen Bot angegeben hat. Eine IP-Abfrage sieht den User-Agent nie, GeoIPHub kann einen gefälschten Agent also nicht allein markieren. Ihr Checkout-Handler hat den Header und muss ihn vergleichen.

Die Namen unterscheiden sich zwischen beiden Seiten. OpenAIs User-Agent-Token ist ChatGPT-User, und die API liefert ChatGPTUser ohne Bindestrich. Googles Token ist Google-Agent, und die API liefert GoogleUserTriggeredAgent. Ein wörtlicher Stringvergleich schlägt fehl, pflegen Sie also eine kleine Zuordnung:

Ein Ergebnis false entspricht der Zeile des Cloud-Servers oben: Prüfen Sie zusätzlich oder lehnen Sie ab, unabhängig vom Score. Die vollständige Durchsetzung in nginx und Express, mit einem Test gegen einen gefälschten GPTBot, finden Sie in unserem Leitfaden zur Frage, ob Sie KI-Crawler blockieren sollten.

Verifizieren Sie die Signatur des Agents, bevor Sie seine IP bewerten

Ein gültiger Protokoll-Berechtigungsnachweis oder eine gültige Signatur wiegt schwerer als jedes IP-Signal. Drei Mechanismen beantworten die Frage „Wer hat das gesendet?“ belastbarer als eine Bereichsdatei.

Agentic Commerce Protocol (ACP). Stripe kündigte ACP am 29. September 2025 an, als offenen Standard, „gemeinsam von Stripe und OpenAI entwickelt“; das Spezifikations-Repository steht unter der Apache-2.0-Lizenz. Sein Agentic Checkout RFC kennzeichnet einen Authorization-Bearer-Token, API-Version und bei jedem POST Idempotency-Key als Pflicht, Signature und Timestamp als empfohlen. Stripe erklärt, dass seine Shared Payment Tokens „auf einen bestimmten Händler und eine bestimmte Warenkorbsumme beschränkt sind“, was begrenzt, was sich mit einem gestohlenen Token kaufen lässt.

Web Bot Auth. Agents signieren jede Anfrage nach RFC 9421 HTTP Message Signatures (Standards Track, Februar 2024). Cloudflares Beitrag zu Web Bot Auth verwendet die Header Signature, Signature-Input und Signature-Agent sowie vom Unterzeichner veröffentlichte Ed25519-Schlüssel.

Agent-Programme der Kartennetzwerke. Visa hat sein Trusted Agent Protocol „in Zusammenarbeit mit Cloudflare“ auf Basis des Standards für HTTP Message Signatures entwickelt, um vertrauenswürdige Agents „von bösartiger Automatisierung und Rogue-Bots“ zu unterscheiden (Visa, 14. Oktober 2025). Cloudflares Ankündigung vom selben Tag besagt: „Mastercard integriert Web Bot Auth in Mastercard Agent Pay.“

Bei einem ACP-Aufruf ruft laut RFC ChatGPT Ihre Checkout-Endpunkte auf, die verbindende IP gehört also der Agent-Plattform, nicht dem Käufer. Verifizieren Sie auf diesem Weg den Berechtigungsnachweis und heben Sie sich die IP-Bewertung für direkten Web-Traffic auf. Unser Leitfaden zum Verifizieren von KI-Crawlern und Agents per IP, rDNS und Web Bot Auth geht jede Prüfung durch.

Warum IP-Allowlists allein fehleranfällig sind, selbst für echte Agents

Eine von Hand gepflegte Allowlist bricht, weil Agent-Adressen geteilt werden und sich ständig verschieben. Cloudflare sagt es deutlich: „Die Logik, dass IP-Adressbereiche ein Produkt oder eine Nutzergruppe repräsentieren, ist fragil.“ Weiter heißt es, Verbindungen „könnten von mehreren Nutzern geteilt werden, etwa bei Privacy-Proxys und VPNs“, und Cloud-Bereiche „ändern sich im Lauf der Zeit“ (Cloudflare).

OpenAIs eigene Datei zeigt diese Drift:

Die Zahl vom 06.10.2026 stammt aus unserem Vergleich von GPTBot, OAI-SearchBot und ChatGPT-User. OpenAI schreibt außerdem über ChatGPT-User: „Da diese Aktionen von einem Nutzer ausgelöst werden, gelten robots.txt-Regeln möglicherweise nicht“ (OpenAI).

Auch wir hinken hinterher. GeoIPHub ruft 19 offizielle Bereichsdateien täglich neu ab und baut seine Lookup-Datenbank täglich neu auf, ein neues Präfix kann also bis zu etwa zwei Tage brauchen, bis es verifiziert wird. Behandeln Sie einen Treffer in einem Bereich als starke Bestätigung und bevorzugen Sie eine Signatur, wenn der Agent eine sendet.

Betrug durch KI-Shopping-Agents: die Bedrohungen beim Bezahlschritt

Drei Angriffe treiben den Betrug durch KI-Shopping-Agents beim Checkout, und keiner davon sieht aus wie eine legitime Agent-Bestellung mit einem Warenkorb für einen Käufer.

• Card Testing (Enumeration). Salven kleiner Zahlungen oder reiner Autorisierungsversuche mit hohen Ablehnungsquoten. Laut Visa verursachen Enumerationsangriffe „jährlich 1,1 Mrd. US-Dollar an Betrugsverlusten“, und „bei 33 % der enumerierten Konten kam es innerhalb von fünf Tagen zu Betrug“ (Visa, Mai 2024).
• Kontoübernahme. Gestohlene Logins, mit denen über gespeicherte Karten eingekauft wird. Imperva zufolge entfielen auf Finanzdienstleistungen „46 % der Vorfälle mit Kontoübernahme“ (Imperva 2026). Unser Leitfaden zur Abwehr von Kontoübernahmen behandelt die Login-Seite.
• Scalping. Bots, die bei stark nachgefragten Drops limitierte Ware horten.

Card Testing, das über viele Adressen verteilt ist, schlägt einen Zähler pro IP, zählen Sie also auch Ablehnungen und unterschiedliche Karten pro ASN und pro BIN.

Den Score von 0 bis 100 auf eine Checkout-Aktion abbilden

Ein Score von 0 bis 100 ist beim Checkout nur dann nützlich, wenn jeder Bereich auf eine feste Aktion abgebildet wird. Der erklärbare Risikoscore von GeoIPHub deckt die Eingaben auf IP-Seite ab, und scoring.detection_methods nennt jedes Signal, das angeschlagen hat. Den Rest liefern Ihr Code und Ihre Zahlungsdaten:

Bilden Sie dann die Bereiche auf Aktionen ab:

Deckelungen halten geteilte Adressen aus block heraus. Eine Relay-Adresse ist bei 60 gedeckelt, sie kann also nicht allein aufgrund des Scores abgelehnt werden, und für Adressen, die die API als Carrier-Grade NAT erkennt, gilt eine Deckelung bei 50. ACP bringt außerdem ein eigenes Card-Testing-Signal mit: Das Delegate-Payment-RFC sendet risk_signals vom Typ card_testing mit der Aktion blocked, manual_review oder authorized. Die Agent-Plattform füllt das aus; Ihr Score bleibt eine separate Prüfung. Unser Beitrag zu Schwellenwerten des IP-Betrugsscores für Login, Registrierung und Checkout testet diese Bereiche an fünf weiteren Adressen.

Eskalieren statt blockieren: 3-D Secure verschiebt die Haftung

Schicken Sie die mittleren Bereiche in 3-D Secure, statt sie abzulehnen, denn eine Zusatzprüfung erhält den Verkauf und verschiebt meist das Rückbuchungsrisiko. Der Leitfaden zur Haftung bei 3-D Secure v2 von Trust Payments besagt, dass nach erfolgreicher Authentifizierung „der Kartenaussteller in den meisten Fällen bei einer betrügerischen Rückbuchung haftet“. Er warnt aber auch: „Eine erfolgreiche Authentifizierung einer Transaktion garantiert weder die Haftungsverlagerung noch eine erfolgreiche Autorisierung.“

Eine Zusatzprüfung gibt einem echten Käufer einen Weg hindurch und zwingt einen Card Tester zu beweisen, dass er die Karte besitzt. Unser Leitfaden zu Fehlalarmen bei der VPN-Erkennung zeigt, wer sonst noch in diesem mittleren Bereich landet.

Die Frage nach autorisierten Agents ist rechtlich, nicht technisch

Die schwierigere Frage ist, ob der Agent überhaupt bei Ihnen einkaufen darf. Am 9. März 2026 erließ der US District Court for the Northern District of California auf Antrag von Amazon eine einstweilige Verfügung gegen Perplexity. The Register berichtet, der Richter habe geschrieben, dass Perplexitys Agent Comet „mit der Erlaubnis des Amazon-Nutzers, aber ohne Autorisierung durch Amazon zugreift“ (The Register). Perplexity legte Berufung ein, und am 4. August 2026 hob der Ninth Circuit die Verfügung auf und verwies das Verfahren an das District Court zurück, wo es noch offen ist.

Dieses Urteil hat die Frage nicht abschließend geklärt. IP-Prüfungen verraten Ihnen, wer die Anfrage gesendet hat. Ihre Nutzungsbedingungen legen fest, ob dieser Absender einkaufen darf.

Wo IP-Prüfungen beim Checkout versagen

IP-Signale decken nur einen Teil des Checkout-Bildes ab, und das sind die bekannten Lücken:

• Keine Erkennung von Residential Proxys. Betrug von Heimanschlüssen erfordert Ihre Velocity- und Zahlungsdaten.
• Kein Einblick in den User-Agent. Die API markiert nie einen gefälschten Agent; das übernimmt der Namensabgleich in Ihrem Code.
• Verzögerung bei Bereichen und Lücken im DNS. Ein neues Präfix kann etwa zwei Tage bis zur Verifizierung brauchen, und wir haben heute Vormittag ein falsches fcrdns_mismatch gesehen.
• Carrier-Grade NAT wird derzeit nicht anhand des Bereichs markiert. Als wir 100.64.0.1 am 22.10.2026 abfragten, kam die Adresse nicht als CGNAT markiert zurück. Bauen Sie noch keine Regel auf diesem Flag auf.

Verfolgen Sie nach jeder Regeländerung die Fehlalarme nach Segment, etwa iOS Safari, Mobilfunkanbieter und Private Relay. Unsere Notiz dazu, wie genau IP-Geolokalisierung wirklich ist, erklärt, warum das Land die Stadt schlägt.

So bauen Sie es in Ihren Checkout-Handler ein

Bauen Sie das serverseitig am Checkout-Endpunkt ein, in vier Schritten:

1. Verifizieren Sie zuerst einen ACP-Berechtigungsnachweis oder eine Web-Bot-Auth-Signatur und geben Sie einem gültigen Nachweis den vertrauenswürdigen Pfad.
2. Fragen Sie die verbindende IP ab, wie in unserem Leitfaden zum Einbau von IP-Betrugserkennung in Ihre App mit der kostenlosen API.
3. Gleichen Sie die User-Agent-Zuordnung mit threat.crawler.name ab. Eine fehlgeschlagene Agent-Behauptung erhält eine Zusatzprüfung oder eine Ablehnung.
4. Bilden Sie scoring.recommended_action auf die Bereichstabelle ab und ergänzen Sie Ihre Velocity für Karten und ASNs.

Wenn eine Entscheidung falsch aussieht, nutzen Sie die Schritte aus So untersuchen Sie eine IP-Adresse, um herauszufinden, warum. Beginnen Sie mit einer Adresse aus Ihren eigenen Checkout-Logs, die sich diese Woche als ChatGPT-User ausgegeben hat. Fragen Sie sie ab und vergleichen Sie crawler.name mit der Behauptung.

Häufige Fragen

Sollte ich beim Checkout alle Rechenzentrums- oder Proxy-IPs blockieren, um Bots zu stoppen?

Nein. Echte Agents laufen in Cloud-Netzwerken: Am 23.10.2026 erhielt eine verifizierte ChatGPT-User-Adresse in Microsofts AS8075 den Score 0 und allow. Pauschale Sperren weisen außerdem Nutzer von Private Relay und Carrier-Grade NAT ab. Gewichten Sie Hosting im Score und schicken Sie die mittleren Bereiche in 3-D Secure.

Wie unterscheide ich beim Bezahlschritt einen legitimen KI-Shopping-Agent von einem Betrugs-Bot?

Verifizieren Sie zuerst die Identität: einen ACP-Berechtigungsnachweis oder eine Web-Bot-Auth-Signatur nach RFC 9421. Fehlt beides, fragen Sie die IP ab, die threat.crawler.verified und den Bot-Namen liefert, und lassen Sie Ihren Code diesen Namen mit dem User-Agent abgleichen, den die Anfrage angegeben hat.

Warum ist eine IP-Allowlist allein für KI-Agents fehleranfällig?

Cloudflare weist darauf hin, dass die Verbindungen eines Crawling-Dienstes geteilt sein können, wie bei Privacy-Proxys und VPNs, und dass sich Cloud-Bereiche im Lauf der Zeit ändern. OpenAIs chatgpt-user.json wuchs zwischen unseren Abrufen am 06.10.2026 und am 23.10.2026 von 230 auf 234 IPv4-Präfixe.

Wie sollte ein IP-Risikoscore von 0 bis 100 auf eine Checkout-Entscheidung abgebildet werden?

Lassen Sie allow (25 oder weniger) durch, schicken Sie review (50 oder weniger) und step_up (75 oder weniger) in 3-D Secure und lehnen Sie block (über 75) ab oder halten Sie es an. Eine Agent-Behauptung, die die Verifizierung nicht besteht, erhält unabhängig vom Score eine Zusatzprüfung.

Schadet eine Zusatzprüfung mit 3-D Secure der Conversion mehr als eine Sperre?

Eine Sperre kostet den Verkauf mit Sicherheit; eine Zusatzprüfung gibt einem echten Käufer einen Weg hindurch. Trust Payments erklärt, dass nach erfolgreicher Authentifizierung in den meisten Fällen der Kartenaussteller für eine betrügerische Rückbuchung haftet, auch wenn das nicht garantiert ist.

Ist es legal, KI-Agents vom Einkauf in meinem Shop auszuschließen?

Das hängt von der Autorisierung ab, und dies ist keine Rechtsberatung. Im März 2026 erließ ein US-Bundesgericht auf Antrag von Amazon eine einstweilige Verfügung gegen Perplexity, dessen Agent Comet laut dem Richter mit Erlaubnis des Nutzers, aber ohne Autorisierung durch Amazon auf Amazon zugriff. Der Ninth Circuit hob diese Verfügung im August 2026 auf, und das Verfahren ist noch offen.