LLM gateway: bezpieczeństwo, routing i kontrola kosztów AI

LLM gateway centralizuje uwierzytelnianie, routing modeli, limity, cache i audyt. Ułatwia governance, ale staje się krytycznym punktem zdolnym czytać prompty, narzędzia i odpowiedzi całej organizacji.

Tożsamość i tenanty

Każde żądanie niesie tożsamość użytkownika, workloadu, aplikacji i tenanta. Gateway nie może ufać nagłówkowi ustawionemu przez klienta bez weryfikacji tokenu. Polityka określa dozwolone modele, region, budżet i klasy danych.

Routing i fallback

Fallback na innego dostawcę może zmienić retencję, region, capability i politykę safety. Traktuj go jako materialną zmianę wymagającą jawnej zgody. Nie wysyłaj promptu z danymi poufnymi do modelu, którego profil nie pozwala na tę klasę.

Logi i cache

Domyślnie loguj metadane, nie pełną treść. Prompty, argumenty narzędzi i wyniki mogą zawierać sekrety. Szyfruj cache, separuj tenanty, ogranicz TTL i uwzględnij semantic cache w procedurze usuwania danych.

Odporność

Stosuj rate limit per identity, budżet kosztu, circuit breaker i ochronę przed retry storm. Klucze dostawców trzymaj w sejfie i rotuj bez przestoju. Gateway musi mieć ścieżkę awaryjną, ale bypass nie może omijać audytu.

Testuj cross-tenant cache, header spoofing, downgrade modelu, fail-open i wyciek przez observability. Powiąż kontrolę z rejestrem modeli AI.

Gateway jako punkt egzekwowania polityki

Gateway powinien uwierzytelnić aplikację i użytkownika, ustalić tenant oraz dopiero potem wybrać dostawcę i model. Nie ufaj nagłówkom dostarczonym przez klienta bez weryfikacji na zaufanej tożsamości. Decyzja obejmuje dozwolone modele, region, klasyfikację danych, limit kosztu, narzędzia i maksymalną długość kontekstu.

Normalizuj różnice między API dostawców, ale nie ukrywaj semantyki bezpieczeństwa. Brak obsługi wymaganego parametru lub schematu tool call powinien kończyć się kontrolowanym błędem, a nie cichym pominięciem zabezpieczenia. Rejestr modeli przechowuje właściciela, wersję, wyniki ewaluacji, regiony i dopuszczone przypadki użycia.

Cache, logi i dane wrażliwe

Klucz cache musi obejmować tenant, model, wersję polityki i parametry wpływające na odpowiedź. Dla treści wrażliwej bezpieczniejszy może być brak cache. Szyfruj dane w tranzycie i spoczynku, ustaw retencję oraz maskuj sekrety przed zapisaniem logu. Pełny prompt nie powinien być domyślną metryką observability.

Log audytowy zapisuje decyzję routingu, wersję polityki, tożsamość, dostawcę, model, zużycie i status, ale nie ujawnia tokenu dostawcy. Klucze przechowuje gateway; aplikacja otrzymuje jedynie prawo wykonania określonego typu żądania.

Bezpieczna awaria

Fallback jest nową decyzją bezpieczeństwa. Model zastępczy musi mieć zgodny region, obsługiwać wymagane kontrolki i przejść ewaluację dla danego zastosowania. Gdy warunki nie są spełnione, gateway powinien odmówić lub przejść w ograniczony tryb bez narzędzi, zamiast wybierać dowolny dostępny model.

Testy chaosowe obejmują timeout dostawcy, częściowy streaming, rozbieżny schemat, lawinę retry i wyczerpanie budżetu. Sprawdź, czy każda ścieżka nadal tworzy log audytowy, zachowuje izolację tenantów i nie omija bramki akceptacji.

Kontrola narzędzi i odpowiedzi strumieniowej

Gateway powinien walidować nazwę oraz argumenty tool call przed przekazaniem ich do executora. Adapter dostawcy nie może cicho zmienić typu, pominąć wymaganego pola ani dołączyć nieznanego narzędzia. Dla każdego schematu utrzymuj wersję i test zgodności.

W streamingu odpowiedź jest niepełna aż do zakończenia. Nie uruchamiaj akcji wysokiego wpływu na podstawie fragmentu, który może zostać później anulowany lub zmienić strukturę. Ogranicz wielkość bufora, czas oraz liczbę równoległych strumieni i rozliczaj koszt także po zerwaniu połączenia.

Operacje i incident response

Dashboard powinien pokazywać błędy per dostawca, rozkład modeli, koszt per tenant, odrzucenia polityki, retry i wykorzystanie fallbacku. Nagły wzrost jednego wskaźnika może oznaczać awarię adaptera, nadużycie lub błędną konfigurację.

Procedura incydentu obejmuje rotację klucza dostawcy, wyłączenie modelu, blokadę regionu i unieważnienie cache bez zatrzymywania całej platformy. Każda zmiana awaryjna musi zachować identyfikator decyzji i później przejść normalny przegląd.

Przegląd architektury powinien także objąć zależność od jednego dostawcy oraz możliwość eksportu konfiguracji. Plan ciągłości nie oznacza automatycznego failoveru za wszelką cenę; definiuje, które funkcje mogą zostać czasowo wyłączone, gdy bezpieczny model zastępczy nie jest dostępny.

Każdy nowy klient gatewaya zaczyna od najmniejszego profilu i osobnego limitu. Uprawnienia zwiększaj dopiero po obserwacji ruchu oraz przeglądzie danych, narzędzi i scenariuszy awarii.

Źródła: OWASP Secure AI Model Ops, Anthropic LLM Gateway Configuration.