Cloudflare AI Gateway : bloquez les requêtes sans clé avant la facture

Cloudflare AI Gateway peut désormais faire échouer une requête si la clé fournisseur du client manque, avant que celle-ci ne soit portée sur votre facture Cloudflare. Depuis le 14 septembre 2026, AI Gateway permet d’exiger les identifiants du fournisseur : toute requête vers un service tiers dépourvue de clé applicable reçoit alors une réponse HTTP 400, au lieu de passer par Unified Billing.

Cloudflare AI Gateway change l’identité du payeur

AI Gateway peut acheminer une même requête de modèle selon plusieurs parcours d’authentification. La clé utilisée indique au fournisseur de modèles quel compte doit régler l’usage.

Avant ce changement, l’ordre était simple. Cloudflare cherchait d’abord une clé fournisseur dans la requête. À défaut, le service recherchait un identifiant Bring Your Own Key, ou BYOK, enregistré dans la passerelle sous l’alias default. Si aucun des deux n’était disponible, il pouvait utiliser les identifiants gérés par Cloudflare via Unified Billing et déduire la consommation de votre solde de crédits Cloudflare.

Ce dernier recours est pratique lorsque Cloudflare doit payer. Il devient une fuite budgétaire si la requête vient d’un client censé fournir sa propre clé OpenAI, Anthropic, Google ou celle d’un autre fournisseur.

Cloudflare permet maintenant de supprimer cette troisième étape pour le trafic destiné à des fournisseurs tiers. Activez Require provider credentials sur la passerelle — l’API représente ce réglage par byok_only: true — et toute requête sans identifiant client applicable s’arrêtera avec une réponse HTTP 400. La même restriction peut être imposée à une seule requête avec cf-aig-no-wholesale: true. Cloudflare détaille ici l’ordre complet des identifiants et ces deux contrôles.

Le plus simple est d’imaginer trois payeurs possibles, placés dans cet ordre :

1. Identifiant de la requête : le client joint sa clé fournisseur à l’appel. AI Gateway la transmet telle quelle ; le fournisseur facture donc le compte associé à cette clé.
2. Identifiant enregistré dans la passerelle : si l’appel ne contient aucune clé fournisseur, AI Gateway utilise une clé conservée dans Cloudflare Secrets Store. Pour les endpoints Unified Billing, la clé enregistrée applicable doit porter l’alias default.
3. Cloudflare Unified Billing : si aucun identifiant client ou enregistré ne s’applique, Cloudflare peut utiliser son propre identifiant géré et déduire la dépense du compte Cloudflare.

La nouvelle règle met fin à la file après la deuxième étape. Voilà toute sa portée économique : un identifiant manquant devient une interruption visible, et non plus un transfert de coûts silencieux.

La dépense n’est plus à rapprocher : la requête est rejetée

Unified Billing ajoute 5% de frais à l’achat de crédits. L’exemple de Cloudflare est limpide : $100 de crédits entraînent un débit de $105, tandis que le prix d’inférence du fournisseur est répercuté sans marge.

Appliquons ce mécanisme au workflow d’un client. Si une tâche devait utiliser le compte fournisseur de ce client, mais que sa clé disparaît, $100 d’utilisation du modèle peuvent être prélevés sur les crédits Cloudflare de l’opérateur. Alimenter ce solde lui coûte $105. Le compte du client chez le fournisseur ne consigne aucune trace de cet usage de secours ; l’opérateur supporte l’intégralité du débit de $105, puis doit encore déterminer quel client l’a provoqué.

Les 5% de frais ne constituent pas le cœur du problème. Le vrai problème est que la totalité des $100 de consommation a été transférée au mauvais budget. Les $5 supplémentaires ne font qu’alourdir l’erreur.

Exiger les identifiants du fournisseur transforme une enquête financière en erreur applicative. Le secours automatique disparaît, mais la frontière entre les payeurs devient stricte. Pour comparer plus largement les frais des passerelles et la facturation directe par les fournisseurs, consultez ce comparatif des coûts des passerelles IA.

À qui ce réglage est-il destiné ?

Une agence qui exploite les automatisations de ses clients

Une agence peut administrer un seul compte Cloudflare alors que chaque client dispose de son propre contrat avec un fournisseur de modèles. Activez la règle de la passerelle sur les routes financées par les clients. Si une clé a été oubliée pendant l’intégration ou supprimée lors d’une rotation, la tâche s’arrêtera au lieu de puiser dans le solde prépayé de l’agence.

Le payeur ne fait alors plus aucun doute. Soit le client fournit un identifiant valide, soit il reçoit une erreur de configuration. L’agence n’a plus à reconstituer après coup l’origine des dépenses sur une facture de crédits partagée.

Une équipe SaaS qui accepte les clés de ses clients

Un produit SaaS alimenté par les clés fournisseur de ses clients peut traiter la réponse HTTP 400 comme un état de configuration. Il peut signaler au client que son identifiant fournisseur manque, tout en empêchant la requête d’entamer la réserve de crédits Cloudflare de la plateforme.

C’est particulièrement utile lorsqu’une réponse réussie masquerait l’erreur. Sans cette restriction, la fonctionnalité continue de marcher, mais la mauvaise entreprise paie. Avec elle, l’échec survient assez tôt pour corriger la configuration du compte.

Un ingénieur plateforme qui commence par une seule route

