Cloudflare dodał niewielką, ale ważną kontrolę do AI Gateway: zespoły mogą teraz wymagać poświadczeń dostawcy zewnętrznego, zanim żądanie będzie mogło zostać uruchomione. Jeśli brama nie znajdzie odpowiednich danych uwierzytelniających, żądanie zakończy się niepowodzeniem przy użyciu protokołu HTTP 400, zamiast powrócić do ujednoliconego rozliczenia zarządzanego przez Cloudflare.
Zmienia to praktyczne znaczenie „przynieś własny klucz”, czyli BYOK. Do tej pory brak klucza dostawcy mógł być problemem konfiguracyjnym, który nadal generował pomyślne wywołanie modelu, ale w ramach innej ścieżki rozliczeniowej. Dzięki nowemu ustawieniu brakujące dane uwierzytelniające stają się poważnym naruszeniem zasad. W przypadku organizacji, które oddzielają konta modelowe należące do klientów od ruchu rozliczanego centralnie, to rozróżnienie ma większe znaczenie, niż sugeruje kod stanu.
Co się zmieniło
Aktualizacja Cloudflare z 14 września dodaje dwa sposoby egzekwowania nowego zachowania. Na poziomie bramy administratorzy mogą włączyć ustawienie byok_only. W momencie żądania osoby dzwoniące mogą wysłać nagłówek cf-aig-no-wholesale, aby zapobiec zastępczemu rozliczeniu hurtowemu dla tego żądania.
Gdy kontrola zostanie zastosowana, a dane uwierzytelniające dostawcy nie są dostępne, AI Gateway zwraca HTTP 400. Cloudflare twierdzi, że żądania AI Workers pozostają dozwolone, więc zasady dotyczą w szczególności żądań dostawców zewnętrznych, które w przeciwnym razie mogłyby być przesyłane przez poświadczenia zarządzane przez Cloudflare.
Ta funkcja nie dotyczy nowego modelu routera ani cen. rabat. Jest to poręcz w trybie rozliczeniowym. To sprawia, że ma to bezpośrednie zastosowanie w przypadku ujednoliconego rozliczeń API AI, ponieważ pojedyncza brama może teraz wytyczyć ostrzejszą granicę między centralnie rozliczanym ruchem a żądaniami, którymi należy obciążyć własne konto dostawcy klienta.
Dlaczego rezerwowe rozliczenia są ryzykowne
Rezerwacja awaryjna jest wygodna, gdy priorytetem jest czas pracy. Jeśli brakuje poświadczeń dostawcy, wygasły lub nie są dołączone do właściwej trasy, poświadczenia zarządzane przez bramę mogą zapewnić działanie aplikacji. Ale ta sama wygoda może spowodować bałagan na fakturze.
Dostawca SaaS, agencja lub zespół platformy wewnętrznej może obiecać, że ruch danego najemcy będzie generowany wyłącznie w ramach konta OpenAI, Anthropic, Google lub innego dostawcy tego najemcy. Jeśli zamiast tego brama dyskretnie użyje poświadczeń hurtowych, żądanie może nadal zostać zrealizowane, ale znaczenie komercyjne uległo zmianie. Operator platformy może przejąć koszty, przekazać je nieprawidłowo lub utracić możliwość pogodzenia wykorzystania z rachunkiem dostawcy własnego klienta.
Jest to szczególnie wrażliwe w przypadku modeli API sprzedawców i partnerów. Jeden klient może korzystać z BYOK ze względu na zasady zamówień. Inny może skorzystać ze środków rozliczanych na platformie. Trzeci może wymagać oddzielnych kont dostawców ze względów regulacyjnych lub związanych z zarządzaniem danymi. W tym środowisku ścieżka rozliczeniowa stanowi część umowy dotyczącej produktu, a nie szczegół implementacji.
Nowa kontrola Cloudflare umożliwia zespołom zapewnienie wykonalności umowy na granicy bramy. Nieudane żądanie jest denerwujące pod względem operacyjnym, ale łatwiej je debugować niż udane żądanie, które później pojawia się w niewłaściwym centrum kosztów.
Kogo dotyczy
Bezpośrednim odbiorcą jest dowolny zespół korzystający z Cloudflare AI Gateway z połączeniem danych uwierzytelniających należących do dostawcy i rozliczeń zarządzanych przez Cloudflare. Zmiana ma największe znaczenie, gdy wielu najemców, środowisk lub jednostek biznesowych korzysta z tej samej konfiguracji bramy.
Programiści będą musieli zdecydować, czy trasa powinna preferować dostępność, czy ścisłą izolację rozliczeń. Zespoły finansowe i operacyjne zyskują przejrzysty mechanizm zapobiegania przypadkowemu użyciu hurtowemu. Zespoły ds. bezpieczeństwa i platform zyskują kolejną dźwignię do zarządzania kluczami API, ponieważ obecność lub brak danych uwierzytelniających dostawcy ma teraz bezpośredni skutek w postaci egzekwowania prawa.
Dla szerzej operatorów bram AI aktualizacja jest sygnałem. Kontrole rozliczeniowe stają się kontrolami opartymi na zasadach. Nie wystarczy już wykazanie, że w żądaniu wykorzystano konkretny model. Bramy coraz częściej muszą rejestrować, która ścieżka poświadczeń została użyta, kto był właścicielem tych poświadczeń, który dzierżawca lub klucz interfejsu API zainicjował połączenie oraz czy dozwolone było rozwiązanie awaryjne.
Użytkownicy Model Gate napotykają ten sam podstawowy problem, zarządzając zespołami, kluczami API, analityką użycia i dostępem skierowanym do partnerów. Klucz o zasięgu klienta to nie tylko token uwierzytelniający; może to oznaczać tryb rozliczeniowy, limit wydatków, konto dostawcy i zestaw oczekiwań audytowych. Jeśli te znaczenia nie będą konsekwentnie egzekwowane, pulpity analityczne i faktury mogą odbiegać od tego, co według klientów kupili.
Praktyczne konsekwencje
Pierwszą praktyczną zmianą jest obsługa błędów. Aplikacje umożliwiające sterowanie wyłącznie BYOK powinny traktować protokół HTTP 400 z bramy jako problem z konfiguracją lub poświadczeniami, a nie jako awarię modelu.Ponowna próba wykonania tego samego żądania bez naprawienia danych uwierzytelniających może jedynie spowodować zamieszanie.
Druga zmiana dotyczy wdrożenia. Zespoły, które pozwalają klientom przynosić klucze dostawców, wymagają silniejszego etapu weryfikacji danych uwierzytelniających przed rozpoczęciem ruchu produkcyjnego. Dzierżawca nie powinien odkrywać podczas aktywnego przepływu pracy, że jego klucz dostawcy nigdy nie został dołączony do trasy bramy.
Trzecia zmiana to obserwowalność. Dzienniki bramy i raporty użytkowania powinny ujawniać, czy żądanie korzystało z BYOK, rozliczeń platformy czy zablokowanej ścieżki zastępczej. Bez tego pola zespoły pomocy technicznej mogą wiedzieć, że żądanie nie powiodło się, ale nie wiedzieć, czy awaria chroni granicę rozliczeniową.
Na koniec platformy partnerskie powinny ponownie sprawdzić swoje ustawienia domyślne. Ścisłe egzekwowanie BYOK nie zawsze jest właściwym wyborem. Niektóre produkty mogą celowo korzystać z rozliczeń platformowych, aby zachować ciągłość usług. Inni mogą potrzebować twardej separacji ze względu na umowy, zaufanie klientów lub ochronę marży. Ważną zmianą jest to, że decyzja może być wyraźna, a nie przypadkowa.
Co pozostaje niejasne
Zmiana publiczna opisuje mechanikę polityki, ale zespoły nadal będą musiały przetestować, jak się zachowuje w odniesieniu do własnego zestawu dostawców, struktury tras i modelu dziedziczenia poświadczeń. Nie jest jeszcze jasne, jak szeroko platformy aplikacji i narzędzia do obserwacji innych firm uwzględnią to rozróżnienie między trybami rozliczeniowymi w ich domyślnych pulpitach nawigacyjnych.
Szerszy kierunek jest wystarczająco jasny. Bramy wielomodelowe stają się płaszczyznami kontroli finansowej w takim samym stopniu, jak proxy API. Ustawienie Cloudflare „tylko BYOK” jest wąską funkcją, ale dotyczy prawdziwego trybu awarii: żądania, które działa technicznie, naruszając zamierzony model rozliczeń.