Cloudflare macht HTTP 402 zur Bezahlschranke für KI-Agenten

Cloudflare holt den Statuscode 402 aus der Reserve. Aus Payment Required wird eine maschinenlesbare Zahlungsbedingung, die ein Agent ohne Checkout-Seite beantworten kann. Für Betreiber verschiebt sich die Arbeit damit von der Bot-Abwehr in den Daten- und Zahlungsbetrieb.

Das Wichtigste in Kürze

Verwandt:MCP wächst: Stateless Agent-Server skalieren endlich frei  /  Wenn die KI-Antwort das Ranking ersetzt

Vom Bot-Filter zur Kasse am Edge

Die Entwicklung lässt sich an vier Produktschritten ablesen. Sie gehören zeitlich sauber auseinandergehalten. Im Juli 2025 stellte Cloudflare Pay per Crawl vor, damals ausdrücklich als Private Beta. Crawler senden einen Zahlungswunsch, Cloudflare kann als Merchant of Record auftreten, Publisher erlauben den Zugriff, bepreisen ihn oder blockieren ihn. Im August 2025 folgte AI Crawl Control als allgemein verfügbares Produkt. Es steuert ausgewählte Bots und antwortet bei passenden Regeln mit HTTP 402. Pay per Crawl blieb in derselben Ankündigung Beta.

Im September 2025 kam mit dem AI Index die Auffindbarkeits-Ebene dazu: ein KI-optimierter Suchindex, ein MCP-Server, eine Search API, llms.txt und llms-full.txt, eine Bulk Data API und Pub/Sub. Opt-in, Berechtigungen und Kontrolle stehen dort im Vordergrund. Im Juli 2026 beschreibt Cloudflare mit dem Monetization Gateway die Ausweitung auf beliebige Ressourcen hinter dem Netzwerk: Webseiten, Datensätze, APIs, MCP-Tools. Genannt sind zunächst Stablecoin-basierte Zahlungen. Routing nach Methode, variable Preise und Regeln für nicht authentifizierte Aufrufer stehen als geplante Fähigkeiten im Text. Für die Betriebsplanung heißt das: allgemein verfügbar ist die Steuerungsebene, der Zahlungsteil ist Beta oder angekündigt.

Diese Zahl ist eine Unternehmensangabe über den eigenen Traffic. Sie belegt nur, wie viele Zugriffe abgewiesen werden. Wer daraus ein Marktvolumen ableitet, verwechselt Nachfrage nach Inhalten mit Zahlungsbereitschaft. Cloudflare selbst ordnet Crawl-Mengen in seiner Diskussion um smartere KI-Suche nur als grobes Nutzensignal ein und diskutiert die Bewegung Richtung Pay per Use.

Was beim Agenten wirklich passiert

Der technische Kern ist ein sechsstufiger Ablauf ohne Browser-Umleitung. Der Agent fragt eine Ressource an. Der Server antwortet mit HTTP 402 und liefert maschinenlesbare Zahlungsbedingungen mit: Betrag, akzeptierte Methode, Empfänger, Gültigkeit. Der Agent führt die Zahlung aus. Er wiederholt dieselbe Anfrage, diesmal mit dem Zahlungsnachweis im Header. Ein Facilitator prüft diesen Nachweis. Erst nach bestandener Prüfung reicht das Gateway die Anfrage an das Origin weiter. Der Inhalt geht raus.

Der offene Protokollpfad dafür heißt x402. Drei Ebenen bleiben dabei getrennt: HTTP 402 ist der Statuscode, x402 das Zahlungsprotokoll darüber, das Monetization Gateway das Produkt, das beides am Edge terminiert. Die Entwicklerdokumentation zu kostenpflichtigen HTTP-Inhalten zeigt den Ablauf als Proxy-Worker vor dem Origin, mit einem Testnetz-Beispielpfad. Für Architekten ist die Stelle interessant, an der die Prüfung sitzt. Der Facilitator ist eine externe Abhängigkeit im synchronen Antwortpfad, mit eigener Latenz, eigener Verfügbarkeit und eigenem Fehlerbild.

Die Bausteine, ohne die 402 nur ein Fehlerbild bleibt

Ein Preis an einer URL ist noch kein Produkt. Damit ein Agent den Weg von der Suche bis zur Auslieferung geht, müssen mehrere Komponenten gleichzeitig stehen. Am Anfang steht Discovery: Der Agent muss die Ressource überhaupt finden, über Index, Sitemap, llms.txt oder einen MCP-Server, der die Fähigkeiten beschreibt. Dann Identität. Web Bot Auth unterscheidet den zahlenden Agenten vom anonymen Scraper. Ohne diese Unterscheidung ist jede Quotenregel Fiktion.

Es folgen Schema und Provenienz. Ein Datensatz braucht eine stabile Struktur, einen Stand, eine Herkunft. Genau daraus entsteht der Grund, überhaupt zu zahlen. Dazu kommen die Pricing-Logik pro Ressource oder Methode, der Facilitator für die Prüfung, eine Origin-Policy für den Fall einer bestandenen Prüfung sowie Logs, die Zahlung, Auslieferung und Antwortgröße zusammenführen. Quoten und Abuse-Schutz gehören daneben, weil ein bezahlter Zugang genauso automatisiert missbraucht werden kann wie ein offener. Die Lizenz muss den Nutzungsumfang benennen: einmalige Abfrage, Training, Weiterverbreitung. Ein menschlicher Fallback bleibt Pflicht, sonst wird aus der Bezahlschranke eine 402-Wand für Leser. Und der kostenlose Pfad braucht eine bewusste Kante, damit klar ist, welcher Teil offen bleibt.

