Perplexity förklarar hur LLM-gatewayer fungerar och vilka risker de innebär i produktionsmiljö

Perplexity publicerade den 27 oktober 2026 en praktisk guide till LLM-gatewayer som visar teknikteam hur mellanlagret dirigerar, autentiserar, cachar och loggar modellförfrågningar samt redogör för säkerhets- och tillförlitlighetsriskerna med att samla leverantörernas autentiseringsuppgifter i en och samma tjänst.

Definition och indelning av gatewayer

Guiden definierar en LLM-gateway som en omvänd proxy för modellförfrågningar: applikationer skickar förfrågningar till gatewayen i stället för direkt till leverantörer som OpenAI, Anthropic eller Google, och gatewayen vidarebefordrar dem samtidigt som den tillämpar operatörens regler. Kategorin presenteras som en lösning på den växande mängden olika tjänster och verktyg. Guiden inleds med ett inlägg från september 2026 på Reddits r/LLMDevs, där en ingenjör beskrev en arbetsplats där alla hade egna nycklar till Claude, OpenAI, AWS Bedrock och andra leverantörer av inferenstjänster.

Guidens jämförelsetabell skiljer mellan fyra typer av gatewayer. En API-gateway placeras framför backendtjänster och avgör om en klient är autentiserad och håller sig inom sin anropsgräns. En LLM-gateway placeras framför modellleverantörer och avgör vilken modell som får en förfrågan, vem som betalar för den och om svaret kommer tillbaka. En MCP-gateway avgör om en agent får anropa ett visst verktyg med angivna argument. I guiden används ”AI-gateway” om leverantörsprodukter som kombinerar några av dessa funktioner.

Förfrågans livscykel i sex steg

Guiden förklarar hur det fungerar genom att följa en förfrågan från applikationen till modellen och tillbaka. Först skickar applikationen en chattförfrågan, ofta i ett OpenAI-kompatibelt format, till gatewayens slutpunkt. Gatewayen validerar autentiseringsuppgifterna, ofta en virtuell nyckel som utfärdats till ett team eller en produkt, och kan, om skyddsmekanismer för inkommande data har aktiverats, söka igenom promptar efter känsliga uppgifter eller försök att åsidosätta modellens instruktioner. Om cachning är aktiverad kan en matchande förfrågan som uppfyller villkoren besvaras med ett sparat svar. Vissa gatewayer erbjuder semantisk cachning, som matchar förfrågningar som bedöms vara likartade snarare än identiska. Därefter letar gatewayen upp den matchande routen i sin konfiguration och kan växla till en reservleverantör om den första leverantören inte svarar i tid. Den konverterar förfrågan till det valda formatet, autentiserar det utgående anropet och konverterar svaret tillbaka så att applikationen kan använda det. Om loggning är aktiverad registrerar gatewayen vem som gjorde anropet, vilken modell som hanterade det, antalet token, svarstiden och kostnaden.

Säkerhets- och tillförlitlighetsrisker

Guidens centrala varning är att gatewayen samlar autentiseringsuppgifter på ett och samma ställe. Microsofts säkerhetsteam har redogjort för vad en LiteLLM-distribution kan innehålla eller hämta: API-nycklar till leverantörer, LiteLLM:s huvudnyckel, poster för virtuella nycklar, anslutningssträngar till databaser, routningskonfiguration och data om klientpolicyer. I inlägget från den 26 augusti 2026 beskrev Microsoft ett observerat intrång i en LiteLLM-gateway, där angripare samlade in autentiseringsuppgifter från gatewayens körmiljö.

Den 13 oktober 2026 offentliggjorde Check Point Research två sårbarheter med hög risk i LiteLLM: CVE-2026-35029, en brist i åtkomstkontrollen som gjorde det möjligt för autentiserade användare, även användare med enbart läsbehörighet, att komma åt administrativa funktioner och ta över gatewayen, samt CVE-2026-59823, en sårbarhet för förfalskning av förfrågningar från serversidan som gjorde det möjligt för användare att omdirigera gatewayens förfrågningar till en server som kontrollerades av en angripare och fånga upp API-nycklar till AI-leverantörer. Båda sårbarheterna åtgärdas i LiteLLM version 1.83.9. Check Point uppgav att LiteLLM hade 97 miljoner nedladdningar per månad och fler än 59 000 stjärnmarkeringar på GitHub, och sade att den samordnade rapporteringen till LiteLLM inleddes i oktober 2025.

Guiden uppmanar också team att fastställa en policy för hur fel i skyddsmekanismer ska hanteras. Den beskriver krokar som punkter i förfrågansflödet där gatewayen skickar innehåll till en extern granskare för bedömning. Det påpekas att Portkeys dokumentation nämner before_request_hooks och after_request_hooks, och att TrueFoundry kör fyra krokar med kontroller både före och efter anrop till MCP-verktyg.

När det gäller tillförlitlighet hänvisar guiden till dokumenterade avbrott. Cloudflares egen redogörelse för avbrottet den 12 juni 2025 uppger att felfrekvensen för AI Gateway som högst nådde 97 % av förfrågningarna, eftersom AI Gateway är beroende av Workers KV för klient- och internkonfigurationer. Det övergripande avbrottet varade i 2 timmar och 28 minuter. OpenRouters haverirapport om avbrotten den 17 och 19 februari 2026 uppger att incidenterna varade i 38 respektive 35 minuter efter ett fel i ett cacheberoende från tredje part. De ledde till 401-fel med meddelandet ”User not found” och till åtgärder som kretsbrytare samt att 503-fel returneras i stället för 401 när infrastrukturproblem hindrar auktoriseringskontroller.

Distributionsalternativ, prissättning och leverantörsspecifika lösningar

Guiden beskriver fyra sätt att distribuera en gateway. Team kan utveckla en enkel gateway internt – ta emot förfrågningar, kontrollera anroparens nyckel, lägga till leverantörens autentiseringsuppgifter, vidarebefordra anropet och logga resultatet – eller själva drifta en gateway med öppen källkod. LiteLLM, Bifrost och Helicone nämns som alternativ. Bland de hanterade gatewayerna finns Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter och Portkeys driftade gateway. Ett fjärde alternativ är att bygga vidare på en API-gateway som företaget redan använder. Exempel som nämns är Kong AI Gateway, Apigees AI-gatewaypolicyer och Azure API Managements AI-gateway.

När det gäller kostnader uppger guiden att LLM-gateways sträcker sig från kostnadsfri programvara med öppen källkod till betalplaner som börjar på omkring 50 dollar i månaden, med anpassad prissättning för företag, och att vissa i stället tar ut en procentandel: OpenRouters Standard-plan lägger enligt guiden på 5,5 % på köp av krediter.

Guiden avslutas med svar som gäller specifika leverantörer. Den uppger att Amazon Bedrock AgentCore Gateway stöder modellanrop via det som AWS kallar ”inferensmål”, vilket gör att applikationer kan använda en enda slutpunkt för att nå leverantörer som Amazon Bedrock, OpenAI och Anthropic. Den noterar att Perplexitys egen Agent API stöder gränssnittet i OpenAI:s Responses API, så att team kan återanvända befintliga klientbibliotek från OpenAI, och att Agent API gör det möjligt för användare att lista upp till fem modeller, även modeller från olika leverantörer, i önskad ordning. Guiden nämner också Perplexitys Numbat med öppen källkod, som ansluter till agenter som stöds via lokala hookar och kan granska planerade åtgärder, till exempel skalkommandon eller filskrivningar, innan de körs. Blockering är valfritt och är avstängt som standard.