Perplexity gennemgår LLM-gatewayens mekanik og risici i produktion

Perplexity udgav den 27. oktober 2026 en praktisk guide til LLM-gateways, der gennemgår, hvordan mellemlaget dirigerer, godkender, cacher og logger modelkald, og beskriver sikkerheds- og pålidelighedsrisiciene ved at samle udbyderes legitimationsoplysninger i én tjeneste.

Definition og taksonomi for gateways

Guiden definerer en LLM-gateway som en omvendt proxy til modelkald: Applikationer sender forespørgsler til gatewayen i stedet for direkte til udbydere som OpenAI, Anthropic eller Google, og gatewayen videresender forespørgslerne og anvender samtidig operatørens regler. Kategorien præsenteres som et svar på fragmenteringen. Guiden indleder med et opslag fra september 2026 på Reddits r/LLMDevs, hvor en ingeniør beskrev en arbejdsplads, hvor alle havde deres egne nøgler til Claude, OpenAI, AWS Bedrock og andre udbydere af inferenstjenester.

Guidens sammenligningstabel skelner mellem fire typer gateways. En API-gateway står foran backend-tjenester og afgør, om en klient er godkendt og overholder sin hastighedsgrænse. En LLM-gateway står foran modeludbydere og afgør, hvilken model der modtager en forespørgsel, hvem der betaler for den, og om den kom retur. En MCP-gateway afgør, om en agent må kalde et bestemt værktøj med bestemte argumenter. Guiden bruger betegnelsen »AI-gateway« om leverandørprodukter, der samler nogle af disse funktioner.

Livscyklussen for en forespørgsel i seks trin

Guiden forklarer mekanikken ved at følge en forespørgsel fra applikationen til modellen og tilbage igen. Først sender applikationen en chatforespørgsel, ofte i et OpenAI-kompatibelt format, til gatewayens endepunkt. Gatewayen validerer legitimationsoplysningerne, ofte en virtuel nøgle, der er tildelt et team eller et produkt, og kan, hvis inputværn er konfigureret, undersøge prompts for følsomme data eller forsøg på at tilsidesætte modellens instruktioner. Hvis caching er aktiveret, kan en forespørgsel, der opfylder betingelserne og matcher en tidligere forespørgsel, besvares med et gemt svar. Nogle gateways tilbyder semantisk caching, som matcher forespørgsler, der vurderes at ligne hinanden, frem for at være identiske. Gatewayen slår derefter den tilsvarende rute op i sin konfiguration og kan skifte til en reserveudbyder, hvis den første udbyder ikke svarer inden for tidsgrænsen. Den konverterer forespørgslen til det valgte format for udbyderen, godkender det udgående kald og konverterer svaret tilbage til et format, som applikationen kan bruge. Når logning er aktiveret, registrerer gatewayen, hvem der foretog kaldet, hvilken model der håndterede det, antallet af tokens, svartiden og omkostningerne.

Sikkerheds- og pålidelighedsrisici

Guidens centrale advarsel er, at gatewayen samler legitimationsoplysningerne ét sted. Microsofts sikkerhedsteam har oplistet, hvad en LiteLLM-implementering kan opbevare eller hente: API-nøgler til udbydere, LiteLLM-hovednøglen, registreringer af virtuelle nøgler, forbindelsesstrenge til databaser, routingskonfiguration og data om lejerpolitikker. I opslaget fra den 26. august 2026 beskrev Microsoft et observeret kompromitteringstilfælde, hvor angribere stjal legitimationsoplysninger fra LiteLLM-gatewayens runtime-miljø.

