Cloudflare AI Gateway evita cobranças na conta errada

O Cloudflare AI Gateway agora pode rejeitar uma solicitação quando falta a chave do provedor de modelo do cliente, antes que o consumo chegue à sua fatura da Cloudflare. Em 14 de setembro de 2026, o AI Gateway passou a exigir credenciais do provedor: uma solicitação a terceiros sem uma chave aplicável recebe HTTP 400, em vez de gerar uso no Unified Billing.

Como o Cloudflare AI Gateway define quem paga

Uma mesma solicitação de modelo pode passar por diferentes caminhos de credenciais no AI Gateway. É a credencial — a chave enviada ao provedor do modelo — que determina qual conta receberá a cobrança.

Antes dessa mudança, a sequência era simples. Primeiro, a Cloudflare procurava uma chave do provedor na própria solicitação. Se não encontrasse, buscava uma chave Bring Your Own Key, ou BYOK, armazenada no gateway com o alias default. Se nenhuma das duas existisse, podia recorrer às credenciais gerenciadas pela Cloudflare por meio do Unified Billing e descontar o uso do seu saldo de créditos da Cloudflare.

Esse último fallback é útil quando a intenção é que a Cloudflare seja a pagadora. Mas vira um vazamento de orçamento quando a solicitação pertence a um cliente que deveria fornecer a própria chave da OpenAI, Anthropic, Google ou de outro provedor.

Agora, a Cloudflare permite eliminar essa terceira etapa no tráfego para provedores externos. Ative Require provider credentials no gateway — representado como byok_only: true na API — e qualquer solicitação sem uma credencial aplicável do cliente será interrompida com HTTP 400. A mesma restrição pode ser aplicada a uma única solicitação com cf-aig-no-wholesale: true. A Cloudflare documenta aqui a ordem completa das credenciais e os dois controles.

A forma mais fácil de entender o fluxo é imaginar três possíveis pagadores em uma fila:

1. Credencial da solicitação: o cliente envia a chave do provedor junto com a chamada. O AI Gateway a encaminha sem alterações, e o provedor cobra da conta vinculada àquela chave.
2. Credencial armazenada no gateway: se a chamada chega sem uma chave do provedor, o AI Gateway usa uma chave salva no Cloudflare Secrets Store. Nos endpoints do Unified Billing, a chave armazenada aplicável precisa usar o alias default.
3. Cloudflare Unified Billing: se não houver uma chave aplicável do cliente nem uma chave armazenada, a Cloudflare poderá usar sua credencial gerenciada e descontar créditos da conta Cloudflare.

Com a nova regra, a fila termina depois da segunda etapa. Essa é toda a consequência para o negócio: credenciais ausentes deixam de provocar uma transferência invisível de custos e passam a gerar uma indisponibilidade visível.

O controle de gastos com IA saiu da conciliação e virou rejeição

O Unified Billing cobra uma taxa de 5% na compra de créditos. O exemplo da própria Cloudflare é direto: $100 em créditos resultam em uma cobrança de $105, enquanto o preço de inferência do provedor é repassado sem margem adicional.

Agora leve essa conta para um fluxo de trabalho de cliente. Se uma tarefa deveria usar a conta do provedor do próprio cliente, mas a chave desaparecesse, $100 em uso do modelo poderiam consumir os créditos da Cloudflare pertencentes à empresa que opera o serviço. Financiar esses créditos custaria $105. A conta do cliente no provedor não registraria nada desse uso de fallback, enquanto a operadora ficaria com toda a cobrança de $105 e ainda teria de provar qual cliente a causou.

A taxa de 5% não é o principal problema. O problema real é que toda a carga de $100 migrou para o orçamento errado. Os $5 adicionais apenas tornam o erro mais caro.

Exigir as credenciais do provedor transforma uma investigação financeira em um erro da aplicação. O resgate automático deixa de existir, mas surge uma fronteira rígida que define quem paga. Para uma comparação mais ampla entre as tarifas dos gateways e a cobrança direta dos provedores, consulte a análise de custos dos gateways de IA.

Quem deve usar esse controle

Uma agência que opera automações para clientes

Uma agência pode trabalhar com uma única conta Cloudflare enquanto cada cliente mantém seu próprio contrato com o provedor de modelos. Ative a regra do gateway nas rotas financiadas pelos clientes. Se faltar uma chave durante o onboarding ou se ela for removida em uma rotação, a tarefa será interrompida em vez de consumir o saldo pré-pago da agência.

O benefício é deixar clara a responsabilidade pela cobrança. O cliente fornece uma credencial válida ou recebe um erro de configuração. A agência não precisa mais reconstruir uma fatura de créditos compartilhada depois que o trabalho já foi executado.

Uma equipe de SaaS que aceita chaves fornecidas pelo cliente

Um produto SaaS que recebe chaves de provedores dos próprios clientes pode tratar o HTTP 400 como um estado de configuração. O produto informa ao cliente que a credencial do provedor está ausente e mantém a solicitação fora do saldo de créditos da Cloudflare pertencente à plataforma.

Isso é especialmente útil quando uma resposta bem-sucedida esconderia o erro. Sem a restrição, o recurso continua funcionando, mas a empresa errada paga. Com ela, o produto falha cedo o bastante para que a configuração da conta seja corrigida.

