Cloudflare har lagt til en kontroll til AI Gateway som lar operatører kreve leverandørlegitimasjon på tredjeparts modellforespørsler. Endringen er liten når det gjelder grensesnitt, men den løser et praktisk styringsproblem for team som ruter AI-trafikk gjennom en gateway: hva skal skje når en kunde, et prosjekt eller en leietaker ikke har oppgitt en gyldig leverandørnøkkel?
Før denne oppdateringen kunne Cloudflare AI Gateway bruke Unified Billing-oppsettet som en reservevei for støttede tredjepartsleverandører. Det kan være praktisk når en forespørsel ellers ville mislykkes, men det kan også viske ut kostnadsattribusjon og samsvarsgrenser. Den nye BYOK-bare-innstillingen lar gateway-eiere forhindre tilbakefall og krever at forespørsler bruker eksplisitt oppgitt ta med-din-egen-nøkkel-legitimasjon i stedet.
Cloudflare sier at innstillingen kan aktiveres i dashbordet eller gjennom API med byok_only=true. Den har også lagt til en overskrift per forespørsel, cf-aig-no-wholesale, for tilfeller der team ønsker å blokkere engros- eller Cloudflare-administrert legitimasjonsbruk på individuelle samtaler.
Hva endret
14. september AI Gateway-endringsloggen introduserer et krav om legitimasjon for tredjeparter. Når den er aktivert, vil gatewayen ikke stille tilbake til Cloudflare-administrert Unified Billing-legitimasjon hvis innringeren ikke har oppgitt akseptabel leverandørlegitimasjon.
Denne forskjellen er viktig fordi AI-gatewayer i økende grad sitter mellom mange interne applikasjoner, eksterne kunder og flere modellleverandører. En manglende nøkkel er ikke bare en teknisk feilmodus. Den kan bestemme hvilken juridisk enhet som faktureres, hvilken kontos leverandørkvote som forbrukes, og om bruk vises i riktig kostnadssenter.
Den nye kontrollen gir plattformteam en strengere driftsmodus. I stedet for å behandle manglende kundelegitimasjon som en rutinguleilighet, kan gatewayen behandle dem som et brudd på retningslinjene. Dette er spesielt relevant for forhandleroppsett, kundeeide nøkkeldistribusjoner og bedriftsmiljøer der leverandørforholdet må forbli direkte knyttet til en forretningsenhet eller leietaker.
Hvorfor er det viktig for AI-gatewayoperatører
AI-gatewaydesign har ofte fokusert på ruting, latens, hurtigbufring, gjenforsøk og modellabstraksjon. Faktureringsatferd fortjener samme oppmerksomhet. Hvis en gateway automatisk endrer legitimasjonsmodus når én bane er utilgjengelig, kan nedstrømsrapportering bli villedende. En forespørsel kan se ut som vanlig programtrafikk mens fakturaen lander et annet sted.
For bedrifter som driver et sentral AI API-kostnadskontroll-lag, skaper det operasjonell risiko. Økonomiteam kan miste rene tilbakeføringsdata. Sikkerhetsteam vet kanskje ikke hvilken legitimasjon som faktisk ble brukt. Produktteam kan slite med å forklare hvorfor én leietakers bruk ble fakturert via en plattformkonto i stedet for den leietakerens egen leverandørkonto.
Bare BYOK-modus hjelper også med kundeforpliktelser. Noen kjøpere krever at deres egne leverandørkontrakter, databehandlingsvilkår eller regionale innstillinger styrer modellanrop. Hvis en gateway kan falle tilbake til en administrert faktureringslegitimasjon, blir denne forpliktelsen vanskeligere å håndheve med mindre reserven er deaktivert av retningslinjer.
Toppteksten per forespørsel legger til et mer detaljert alternativ. En plattform kan holde bredere Unified Billing-atferd tilgjengelig for enkelte arbeidsbelastninger, samtidig som den forhindrer den for forespørsler som har strengere krav til overholdelse, forhandler eller attribusjon. Det gir utviklere en migreringsbane uten å tvinge alle apper til den strengeste modusen samtidig.
Hvem er berørt
Den umiddelbare målgruppen er ethvert team som bruker Cloudflare AI Gateway til proxy-forespørsler til tredjeparts AI-leverandører. Endringen er mest relevant der flere team, leietakere eller kunder deler en gateway og hvor leverandørlegitimasjon forventes å eies utenfor den sentrale plattformkontoen.
Enterprise AI-plattformteam bør vurdere om deres gateway-atferd samsvarer med interne retningslinjer. Hvis et prosjekt skal bruke sin egen OpenAI-, Anthropic-, Google-, Mistral- eller annen leverandørkonto, bør gatewayen gjøre denne avhengigheten synlig og håndhevbar. En reserve som hjelper en demo til å lykkes, kan bli et problem i produksjonen hvis den skjuler ødelagt legitimasjonsoppsett.
Forhandlere og partnerplattformer har en skarpere versjon av det samme problemet. Hvis kunder tar med sine egne leverandørnøkler, trenger plattformoperatører tillit til at trafikk ikke ved et uhell konverteres til plattformfakturert bruk. Ellers kan marginer, fakturaer, revisjonsposter og kundetillit bli påvirket.
Utviklere blir også berørt, men mest gjennom klarere feilmoduser. Med kun BYOK-håndhevelse bør en forespørsel som mangler riktig legitimasjon mislykkes i stedet for å gå gjennom en alternativ faktureringsvei.Det kan kreve bedre introduksjonskontroller, klarere feilhåndtering og distribusjonstester som bekrefter leverandørnøkler før trafikken publiseres.
Praktiske konsekvenser
Det første praktiske trinnet er policyinventar. Teamene bør bestemme hvilke arbeidsbelastninger som er tillatt å bruke Cloudflare-administrert Unified Billing og hvilke som må bruke kundeeid eller prosjekteid leverandørlegitimasjon. Denne avgjørelsen bør være eksplisitt, ikke overlatt til standard gateway-atferd.
Det andre trinnet er observerbarhet. Logger og bruksanalyse skal registrere hvilken legitimasjonsmodus som ble brukt, om en forespørsel ble blokkert fordi BYOK-only var aktivert, og hvilken leietaker eller prosjekt som leverte nøkkelen. Uten den synligheten kan en strengere kontroll redusere faktureringstvetydighet, men likevel etterlate operatører med dårlige feilsøkingsdata.
Det tredje trinnet er arbeidsflyten for utviklere. Apper som er avhengige av AI Gateway bør mislykkes tidlig når legitimasjon mangler. En oppstartssjekk, distribusjonsvalidering eller admin-konsoll-advarsel er bedre enn å oppdage problemet etter at en produksjonsforespørsel er avvist.
Den gjenværende usikkerheten er mindre om selve funksjonen og mer om adopsjonsmønstre. Cloudflare har dokumentert den nye kontrollen, men hver operatør må fortsatt bestemme hvor den skal brukes. Noen team vil foretrekke robustheten til reservefakturering for interne eksperimenter. Andre vil gjøre BYOK-kun standard for produksjonsleietrafikk. Den viktige endringen er at dette nå er et styringsvalg snarere enn en implisitt atferd skjult inne i rutinglaget.