Cloudflare has added a control to AI Gateway that lets operators require provider credentials on third-party model requests. The change is small in interface terms, but it addresses a practical governance problem for teams routing AI traffic through a gateway: what should happen when a customer, project, or tenant has not supplied a valid provider key?
Before this update, Cloudflare AI Gateway could use its Unified Billing setup as a fallback path for supported third-party providers. That can be convenient when a request would otherwise fail, but it can also blur cost attribution and compliance boundaries. The new BYOK-only setting lets gateway owners prevent that fallback and require that requests use explicitly supplied bring-your-own-key credentials instead.
Cloudflare says the setting can be enabled in the dashboard or through the API with byok_only=true. It also added a per-request header, cf-aig-no-wholesale, for cases where teams want to block wholesale or Cloudflare-managed credential use on individual calls.
What changed
The September 14 AI Gateway changelog introduces a credential requirement for third-party provider requests. When enabled, the gateway will not silently fall back to Cloudflare-managed Unified Billing credentials if the caller has not provided acceptable provider credentials.
That distinction matters because AI gateways increasingly sit between many internal applications, external customers, and multiple model providers. A missing key is not just a technical failure mode. It can decide which legal entity is billed, which account’s provider quota is consumed, and whether usage appears in the right cost center.
The new control gives platform teams a stricter operating mode. Instead of treating missing customer credentials as a routing inconvenience, the gateway can treat them as a policy violation. That is especially relevant for reseller setups, customer-owned-key deployments, and enterprise environments where the provider relationship needs to remain directly tied to a business unit or tenant.
Why it matters for AI gateway operators
AI gateway design has often focused on routing, latency, caching, retries, and model abstraction. Billing behavior deserves the same attention. If a gateway automatically changes credential mode when one path is unavailable, downstream reporting can become misleading. A request may look like ordinary application traffic while the invoice lands somewhere else.
For businesses operating a central AI API cost control layer, that creates operational risk. Finance teams may lose clean chargeback data. Security teams may not know which credential was actually used. Product teams may struggle to explain why one tenant’s usage was billed through a platform account instead of that tenant’s own provider account.
BYOK-only mode also helps with customer commitments. Some buyers require that their own provider contracts, data-processing terms, or regional settings govern model calls. If a gateway can fall back to a managed billing credential, that commitment becomes harder to enforce unless the fallback is disabled by policy.
The per-request header adds a more granular option. A platform can keep broader Unified Billing behavior available for some workloads while preventing it for requests that carry stricter compliance, reseller, or attribution requirements. That gives developers a migration path without forcing every application onto the strictest mode at once.
Who is affected
The immediate audience is any team using Cloudflare AI Gateway to proxy requests to third-party AI providers. The change is most relevant where multiple teams, tenants, or customers share a gateway and where provider credentials are expected to be owned outside the central platform account.
Enterprise AI platform teams should review whether their gateway behavior matches internal policy. If a project is supposed to use its own OpenAI, Anthropic, Google, Mistral, or other provider account, the gateway should make that dependency visible and enforceable. A fallback that helps a demo succeed can become a problem in production if it hides broken credential setup.
Resellers and partner platforms have a sharper version of the same issue. If customers bring their own provider keys, platform operators need confidence that traffic is not accidentally converted into platform-billed usage. Otherwise, margins, invoices, audit records, and customer trust can all be affected.
Developers are affected too, though mostly through clearer failure modes. With BYOK-only enforcement, a request that lacks proper credentials should fail rather than route through an alternative billing path. That may require better onboarding checks, clearer error handling, and deployment tests that verify provider keys before traffic goes live.
Practical consequences
The first practical step is policy inventory. Teams should decide which workloads are allowed to use Cloudflare-managed Unified Billing and which must use customer-owned or project-owned provider credentials. That decision should be explicit, not left to default gateway behavior.
The second step is observability. Logs and usage analytics should record which credential mode was used, whether a request was blocked because BYOK-only was enabled, and which tenant or project supplied the key. Without that visibility, a stricter control can reduce billing ambiguity but still leave operators with poor troubleshooting data.
The third step is developer workflow. Applications that depend on AI Gateway should fail early when credentials are missing. A startup check, deployment validation, or admin-console warning is better than discovering the issue after a production request is rejected.
The remaining uncertainty is less about the feature itself and more about adoption patterns. Cloudflare has documented the new control, but each operator still has to decide where to apply it. Some teams will prefer the resilience of fallback billing for internal experiments. Others will make BYOK-only the default for production tenant traffic. The important change is that this is now a governance choice rather than an implicit behavior hidden inside the routing layer.