Cloudflare AI Gateway: Schutz vor Kosten auf der falschen Rechnung

Cloudflare kann in Cloudflare AI Gateway jetzt Anfragen abweisen, denen ein kundenseitiger Modellschlüssel fehlt – bevor die Kosten auf der eigenen Cloudflare-Rechnung landen. Seit dem 14. September 2026 verlangt AI Gateway auf Wunsch Provider-Zugangsdaten: Fehlt für eine Drittanbieteranfrage ein passender Schlüssel, endet sie mit HTTP 400, statt Unified Billing zu belasten.

Cloudflare AI Gateway klärt, wer zahlt

AI Gateway kann eine Modellanfrage über mehrere Zugangsdatenpfade weiterleiten. Der jeweilige Schlüssel verrät dem vorgelagerten Modellanbieter, welchem Konto die Kosten zugeordnet werden sollen.

Bislang galt eine einfache Reihenfolge. Zuerst suchte Cloudflare in der Anfrage nach einem Provider-Schlüssel. War dort keiner vorhanden, prüfte der Dienst, ob im Gateway ein Bring Your Own Key (BYOK) unter dem Alias default gespeichert war. Fehlten beide, konnte Cloudflare über Unified Billing von Cloudflare verwaltete Zugangsdaten verwenden und die Nutzung vom Cloudflare-Guthaben abbuchen.

Diese letzte Ausweichmöglichkeit ist praktisch, wenn Cloudflare bewusst als Zahler vorgesehen ist. Sie wird jedoch zum Kostenleck, sobald die Anfrage zu einem Kunden gehört, der seinen eigenen Schlüssel für OpenAI, Anthropic, Google oder einen anderen Provider bereitstellen sollte.

Für Datenverkehr zu Drittanbietern lässt sich dieser dritte Schritt nun abschalten. Wird im Gateway Require provider credentials aktiviert – in der API entspricht das byok_only: true –, endet eine Anfrage ohne passende Kundenzugangsdaten mit HTTP 400. Dieselbe Einschränkung lässt sich mit cf-aig-no-wholesale: true auf eine einzelne Anfrage anwenden. Cloudflare dokumentiert hier die vollständige Reihenfolge der Zugangsdaten und beide Steuerungsmöglichkeiten.

Am einfachsten lässt sich das als Warteschlange mit drei möglichen Zahlern verstehen:

1. Zugangsdaten der Anfrage: Der Kunde sendet seinen Provider-Schlüssel mit dem Aufruf. AI Gateway leitet ihn unverändert weiter, sodass der Provider das dahinterliegende Konto belastet.
2. Im Gateway gespeicherte Zugangsdaten: Kommt kein Provider-Schlüssel mit der Anfrage an, verwendet AI Gateway einen in Cloudflare Secrets Store hinterlegten Provider-Schlüssel. Bei Unified-Billing-Endpunkten muss der passende gespeicherte Schlüssel den Alias default tragen.
3. Cloudflare Unified Billing: Gibt es weder einen passenden Kundenschlüssel noch einen gespeicherten Schlüssel, kann Cloudflare eigene verwaltete Zugangsdaten einsetzen und Guthaben vom Cloudflare-Konto abbuchen.

Mit der neuen Regel endet die Warteschlange nach Schritt zwei. Die geschäftliche Konsequenz ist damit klar: Fehlende Zugangsdaten führen zu einem sichtbaren Ausfall, statt Kosten unbemerkt zu verlagern.

Cloudflare AI Gateway: Kostenkontrolle durch Ablehnung statt Nacharbeit

Beim Kauf von Guthaben erhebt Unified Billing eine Gebühr von 5%. Das Beispiel von Cloudflare ist eindeutig: Aus $100 Guthaben wird eine Belastung von $105; der Inferenzpreis des Providers selbst wird ohne Aufschlag weitergereicht.

Übertragen auf einen Kunden-Workflow sieht das so aus: Sollte ein Kundenauftrag das Provider-Konto des Kunden nutzen, doch dessen Schlüssel fehlt, könnte Modellnutzung im Wert von $100 stattdessen das Cloudflare-Guthaben des Betreibers aufbrauchen. Die Finanzierung dieses Guthabens kostet $105. Im Provider-Konto des Kunden taucht nichts von dieser Ausweichnutzung auf, während der Betreiber die gesamten $105 bezahlt und anschließend nachweisen muss, welcher Kunde sie verursacht hat.

