Perplexity legt uit hoe LLM-gateways werken en welke risico’s ze in productie met zich meebrengen

Perplexity publiceerde op 27 oktober 2026 een praktische gids over LLM-gateways. Daarin laat het engineeringteams zien hoe deze tussenlaag modelaanroepen doorstuurt, verifieert, in de cache opslaat en registreert, en beschrijft het de beveiligings- en betrouwbaarheidsrisico’s van het concentreren van inloggegevens van aanbieders in één dienst.

Definitie en taxonomie van gateways

De gids definieert een LLM-gateway als een reverseproxy voor modelaanroepen: applicaties sturen verzoeken naar de gateway in plaats van rechtstreeks naar aanbieders zoals OpenAI, Anthropic of Google. De gateway stuurt die verzoeken door en past daarbij de regels van de beheerder toe. De gids presenteert deze categorie als een oplossing voor versnippering. Als voorbeeld haalt hij een bericht uit september 2026 aan op Reddit-forum r/LLMDevs, waarin een engineer een werkplek beschreef waar iedereen eigen sleutels had voor Claude, OpenAI, AWS Bedrock en andere aanbieders van inferentiediensten.

De vergelijkingstabel in de gids onderscheidt vier soorten gateways. Een API-gateway staat vóór backenddiensten en bepaalt of een client is geauthenticeerd en binnen de limiet voor het aantal verzoeken blijft. Een LLM-gateway staat vóór modelaanbieders en bepaalt welk model een verzoek ontvangt, wie ervoor betaalt en of er een antwoord terugkomt. Een MCP-gateway bepaalt of een agent een bepaalde tool met bepaalde argumenten mag aanroepen. De gids gebruikt de term ‘AI-gateway’ voor producten van leveranciers die een combinatie van deze functies bundelen.

De levenscyclus van een verzoek in zes stappen

De gids legt de werking uit door één verzoek van de applicatie naar het model en terug te volgen. Eerst stuurt de applicatie een chatverzoek naar het eindpunt van de gateway, vaak in een formaat dat compatibel is met OpenAI. De gateway controleert de inloggegevens, vaak een virtuele sleutel die aan een team of product is verstrekt. Als er invoerbeveiligingen zijn ingesteld, kan de gateway prompts ook scannen op gevoelige gegevens of pogingen om de instructies van het model te omzeilen. Als caching is ingeschakeld, kan een daarvoor in aanmerking komend, overeenkomend verzoek worden beantwoord met een opgeslagen reactie. Sommige gateways bieden semantische caching, waarbij verzoeken als vergelijkbaar worden aangemerkt in plaats van identiek te moeten zijn. Vervolgens zoekt de gateway in zijn configuratie de bijbehorende route op en kan hij terugvallen op een back-upaanbieder als de eerste aanbieder niet op tijd reageert. De gateway zet het verzoek om naar het formaat van de gekozen aanbieder, authenticeert de uitgaande aanroep en zet het antwoord terug om naar een formaat dat de applicatie kan verwerken. Als logging is ingeschakeld, registreert de gateway wie de aanroep heeft gedaan, welk model deze heeft verwerkt, het aantal tokens, de latentie en de kosten.

Beveiligings- en betrouwbaarheidsrisico’s

De centrale waarschuwing in de gids is dat de gateway inloggegevens op één plek samenbrengt. Het beveiligingsteam van Microsoft heeft opgesomd wat een LiteLLM-implementatie kan bevatten of ophalen: API-sleutels van aanbieders, de hoofdsleutel van LiteLLM, gegevens over virtuele sleutels, databaseverbindingsreeksen, routeringsconfiguratie en gegevens over tenantbeleid. In dat bericht van 26 augustus 2026 beschreef Microsoft een geconstateerde inbreuk op een LiteLLM-gateway waarbij aanvallers inloggegevens buitmaakten uit de runtime-omgeving van de gateway.