L’en-tête de requête offre le périmètre de déploiement le plus réduit. Ajoutez cf-aig-no-wholesale: true à un parcours tiers, testez le comportement en l’absence de clé et reliez l’erreur à votre supervision avant de modifier toute la passerelle.

La priorité ne fonctionne que dans un sens. Un en-tête peut rendre une passerelle permissive plus stricte. En revanche, une requête ne peut pas définir cet en-tête sur false pour assouplir une passerelle où Require provider credentials est déjà activé. Cloudflare précise que ces restrictions se cumulent.

Un responsable FinOps qui distingue le payeur du budget

Ce réglage sert à décider quel compte est autorisé à payer. Les limites de dépenses d’AI Gateway servent, elles, à plafonner le montant dépensé. Ces contrôles répondent à deux objectifs différents et doivent être testés séparément.

Les limites de dépenses peuvent couvrir les requêtes BYOK comme Unified Billing lorsque Cloudflare connaît le prix du modèle. Leur périmètre peut être défini par modèle, fournisseur ou métadonnée. Mais le coût reste une estimation indicative, et Cloudflare recommande de consulter le tableau de bord du fournisseur pour connaître la facture exacte. Considérez donc l’exigence d’identifiants comme la frontière entre les payeurs, puis vérifiez séparément le plafond de dépenses.

Configurer Cloudflare AI Gateway sans provoquer une panne incompréhensible

1. 1

   Associer chaque route au payeur prévu

   Séparez le trafic destiné aux fournisseurs tiers de Workers AI. Pour chaque route tierce, consignez si la clé fournisseur doit accompagner la requête ou provenir de la clé default enregistrée dans la passerelle. N’activez pas un blocage par défaut tant que cette responsabilité n’est pas explicite.

2. 2

   Choisir le périmètre d’application le plus réduit

   Pour un seul parcours, envoyez cf-aig-no-wholesale: true. Pour toute la passerelle, ouvrez AI > AI Gateway, sélectionnez la passerelle, ouvrez Settings, activez Require provider credentials, puis confirmez. Avec une passerelle administrée par API, la requête de mise à jour utilise byok_only: true.

3. 3

   Valider les deux parcours d’authentification autorisés

   Envoyez en préproduction une requête avec la clé fournisseur jointe. Envoyez-en ensuite une autre qui utilise la clé enregistrée sous default. Vérifiez dans chaque cas que l’usage apparaît sur le compte fournisseur prévu. Si votre endpoint Unified Billing dépend d’une clé nommée production, corrigez l’alias avant de poursuivre.

4. 4

   Retirer volontairement la clé

   En préproduction, envoyez la même requête vers un fournisseur tiers sans clé fournisseur ni clé default enregistrée applicable. Le résultat attendu est une réponse HTTP 400, pas une réponse réussie du modèle. Vérifiez que votre politique de nouvelle tentative ne répète pas indéfiniment cette erreur de configuration.

5. 5

   Attribuer l’erreur à une personne et à une file

   Confiez cette réponse HTTP 400 au responsable de l’intégration ou de la plateforme, puisqu’il maîtrise les en-têtes de requête, les secrets enregistrés et la rotation des clés. Le support client peut expliquer l’échec et la finance peut l’auditer, mais aucune de ces équipes ne doit être chargée de le corriger.

Les vrais compromis

Ce réglage remplace un repli silencieux par un échec visible. Si Unified Billing constituait volontairement votre solution de continuité, son activation supprime ce secours pour les requêtes vers des fournisseurs tiers. Par ailleurs, une clé jointe à la requête qui a expiré ou n’est pas valide sera transmise au fournisseur au lieu d’être remplacée par un autre mode de facturation ; le fournisseur peut donc toujours la refuser.

Workers AI est l’exception à retenir. Ses requêtes n’utilisent pas les identifiants de fournisseurs tiers : elles restent autorisées et conservent le mode de facturation Workers AI configuré séparément sur la passerelle. Activer byok_only ne revient donc pas à garantir que « rien ne peut être facturé à Cloudflare ».

Les limites de dépenses ne comblent pas non plus toutes les brèches. Leur comptabilisation est cohérente à terme : des requêtes simultanées peuvent donc faire brièvement dépasser une limite. Elles estiment également le coût à partir du nombre de tokens et des prix de modèles connus. Utilisez-les, mais rapprochez les montants exacts des interfaces de facturation du fournisseur et de Cloudflare.

L’action à mener dès lundi

Choisissez une route vers un fournisseur tiers financée par un client. Commencez par ajouter la restriction au niveau de la requête, puis simulez l’absence d’identifiant en préproduction. Pour réussir le test, vous devez obtenir une réponse HTTP 400 attribuée à une équipe, sans repli réussi. Placez cette erreur dans la file de l’équipe d’intégration ou de plateforme, désignez la personne chargée de réparer la clé, puis seulement envisagez d’activer la règle sur toute la passerelle.

Si votre équipe choisit délibérément Cloudflare Unified Billing pour tout le trafic tiers, laissez la règle désactivée. Si vous utilisez uniquement Workers AI, ce réglage ne change rien à cette facture. Si les comptes fournisseur des clients ou des départements sont censés payer, intervenez cette semaine et testez l’échec avant que la prochaine rotation de clés ne le fasse à votre place.

Pour recevoir d’autres analyses directement exploitables de changements comme celui-ci, inscrivez-vous à la newsletter.