Je zelfgehoste AI-gateway hardenen: van standaardinstellingen naar productie-veilig

Een AI-gateway is het kloppend hart van je eigen AI-stack: het ene adres waar al je applicaties hun prompts naartoe sturen, dat ze doorzet naar OpenAI, Anthropic of een model dat je zelf draait. Handig, want je regelt sleutels, kosten en modelkeuze op een plek. Maar precies daarom is het ook het aantrekkelijkste doelwit op je netwerk. Wie je gateway overneemt, heeft je API-budget, je modeltoegang en vaak je onderliggende server in handen.

Het vervelende is dat de populaire tools standaard zijn ingesteld op gemak, niet op veiligheid. Ze draaien out of the box met open toegang, zodat je in vijf minuten een demo hebt. Die demo-instellingen blijven daarna veel te vaak staan, ook als de gateway al lang productie-verkeer afhandelt. Deze gids is voor de ondernemer of het team dat zelf een AI-gateway draait, of dat overweegt, en hem productie-veilig wil maken zonder beveiligingsexpert te zijn. Ik loop de zes lagen langs die er echt toe doen, met concrete instellingen voor LiteLLM en Langflow.

Wat je nodig hebt

Voordat je begint, zorg dat je het volgende bij de hand hebt:

• Toegang tot de omgeving waar de gateway draait: de Docker-compose of het Kubernetes-manifest, of in elk geval de environment-variabelen en het config-bestand.
• Een wachtwoordmanager of secrets-kluis (denk aan een .env buiten versiebeheer, Docker secrets, of een echte vault) om sleutels in te bewaren. Sleutels horen niet in je git-repo.
• Een reverse proxy zoals Caddy, Nginx of Traefik, plus een domein met een TLS-certificaat. Caddy regelt TLS automatisch.
• Een database (PostgreSQL) als je virtuele sleutels en kostenregistratie wilt; LiteLLM heeft die nodig voor key-management.
• Een half uur rust en een testomgeving. Authenticatie aanzetten kan je per ongeluk buitensluiten, dus oefen het liefst niet meteen op productie.

De gateway dichtzetten in zes lagen

Een productie-veilige AI-gateway combineert authenticatie, netwerkisolatie en least-privilege-sleutels met rate-limits, strak patch-beleid en monitoring. Geen enkele laag is op zichzelf genoeg: authenticatie zonder netwerkisolatie laat je inlogpagina nog steeds aan het hele internet zien. Werk daarom alle zes af, in deze volgorde.

Doorloop de stappen van binnen naar buiten: eerst wie er binnen mag, dan waar de deur staat, dan wat iedereen mag.

1. Zet authenticatie aan en weg met de defaults

Dit is de stap die het vaakst overgeslagen wordt en het meeste kwaad voorkomt. Langflow draait standaard met automatische login aan, een lek dat sinds kort actief wordt misbruikt: iedereen die de pagina opent, is meteen superuser. De officiële Langflow-documentatie bevestigt dat LANGFLOW_AUTO_LOGIN standaard op True staat en waarschuwt om poorten nooit zonder beveiliging aan het internet te hangen. Zet daarom in productie:

• LANGFLOW_AUTO_LOGIN=False
• LANGFLOW_SUPERUSER en LANGFLOW_SUPERUSER_PASSWORD op je eigen waarden (de fallback is letterlijk langflow / langflow, verander dat dus)
• LANGFLOW_SECRET_KEY op een zelf gegenereerde sleutel (laat Langflow er niet stilletjes zelf een verzinnen, want dan klopt de versleuteling niet meer over herstarts of meerdere instances heen)
• LANGFLOW_NEW_USER_IS_ACTIVE=False, zodat nieuwe accounts eerst geactiveerd moeten worden

Bij LiteLLM begint authenticatie met een master key. Die stel je in via LITELLM_MASTER_KEY (of general_settings: master_key in je config.yaml) en hij moet beginnen met sk-. Die master key is je adminsleutel: behandel hem als root-wachtwoord en gebruik hem nooit in een gewone applicatie. Geef applicaties in plaats daarvan virtuele sleutels (stap 3).

2. Haal de gateway van het publieke internet

Een AI-gateway hoort niet rechtstreeks aan het internet te hangen. De meeste overnames beginnen doordat de poort (LiteLLM op 4000, Langflow op 7860) open op 0.0.0.0 staat en zo vindbaar is via een scanner als Shodan.

• Bind lokaal, proxy ervoor. Laat de gateway luisteren op 127.0.0.1 of op een intern Docker-netwerk, en zet een reverse proxy (Caddy, Nginx, Traefik) ervoor die TLS afhandelt. Alleen de proxy is van buiten bereikbaar, op 443.
• Segmenteer je netwerk. Zet de gateway en zijn database in een apart, intern subnet. De gateway mag uit naar de model-API's, maar inkomend verkeer komt uitsluitend via de proxy. Een host-firewall (ufw, nftables) of security group dwingt dat af.
• Beperk wie mag bellen. Moet alleen je eigen backend de gateway aanspreken? Sta dan op de proxy alleen dat IP-bereik toe, of zet er een VPN of mTLS voor. Hoe kleiner het aanvalsoppervlak, hoe minder er kan.

3. Werk met virtuele sleutels en least privilege

Geef nooit je master key aan applicaties of teamleden. Genereer per gebruiker, team of applicatie een virtuele sleutel. In LiteLLM maak je die via het /key/generate-endpoint, en elke virtuele sleutel kun je beperken tot specifieke modellen, met een eigen budget en rate-limit. Zo geef je je chatbot toegang tot precies één goedkoop model en niet tot je dure redeneermodel.

