Cloudflare hat AI Gateway eine kleine, aber wichtige Kontrolle hinzugefügt: Teams können jetzt Anmeldeinformationen von Drittanbietern anfordern, bevor eine Anfrage ausgeführt werden darf. Wenn das Gateway keine anwendbaren Anmeldeinformationen findet, schlägt die Anfrage mit HTTP 400 fehl, anstatt auf das von Cloudflare verwaltete Unified Billing zurückzugreifen.
Dadurch ändert sich die praktische Bedeutung von Bring-Your-Own-Key oder BYOK. Bisher konnte ein fehlender Anbieterschlüssel ein Konfigurationsproblem sein, das dennoch zu einem erfolgreichen Modellaufruf führte, allerdings unter einem anderen Abrechnungspfad. Mit der neuen Einstellung werden fehlende Anmeldeinformationen zu einem schwerwiegenden Richtlinienverstoß. Für Organisationen, die kundeneigene Modellkonten vom zentral abgerechneten Datenverkehr trennen, ist diese Unterscheidung wichtiger, als der Statuscode vermuten lässt.
Was sich geändert hat
Das Update von Cloudflare vom 14. September fügt zwei Möglichkeiten hinzu, das neue Verhalten durchzusetzen. Auf Gateway-Ebene können Administratoren eine byok_only-Einstellung aktivieren. Zum Zeitpunkt der Anfrage können Anrufer den Header cf-aig-no-wholesale senden, um einen Fallback bei der Großhandelsabrechnung für diese Anfrage zu verhindern.
Wenn die Kontrolle angewendet wird und die Anmeldeinformationen des Anbieters nicht verfügbar sind, gibt AI Gateway HTTP 400 zurück. Cloudflare gibt an, dass Workers AI-Anfragen weiterhin zulässig bleiben, daher bezieht sich die Richtlinie speziell auf Anfragen von Drittanbietern, die andernfalls über von Cloudflare verwaltete Anmeldeinformationen weitergeleitet werden könnten.
Die Funktion ist kein Router eines neuen Modells oder Preisnachlass. Es handelt sich um eine Leitplanke für den Abrechnungsmodus. Dies macht es direkt relevant für die einheitliche AI-API-Abrechnung, da ein einziges Gateway nun eine schärfere Grenze zwischen zentral abgerechnetem Datenverkehr und Anfragen ziehen kann, die dem eigenen Anbieterkonto eines Kunden in Rechnung gestellt werden müssen.
Warum ein Abrechnungs-Fallback riskant ist
Fallback ist praktisch, wenn die Priorität auf der Verfügbarkeit liegt. Wenn ein Provider-Zugangsdatensatz fehlt, abgelaufen ist oder nicht mit der richtigen Route verknüpft ist, kann ein vom Gateway verwalteter Zugangsdatensatz dafür sorgen, dass die Anwendung weiterhin funktioniert. Aber genau dieser Komfort kann zu einem unübersichtlichen Rechnungspfad führen.
Ein SaaS-Anbieter, eine Agentur oder ein internes Plattformteam kann versprechen, dass der Datenverkehr eines bestimmten Mieters nur über das OpenAI-, Anthropic-, Google- oder andere Anbieterkonto dieses Mieters läuft. Wenn das Gateway stattdessen stillschweigend einen Großhandels-Zugangsdatensatz verwendet, ist die Anfrage möglicherweise immer noch erfolgreich, aber die kommerzielle Bedeutung hat sich geändert. Der Plattformbetreiber übernimmt möglicherweise die Kosten, gibt sie falsch weiter oder verliert die Möglichkeit, die Nutzung mit der eigenen Anbieterrechnung des Kunden abzugleichen.
Dies ist besonders heikel für Reseller- und Partner-API-Modelle. Aufgrund von Beschaffungsvorschriften ist möglicherweise ein Kunde auf BYOK angewiesen. Ein anderer kann über die Plattform abgerechnete Credits verwenden. Ein Dritter benötigt möglicherweise aus regulatorischen oder Datenverwaltungsgründen separate Anbieterkonten. In dieser Umgebung ist der Abrechnungspfad Teil des Produktvertrags und kein Implementierungsdetail.
Mit der neuen Steuerung von Cloudflare haben Teams die Möglichkeit, diesen Vertrag an der Gateway-Grenze durchsetzbar zu machen. Eine fehlgeschlagene Anfrage ist betrieblich ärgerlich, lässt sich aber einfacher debuggen als eine erfolgreiche Anfrage, die später in der falschen Kostenstelle erscheint.
Wer ist betroffen?
Die unmittelbare Zielgruppe ist jedes Team, das Cloudflare AI Gateway mit einer Mischung aus anbietereigenen Anmeldeinformationen und von Cloudflare verwalteter Abrechnung verwendet. Die Änderung ist vor allem dann von Bedeutung, wenn mehrere Mandanten, Umgebungen oder Geschäftseinheiten eine Gateway-Konfiguration gemeinsam nutzen.
Entwickler müssen entscheiden, ob eine Route Verfügbarkeit oder strikte Abrechnungsisolierung bevorzugen soll. Finanz- und Betriebsteams erhalten einen saubereren Mechanismus zur Verhinderung einer versehentlichen Großhandelsnutzung. Sicherheits- und Plattformteams erhalten einen weiteren Hebel für die API-Schlüsselverwaltung, da das Vorhandensein oder Fehlen von Anbieteranmeldeinformationen nun eine direkte Durchsetzungswirkung hat.
Für KI-Gateway-Betreiber im weiteren Sinne ist das Update ein Signal. Abrechnungskontrollen werden zu Richtlinienkontrollen. Es reicht nicht mehr aus, nachzuweisen, dass bei einer Anfrage ein bestimmtes Modell verwendet wurde. Gateways müssen zunehmend aufzeichnen, welcher Anmeldeinformationspfad verwendet wurde, wem diese Anmeldeinformationen gehörten, welcher Mandant oder API-Schlüssel den Anruf initiierte und ob ein Fallback zulässig war.
Model Gate-Benutzer stehen vor dem gleichen zugrunde liegenden Problem, wenn sie Teams, API-Schlüssel, Nutzungsanalysen und Zugriff auf Partner verwalten. Ein kundenbezogener Schlüssel ist nicht nur ein Authentifizierungstoken; Dies kann einen Abrechnungsmodus, ein Ausgabenlimit, ein Anbieterkonto und eine Reihe von Prüfungserwartungen umfassen. Wenn diese Bedeutungen nicht konsequent durchgesetzt werden, können Analyse-Dashboards und Rechnungen von dem abweichen, was Kunden glauben, gekauft zu haben.
Praktische Konsequenzen
Die erste praktische Änderung ist die Fehlerbehandlung. Anwendungen, die nur BYOK-Kontrollen ermöglichen, sollten HTTP 400 vom Gateway als Konfigurations- oder Anmeldeinformationsproblem und nicht als Modellfehler behandeln.Das Wiederholen derselben Anfrage ohne Korrektur der Anmeldeinformationen kann nur zu Lärm führen.
Die zweite Änderung betrifft das Onboarding. Teams, die es Kunden ermöglichen, Anbieterschlüssel mitzubringen, benötigen einen strengeren Schritt zur Überprüfung der Anmeldeinformationen, bevor der Produktionsverkehr beginnt. Ein Mandant sollte während eines Live-Workflows nicht feststellen, dass sein Anbieterschlüssel nie an die Gateway-Route angehängt wurde.
Die dritte Änderung ist die Beobachtbarkeit. Gateway-Protokolle und Nutzungsberichte sollten offenlegen, ob eine Anfrage BYOK, Plattformabrechnung oder einen blockierten Fallback-Pfad verwendet hat. Ohne dieses Feld wissen Supportteams möglicherweise, dass eine Anfrage fehlgeschlagen ist, aber nicht, ob der Fehler eine Abrechnungsgrenze geschützt hat.
Abschließend sollten Partnerplattformen ihre Standardeinstellungen noch einmal überprüfen. Eine strikte Durchsetzung von BYOK ist nicht immer die richtige Wahl. Einige Produkte greifen möglicherweise bewusst auf die Plattformabrechnung zurück, um die Servicekontinuität zu gewährleisten. Andere erfordern möglicherweise aufgrund von Verträgen, Kundenvertrauen oder Margenschutz eine harte Trennung. Die wichtige Änderung besteht darin, dass die Entscheidung explizit und nicht zufällig erfolgen kann.
Was unklar bleibt
Die öffentliche Änderung beschreibt die Richtlinienmechanismen, aber Teams müssen weiterhin testen, wie sie sich über ihren eigenen Anbietermix, ihre Routenstruktur und ihr Modell zur Vererbung von Anmeldeinformationen hinweg verhält. Es ist auch noch nicht klar, wie weit Anwendungs-Frameworks und Observability-Tools von Drittanbietern diese Unterscheidung im Abrechnungsmodus in ihren Standard-Dashboards anzeigen werden.
Die größere Richtung ist klar genug. Multi-Modell-Gateways werden ebenso zu Finanzkontrollebenen wie API-Proxys. Die Nur-BYOK-Einstellung von Cloudflare ist eine eingeschränkte Funktion, behebt jedoch einen echten Fehlermodus: die Anfrage, die technisch funktioniert und gleichzeitig gegen das beabsichtigte Abrechnungsmodell verstößt.