Die Gebühr von 5% ist dabei nicht das Kernproblem. Entscheidend ist, dass die vollständige Arbeitslast im Wert von $100 in das falsche Budget gewandert ist. Die zusätzlichen $5 verteuern den Fehler lediglich.

Die Pflicht zu Provider-Zugangsdaten macht aus einer Finanzermittlung einen Anwendungsfehler. Der automatische Rettungsweg entfällt, dafür entsteht eine harte Grenze um den Zahler. Einen umfassenderen Vergleich von Gateway-Gebühren und direkter Provider-Abrechnung bietet die Kostenübersicht für KI-Gateways.

Für wen sich die Einstellung eignet

Agenturen mit Kundenautomatisierungen

Eine Agentur kann ein einziges Cloudflare-Konto betreiben, während jeder Kunde einen eigenen Vertrag mit dem Modellanbieter mitbringt. Auf kundenfinanzierten Routen sollte die Gateway-Regel aktiviert werden. Fehlt beim Onboarding ein Schlüssel oder wird er bei einer Rotation entfernt, stoppt der Auftrag, statt das vorausbezahlte Guthaben der Agentur anzutasten.

Der Vorteil: Die Kostenverantwortung bleibt eindeutig. Entweder stellt der Kunde funktionierende Zugangsdaten bereit oder erhält einen Konfigurationsfehler. Die Agentur muss eine gemeinsam genutzte Guthabenrechnung nicht mehr im Nachhinein mühsam auseinanderrechnen.

SaaS-Teams mit kundeneigenen Schlüsseln

Ein SaaS-Produkt, das von Kunden bereitgestellte Provider-Schlüssel akzeptiert, kann HTTP 400 als Einrichtungsstatus behandeln. Das Produkt weist den Kunden auf die fehlenden Provider-Zugangsdaten hin und hält die Anfrage zugleich aus dem Cloudflare-Guthabenpool der Plattform heraus.

Besonders wertvoll ist das, wenn eine erfolgreiche Antwort den Fehler sonst verbergen würde. Ohne Einschränkung funktioniert das Feature weiter – nur zahlt das falsche Unternehmen. Mit der Regel schlägt es früh genug fehl, um die Kontokonfiguration zu korrigieren.

Plattformteams, die zunächst nur eine Route umstellen

Der Anfrage-Header ist der kleinste sinnvolle Einstieg in die Umstellung. Zunächst cf-aig-no-wholesale: true auf einem Drittanbieterpfad ergänzen, das Verhalten bei fehlendem Schlüssel testen und den Fehler ins Monitoring aufnehmen, bevor die Regel für das gesamte Gateway aktiviert wird.

Die Vorrangregel gilt bewusst nur in eine Richtung. Ein Anfrage-Header kann ein großzügig konfiguriertes Gateway strenger machen. Bei einem Gateway mit aktivierter Option Require provider credentials kann eine Anfrage den Header nicht auf false setzen und die Vorgabe abschwächen. Cloudflare beschreibt diese Einschränkungen als kumulativ.

FinOps-Verantwortliche, die Zahler- und Budgetkontrolle trennen

Diese Einstellung legt fest, welches Konto zahlen darf. Die Ausgabenlimits von AI Gateway bestimmen dagegen, wie viel ausgegeben werden darf. Es handelt sich um unterschiedliche Kontrollen, die getrennt getestet werden sollten.

Ausgabenlimits können sowohl BYOK- als auch Unified-Billing-Anfragen erfassen, sofern Cloudflare den Modellpreis kennt. Sie lassen sich nach Modell, Provider oder Metadaten eingrenzen. Die Kosten bleiben jedoch eine bestmögliche Schätzung; für die exakte Abrechnung verweist Cloudflare auf das Provider-Dashboard. Die Provider-Zugangsdatenregel sollte deshalb als Zahlergrenze dienen, während die Ausgabenobergrenze separat geprüft wird.

Einrichtung ohne rätselhaften Ausfall

1. 1

   Jede Route dem vorgesehenen Zahler zuordnen

   Datenverkehr zu Drittanbietern und Workers AI voneinander trennen. Für jede Drittanbieterroute festhalten, ob der Provider-Schlüssel mit der Anfrage eintreffen oder aus dem im Gateway gespeicherten Schlüssel default stammen soll. Eine Fail-Closed-Regel sollte erst aktiviert werden, wenn diese Zuständigkeit eindeutig ist.