Damit wird sichtbar, warum saubere Daten, MCP oder API und Observability zusammengehören. Wer nur die Zahlungsschicht baut, hat eine Kasse ohne Regal. Cloudflare behandelt diese Betriebsseite mit dem Agent Readiness Score inzwischen als eigene Frage. Das ist Anbieterkommunikation, taugt aber als Checkliste für die eigene Bestandsaufnahme.

Wo der Ablauf im Betrieb bricht

Fünf Fehlerbilder sind absehbar. Alle fünf haben Vorbilder aus API-Betrieb und Paywall-Logik. Erstens findet der Agent die Quelle nicht. Der Preis steht, der Endpunkt ist erreichbar, aber kein Index und kein Tool-Schema führt hin. Das ist ein Katalogproblem. Der Zahlungsweg kann danach separat geprüft werden. Zweitens zahlt der Agent für geringe Qualität. Er bekommt eine dünne Antwort, meldet das nirgends und meidet die Quelle künftig. Ohne Qualitätsmessung auf der eigenen Seite merkt der Betreiber davon nichts.

Drittens zahlt der Agent bei einem Retry mehrfach. Ein Timeout nach der Verifikation, ein Verbindungsabbruch vor der Auslieferung, ein neuer Versuch mit neuem Nachweis. Ohne Idempotenz-Schlüssel je Anfrage und ohne Wiederverwendung eines gültigen Nachweises entsteht doppelte Belastung bei null Gegenwert. Viertens bekommt der Agent eine veraltete Antwort, weil eine Cache-Schicht die Auslieferung übernimmt, ohne den Stand mitzuliefern. Bei bezahlten Daten ist der Zeitstempel Teil der Ware. Fünftens trifft der Agent auf eine Ressource ohne klaren Lizenzumfang. Er darf abrufen, weiß aber nicht, ob er speichern, weiterverarbeiten oder trainieren darf. In dem Moment entscheidet die Rechtsabteilung des Aufrufers gegen den Kauf. Der technisch perfekte Ablauf endet dann ohne Transaktion.

Zwei Einwände, die vor dem Preisschild stehen

Der erste Einwand ist Discovery. Ein Anbieter muss von Agenten gefunden und als vertrauenswürdig ausgewählt werden, bevor eine Bezahlschranke überhaupt wirkt. Existiert eine gleichwertige kostenlose Quelle, gewinnt sie in den meisten Fällen. Der bezahlte Zugriff braucht dann ein Argument, das jenseits des reinen Zugangs liegt: Aktualität, belegte Herkunft, Vollständigkeit, klare Lizenz, ein zugesagtes Serviceniveau oder eine Struktur, die der Agent nirgendwo sonst bekommt. Das ist eine Produktfrage. Die Konfiguration folgt danach.

Der zweite Einwand betrifft das Tempo. Für 2027 werden mehr Agenten und mehr Automatisierung erwartet. Heute ist die Kette aus KI-Nutzung, Automatisierung, autonom handelnden Agenten und delegiertem Einkauf deutlich kürzer als die Infrastrukturthese nahelegt. Die Agenten-Nachfrage wächst vermutlich langsamer als der Ausbau der Bezahlwege. Wer die nächsten 18 Monate als Umsatzprognose liest, plant an der Realität vorbei. Als Vorbereitungsfenster ist derselbe Zeitraum sinnvoll, weil Katalog, Schema, Identität und Messung ohnehin gebraucht werden, egal wie schnell der Markt kommt.

Was Teams jetzt vorbereiten

Der erste Schritt kostet keine Zahlungsintegration. Erfassen, welche Ressourcen überhaupt einen Preis tragen könnten. Für jede davon die Herkunft, den Stand und den Lizenzumfang festhalten. Danach die Auffindbarkeit herstellen: Index, llms.txt, ein MCP-Server oder eine dokumentierte API, damit ein Agent die Fähigkeit ohne Ratespiel erkennt. Erst dann die Zahlungsstrecke an einer einzigen unkritischen Ressource testen, mit Testnetz-Pfad, Idempotenz und einem Log, das Zahlung und Auslieferung in einer Zeile verbindet.

Parallel gehört die Messung aufgesetzt, sonst fehlt später die Grundlage für jede Preisentscheidung. Interessant sind vier Größen: welche Agenten anfragen, welcher Anteil nach dem 402 tatsächlich zurückkommt, wie oft die Verifikation scheitert und welche Ressourcen wiederholt abgerufen werden. Wer diese Werte ein halbes Jahr lang hat, kann über Preise reden. Wer sie nicht hat, konfiguriert einen Statuscode und wartet auf Kundschaft, die den Weg dorthin nicht findet.

Häufige Fragen

Bildquelle: KI-generiert (August 2026)