Den 13. oktober 2026 offentliggjorde Check Point Research oplysninger om to højrisikosårbarheder i LiteLLM: CVE-2026-35029, en fejl i adgangskontrollen, der gav godkendte brugere, herunder brugere med skrivebeskyttet adgang, mulighed for at tilgå administrative funktioner og overtage gatewayen, og CVE-2026-59823, en sårbarhed for server-side request forgery, der gjorde det muligt for brugere at omdirigere gatewayens forespørgsler til en server, som angriberen kontrollerede, og opsnappe API-nøgler til AI-udbydere. Begge sårbarheder er rettet i LiteLLM version 1.83.9. Check Point oplyste, at LiteLLM havde 97 millioner downloads om måneden og mere end 59.000 stjerner på GitHub, og at den koordinerede videregivelse af oplysningerne til LiteLLM begyndte i oktober 2025.

Guiden anbefaler også, at teams fastlægger en politik for, hvad der skal ske, hvis sikkerhedstjek fejler. Den beskriver hooks som punkter i forespørgselsforløbet, hvor gatewayen sender indhold til en ekstern scanner for at få en vurdering. Det nævnes, at Portkeys dokumentation omtaler before_request_hooks og after_request_hooks, og at TrueFoundry kører fire hooks med kontroller både før og efter kald af MCP-værktøjer.

Hvad angår pålidelighed, henviser guiden til dokumenterede driftsafbrydelser. Cloudflares egen beskrivelse af afbrydelsen den 12. juni 2025 angiver, at fejlprocenten for AI Gateway toppede på 97 % af forespørgslerne, fordi AI Gateway er afhængig af Workers KV til klient- og interne konfigurationer. Den samlede afbrydelse varede 2 timer og 28 minutter. OpenRouters hændelsesrapport om afbrydelserne den 17. og 19. februar 2026 angiver, at hændelserne varede henholdsvis 38 og 35 minutter, efter at en cacheafhængighed fra tredjepart svigtede. Det førte til fejlmeddelelserne 401 »User not found« og til afhjælpende tiltag, herunder circuit breakers og returnering af fejlmeddelelserne 503 i stedet for 401, når infrastrukturproblemer forhindrer opslag af godkendelsesoplysninger.

Implementeringsmuligheder, priser og oplysninger om leverandører

Guiden gennemgår fire implementeringsmuligheder. Teams kan udvikle en minimal gateway internt — som modtager forespørgsler, kontrollerer afsenderens nøgle, tilføjer udbyderens legitimationsoplysninger, videresender kaldet og logger resultatet — eller selv hoste en open source-gateway. LiteLLM, Bifrost og Helicone nævnes som muligheder. Blandt de administrerede gateways nævnes Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter og Portkeys hostede gateway. En fjerde mulighed er at udvide en API-gateway, som virksomheden allerede driver. Her nævnes Kong AI Gateway, Apigees AI-gatewaypolitikker og Azure API Managements AI-gateway.

Hvad angår omkostningerne, oplyser guiden, at LLM-gateways spænder fra gratis open source-software til betalingsplaner, der starter ved omkring 50 $ om måneden, med individuelle priser til virksomheder, og at nogle i stedet opkræver en procentdel: OpenRouters Standard-plan lægger ifølge guiden 5,5 % oven i køb af kreditter.

Guiden slutter med svar, der er specifikke for de enkelte leverandører. Den oplyser, at Amazon Bedrock AgentCore Gateway understøtter modelkald via det, AWS kalder »inference targets«, så applikationer kan bruge ét slutpunkt til at få adgang til udbydere som Amazon Bedrock, OpenAI og Anthropic. Den bemærker, at Perplexitys egen Agent API understøtter OpenAI’s Responses API-grænseflade, så teams kan genbruge eksisterende klientbiblioteker fra OpenAI, og at Agent API’en lader brugere angive op til fem modeller, herunder modeller fra forskellige udbydere, i den ønskede rækkefølge. Guiden nævner også Perplexitys open source-projekt Numbat, som opretter forbindelse til understøttede agenter via lokale hooks og kan undersøge planlagte handlinger, såsom shell-kommandoer eller filskrivninger, før de udføres; blokering kan tilvælges og er som standard slået fra.