Op 13 oktober 2026 maakte Check Point Research twee kwetsbaarheden met een hoog risico in LiteLLM bekend: CVE-2026-35029, een fout in de toegangscontrole waardoor geauthenticeerde gebruikers, ook gebruikers met alleen-lezenrechten, toegang kregen tot beheerfuncties en de gateway konden overnemen; en CVE-2026-59823, een server-side request forgery-kwetsbaarheid waarmee gebruikers gatewayverzoeken konden omleiden naar een server die door een aanvaller werd beheerd, zodat die de API-sleutels van AI-aanbieders kon buitmaken. Beide kwetsbaarheden zijn verholpen in LiteLLM versie 1.83.9. Check Point meldde dat LiteLLM 97 miljoen downloads per maand en meer dan 59.000 GitHub-sterren had, en zei dat de gecoördineerde melding aan LiteLLM in oktober 2025 was begonnen.

De gids adviseert teams ook om voor beveiligingscontroles een beleid vast te leggen voor situaties waarin ze niet werken. Hooks zijn volgens de gids punten in het verzoektraject waarop de gateway inhoud doorstuurt naar een externe scanner voor beoordeling. Daarbij merkt de gids op dat de documentatie van Portkey melding maakt van before_request_hooks en after_request_hooks, en dat TrueFoundry vier hooks uitvoert, met extra controles vóór en na MCP-toolaanroepen.

Wat betrouwbaarheid betreft, verwijst de gids naar gedocumenteerde storingen. In zijn eigen verslag van de storing op 12 juni 2025 meldt Cloudflare dat het foutenpercentage bij AI Gateway opliep tot 97% van de verzoeken, omdat AI Gateway voor client- en interne configuraties afhankelijk is van Workers KV. De algehele storing duurde 2 uur en 28 minuten. In het evaluatieverslag achteraf over de storingen van 17 en 19 februari 2026 meldt OpenRouter dat de incidenten 38 en 35 minuten duurden nadat een afhankelijkheid van een externe cachingdienst was uitgevallen. Daarbij traden 401-fouten op met de melding “User not found”. De incidenten leidden tot maatregelen, waaronder circuitbreakers en het retourneren van 503-fouten in plaats van 401-fouten wanneer infrastructuurproblemen de controles van autorisatiegegevens verhinderen.

Implementatieopties, prijzen en leveranciersspecifieke details

De gids beschrijft vier manieren om een gateway te implementeren. Teams kunnen er zelf een eenvoudige gateway bouwen — die verzoeken accepteert, de sleutel van de aanroeper controleert, de inloggegevens van de aanbieder toevoegt, de aanroep doorstuurt en het resultaat registreert — of een open-sourcegateway zelf hosten. Als opties noemt de gids LiteLLM, Bifrost en Helicone. Voorbeelden van beheerde gateways zijn Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter en de gehoste gateway van Portkey. Een vierde mogelijkheid is om een API-gateway uit te breiden die een bedrijf al gebruikt. De gids noemt Kong AI Gateway, de AI-gatewaybeleidsregels van Apigee en de AI-gateway van Azure API Management.

Wat de kosten betreft, vermeldt de gids dat LLM-gateways uiteenlopen van gratis opensourcesoftware tot betaalde abonnementen vanaf ongeveer $ 50 per maand, met aangepaste prijzen voor bedrijven. Sommige rekenen in plaats daarvan een percentage: het Standard-abonnement van OpenRouter voegt volgens de gids 5,5% toe aan aankopen van tegoed.

De gids sluit af met antwoorden over specifieke aanbieders. Amazon Bedrock AgentCore Gateway ondersteunt modelaanroepen via wat AWS ‘inferentiedoelen’ noemt, zodat applicaties via één endpoint aanbieders als Amazon Bedrock, OpenAI en Anthropic kunnen bereiken. De gids vermeldt dat Perplexitys eigen Agent API de interface van OpenAI’s Responses API ondersteunt, zodat teams bestaande clientbibliotheken van OpenAI opnieuw kunnen gebruiken. Ook kunnen gebruikers via de Agent API maximaal vijf modellen in een voorkeursvolgorde opgeven, waaronder modellen van verschillende aanbieders. De gids noemt ook Perplexitys opensourceproject Numbat, dat via lokale hooks verbinding maakt met ondersteunde agents en geplande acties, zoals shellcommando’s of het schrijven van bestanden, kan inspecteren voordat ze worden uitgevoerd. Blokkeren is optioneel en staat standaard uit.