2. 2

   Den kleinsten Geltungsbereich wählen

   Für einen einzelnen Pfad cf-aig-no-wholesale: true mitsenden. Für das gesamte Gateway AI > AI Gateway öffnen, das Gateway auswählen, unter Settings die Option Require provider credentials einschalten und bestätigen. Bei einem per API verwalteten Gateway steht byok_only: true in der Aktualisierungsanfrage.

3. 3

   Beide gültigen Zugangsdatenpfade nachweisen

   Eine Staging-Anfrage mit angehängtem Provider-Schlüssel senden. Danach eine Anfrage ausführen, die sich auf den gespeicherten Schlüssel unter default stützt. In beiden Fällen prüfen, ob das vorgesehene Provider-Konto die Nutzung erfasst. Falls der Unified-Billing-Endpunkt einen Schlüssel namens production verwendet, muss vor dem Fortfahren der Alias korrigiert werden.

4. 4

   Den Schlüssel absichtlich entfernen

   Im Staging dieselbe Drittanbieteranfrage ohne Provider-Schlüssel und ohne passenden gespeicherten default-Schlüssel senden. Erwartet wird HTTP 400 statt einer erfolgreichen Modellantwort. Außerdem prüfen, dass die Wiederholungslogik diesen Konfigurationsfehler nicht immer wieder sendet.

5. 5

   Fehler einer Person und einer Warteschlange zuweisen

   Für diesen HTTP 400 sollte die verantwortliche Person aus Integration oder Plattformbetrieb zuständig sein, denn dort werden Anfrage-Header, gespeicherte Secrets und Schlüsselrotation kontrolliert. Der Kundensupport kann den Fehler erklären und die Finanzabteilung ihn prüfen, doch die Behebung gehört nicht in eines dieser Teams.

Die tatsächlichen Zielkonflikte

Die Einstellung tauscht einen stillen Rückfall gegen einen sichtbaren Fehler. War Unified Billing bewusst als Verfügbarkeitspfad vorgesehen, entfällt diese Absicherung für Drittanbieteranfragen. Auch ein abgelaufener oder ungültiger Anfrageschlüssel wird an den Provider weitergeleitet, statt durch einen anderen Abrechnungspfad ersetzt zu werden; der vorgelagerte Provider kann ihn also weiterhin ablehnen.

Workers AI ist die entscheidende Ausnahme. Seine Anfragen verwenden keine Provider-Zugangsdaten von Drittanbietern, bleiben zulässig und behalten den separaten Abrechnungsmodus des Gateways für Workers AI. Die Aktivierung von byok_only ist kein globaler Schalter nach dem Motto „Cloudflare darf nichts berechnen“.

Auch Ausgabenlimits schließen nicht jede Lücke. Ihre Erfassung wird erst verzögert konsistent, sodass parallele Anfragen die Ausgaben kurzzeitig über ein Limit treiben können. Zudem werden Kosten anhand von Tokens und bekannten Modellpreisen geschätzt. Limits sind sinnvoll, exakte Belastungen sollten aber mit den Abrechnungsansichten des Providers und von Cloudflare abgeglichen werden.

Der nächste Schritt am Montag

Eine kundenfinanzierte Drittanbieterroute auswählen. Zuerst die Einschränkung auf Anfrageebene ergänzen und anschließend im Staging den Test mit fehlenden Zugangsdaten ausführen. Bestanden ist er, wenn HTTP 400 erscheint, kein Rückfall erfolgreich ist und der Fehler klar zugeordnet wurde. Diesen Fehler in die Warteschlange des Integrations- oder Plattformteams legen, eine verantwortliche Person für die Schlüsselreparatur benennen und erst danach erwägen, die Regel im gesamten Gateway zu aktivieren.

Nutzt das Team Cloudflare Unified Billing bewusst für den gesamten Drittanbieterverkehr, bleibt die Regel deaktiviert. Wer ausschließlich Workers AI verwendet, ändert mit dieser Einstellung nichts an dessen Abrechnung. Sollen hingegen Kunden- oder Abteilungskonten beim Provider zahlen, ist diese Woche der richtige Zeitpunkt zum Handeln: Der Fehler sollte getestet werden, bevor die nächste Schlüsselrotation den Test unfreiwillig übernimmt.

Weitere praxisnahe Einordnungen solcher Änderungen liefert der Newsletter.