Um engenheiro de plataforma que começa por uma única rota

O cabeçalho da solicitação oferece a menor superfície para uma implantação gradual. Adicione cf-aig-no-wholesale: true a um caminho de solicitações para terceiros, teste o comportamento sem a chave e conecte o erro ao monitoramento antes de aplicar a mudança ao gateway inteiro.

A precedência funciona de propósito em uma única direção. Um cabeçalho de solicitação pode tornar mais rígido um gateway permissivo. Já uma solicitação não pode definir o cabeçalho como false e enfraquecer um gateway no qual Require provider credentials já esteja ativo. A Cloudflare descreve essas restrições como cumulativas.

Um responsável por FinOps que separa quem paga de quanto pode ser gasto

Use esta configuração para decidir qual conta pode pagar. Use os limites de gastos do AI Gateway para definir quanto pode ser gasto. São controles distintos e precisam de testes diferentes.

Os limites de gastos podem abranger solicitações BYOK e Unified Billing quando a Cloudflare conhece o preço do modelo. Também podem ser definidos por modelo, provedor ou metadados. Ainda assim, o custo é uma estimativa aproximada, e a Cloudflare orienta o uso do painel do provedor para conferir a cobrança exata. Trate a regra de credenciais do provedor como a fronteira entre pagadores e valide o teto de gastos separadamente.

Configure sem criar uma indisponibilidade misteriosa

1. 1

   Relacione cada rota ao pagador previsto

   Separe o tráfego para provedores externos do Workers AI. Em cada rota de terceiros, registre se a chave do provedor deve chegar na solicitação ou vir da chave default armazenada no gateway. Não ative uma regra que bloqueia por padrão antes de explicitar essa responsabilidade.

2. 2

   Escolha o menor escopo de aplicação

   Para um único caminho, envie cf-aig-no-wholesale: true. Para o gateway inteiro, acesse AI > AI Gateway, selecione o gateway, abra Settings, ative Require provider credentials e confirme. Um gateway gerenciado por API usa byok_only: true na solicitação de atualização.

3. 3

   Comprove os dois caminhos válidos de credenciais

   Envie uma solicitação de staging com a chave do provedor anexada. Em seguida, envie outra que dependa da chave armazenada com o alias default. Confirme, nos dois casos, se a conta correta do provedor registra o uso. Se o seu endpoint do Unified Billing depender de uma chave chamada production, corrija o alias antes de continuar.

4. 4

   Remova a chave de propósito

   Em staging, envie a mesma solicitação a terceiros sem uma chave do provedor e sem uma chave default armazenada que seja aplicável. O resultado esperado é HTTP 400, não uma resposta bem-sucedida do modelo. Confirme que sua política de retentativa não continue repetindo esse erro de configuração.

5. 5

   Atribua o erro a uma pessoa e a uma fila

   Responsabilize por esse HTTP 400 a pessoa que cuida da integração ou da plataforma, pois é ela quem controla os cabeçalhos das solicitações, os segredos armazenados e a rotação de chaves. O suporte ao cliente pode explicar a falha, e a equipe financeira pode auditá-la, mas nenhuma dessas equipes deve ser dona da correção.

Os trade-offs, sem rodeios

Esta configuração troca um fallback silencioso por uma falha visível. Se o Unified Billing era seu caminho deliberado de disponibilidade, ativá-la remove esse resgate das solicitações a provedores externos. Uma chave expirada ou inválida presente na solicitação também é encaminhada ao provedor, em vez de ser substituída por outro caminho de cobrança; portanto, o provedor ainda pode rejeitá-la.

Workers AI é a exceção importante. Como suas solicitações não usam credenciais de provedores externos, elas continuam permitidas e mantêm o modo de cobrança separado configurado para o Workers AI. Ativar byok_only não funciona como um botão global de “nada pode ser cobrado da Cloudflare”.

Os limites de gastos também não eliminam todas as brechas. A contabilização tem consistência eventual, então solicitações simultâneas podem fazer o gasto ultrapassar brevemente um limite. Além disso, eles estimam o custo com base nos tokens e nos preços conhecidos dos modelos. Use esses limites, mas confira os valores exatos nas áreas de cobrança do provedor e da Cloudflare.

O que fazer na segunda-feira

Escolha uma rota para terceiros financiada pelo cliente. Primeiro, adicione a restrição no nível da solicitação; depois, execute em staging o teste sem credenciais. O critério de aprovação é um HTTP 400 com responsável definido e sem fallback bem-sucedido. Coloque esse erro na fila da equipe de integração ou plataforma, defina quem consertará a chave e só então considere ativar a regra no gateway inteiro.

Se a sua equipe usa intencionalmente o Cloudflare Unified Billing para todo o tráfego de terceiros, deixe a regra desativada. Se usa apenas o Workers AI, essa configuração não muda a fatura. Se são as contas dos provedores de clientes ou departamentos que devem pagar, tome uma providência nesta semana e teste a falha antes que a próxima rotação de chaves faça isso por você.

Para receber mais análises práticas de mudanças como esta, assine a newsletter.