• Whitelist modellen per sleutel. Een sleutel die alleen gpt-4o-mini mag aanroepen, kan geen duur model leeglepelen als hij uitlekt.
• Eigenaar en doel per sleutel. Koppel elke sleutel aan een team of project, zodat je bij een incident precies één sleutel kunt blokkeren (/key/block) zonder de rest plat te leggen.
• Roteer sleutels. Vervang ze periodiek. Een sleutel die nooit verandert, is een sleutel die ooit uitlekt en daarna jaren bruikbaar blijft.

4. Stel rate-limits en budgetten in

Zonder limieten kan een uitgelekte sleutel, of een script dat op hol slaat, in een nacht je hele maandbudget opmaken. Limieten zijn je vangnet.

• In LiteLLM zet je per sleutel rpm_limit (requests per minuut), tpm_limit (tokens per minuut), max_budget (een plafond in dollars) en max_parallel_requests. Met litellm_settings: default_key_generate_params en upperbound_key_generate_params leg je standaardwaarden en harde bovengrenzen voor alle nieuwe sleutels vast.
• In Langflow beperkt LANGFLOW_RATE_LIMIT_PER_MINUTE het aantal loginpogingen per IP (standaard 5), wat brute-force op je inlog afremt.

5. Houd patch-management strak

AI-tooling beweegt snel, en kwetsbaarheden worden vaak binnen dagen na publicatie misbruikt. In LiteLLM werden drie lekken gevonden waarmee gewone gebruikers admin-rechten en code-uitvoering op de gateway konden krijgen; zulke meldingen zijn geen uitzondering maar de norm voor jonge software.

• Pin je versie expliciet (geen latest-tag), zodat je weet wat je draait en gecontroleerd kunt updaten.
• Volg de release-notes en security-advisories van de tools die je draait, en abonneer je op hun CVE-feed.
• Plan een vast updateritme en zet kritieke patches buiten dat ritme om. Een gateway die maanden achterloopt, is een open deur.

Dat patchen onder druk komt te staan zodra je veel open-source-componenten draait, is precies waarom initiatieven een coalitie als Athena open-source-lekken met AI proberen te vinden vóór de aanvallers. Jij hoeft niet op zo'n coalitie te wachten: het zelf bijhouden van je afhankelijkheden is de helft van het werk.

6. Zet monitoring en logging aan

Je kunt geen aanval stoppen die je niet ziet.

• Log verkeer en kosten. LiteLLM houdt verbruik per sleutel bij in zijn database; gebruik dat om afwijkende pieken te zien. Een sleutel die normaal 100 calls per dag doet en er plots 100.000 maakt, is een alarm.
• Zet SSRF-bescherming aan. In Langflow voorkomt LANGFLOW_SSRF_PROTECTION_ENABLED dat een flow je interne netwerk gaat aftasten, een klassieke manier om vanaf de gateway dieper binnen te dringen.
• Stuur logs naar buiten. Laat audit- en toegangslogs naar een aparte plek lopen (een logserver, je SIEM), zodat een aanvaller die de gateway overneemt niet ook meteen de sporen kan wissen.
• Stel alerts in op mislukte logins, nieuwe sleutels en budgetoverschrijdingen. Een melding op het moment zelf is meer waard dan een mooi dashboard dat niemand bekijkt.

Valkuilen

• De demo-instellingen blijven staan. Verreweg de grootste: een gateway die je "even snel" opzette met open toegang, draait een halfjaar later nog steeds zo. Behandel de eerste echte gebruiker als het moment om te hardenen.
• Master key in de applicatie. Wie zijn adminsleutel in een frontend, mobiele app of publieke repo zet, geeft de hele gateway weg. Altijd virtuele sleutels naar buiten.
• Authenticatie aan, maar netwerk open. Een inlogpagina aan het hele internet is nog steeds een aanvalsoppervlak. Authenticatie en netwerkisolatie horen samen.
• Geen rate-limits. Zonder plafond is de eerste keer dat je een probleem merkt vaak de factuur. Stel limieten in voordat je live gaat, niet erna.
• latest draaien zonder te volgen wat er verandert. Dan update je blind, of je update juist nooit. Pin en plan.
• Logs alleen lokaal. Als de aanvaller de machine heeft, heeft hij ook je logs. Stuur ze ergens anders heen.

Kant-en-klaar vs. maatwerk

Moet je dit allemaal zelf bouwen en beheren? Dat hangt af van je situatie. Grofweg zijn er drie routes:

De eerlijke afweging: een managed gateway is sneller en haalt de beveiligingszorg van je bord, maar je levert grip en data-soevereiniteit in, en de kosten lopen mee met je verbruik. Self-hosted geeft je volledige controle en voorspelbare kosten, en is precies waarom ik voor veel projecten bewust self-hosted kies, maar de verantwoordelijkheid voor de zes lagen hierboven ligt dan bij jou. De middenweg, zelf hosten met een eenmalig goed opgezette inrichting, geeft je het beste van beide: je houdt de data in eigen huis en de doorlopende last laag. Als je nog twijfelt of je überhaupt zelf een gateway wilt draaien, helpt het om eerst een leverancier-onafhankelijke AI-stack op te zetten met LiteLLM en een lokaal model en die pas daarna te hardenen.

Beveiliging van een AI-gateway is geen project met een einddatum, het is een houding. De zes lagen hierboven zijn niet moeilijk; ze worden alleen zelden allemaal aangezet omdat de standaardinstellingen je nergens toe dwingen. Wie de demo-modus achter zich laat en bewust kiest voor authenticatie, isolatie en zichtbaarheid, draait een gateway die niet de zwakste schakel in het netwerk is, maar de best bewaakte. Dat is het verschil tussen een tool die toevallig werkt en infrastructuur waarop je durft te bouwen.