Beveilig private LLM-inferentie in lagen

Je moet private LLM-inferentie als een gelaagd systeem beveiligen: geauthenticeerde endpoints, snel gepatchte frameworks, geverifieerde modelartefacten, beschermde data tijdens uitvoering, beperkte identiteiten en traceerbare logging. Confidential computing versterkt bescherming, maar vervangt geen kwetsbaarheidsmanagement of incidentrespons.

De aanleiding is een onderzoeksnotitie van 28 september 2026 van inferentieframeworks met ernstige kwetsbaarheden, waarin vastgesteld wordt dat vLLM, Ollama, NVIDIA Triton en TensorRT-LLM onveilige deserialisatiecode delen en dat private installaties vaak zonder authenticatie bereikbaar zijn. De casus is CVE-2026-53923 in vLLM, waarbij niet-geïnitialiseerde GPU-geheugengebieden residuele tensordata van andere gebruikers in multi-tenant-opstellingen konden lekken. In onze beoordeling betekent dit dat vertrouwelijkheidsrisico's niet alleen aan de perimeter ontstaan, maar ook binnen de GPU-uitvoering zelf — wat betekent dat je perimeter-, software-, uitvoerings-, identiteits- en waarneembaarheidscontroles gelijktijdig moet inrichten.

Waarom achter de eigen firewall niet volstaat

De aanname dat een systeem veilig is omdat het in je eigen datacenter draait, houdt niet stand. Twee mechanismen maken dit duidelijk. Ten eerste worden nieuwe kwetsbaarheden in serveframeworks snel misbruikt, waardoor de tijd om te patchen kort is. Ten tweede blijken standaardinstallaties geen authenticatie af te dwingen, zodat een bereikbaar endpoint direct toegang geeft. Private hosting reduceert blootstelling, maar veilige inferentie ontstaat pas als alle lagen tegelijk kloppen.

Welke risico's ontstaan in de uitvoering zelf

De vLLM-casus toont waarom tenant-scheiding en snelle patching niet los te koppelen zijn. Een geheugenlek binnen de GPU-uitvoering doorbreekt tenant-grenzen die op netwerkniveau intact lijken. Dit betekent dat je least-privilege-identiteiten niet alleen bij provisioning, maar ook tijdens runtime moet afdwingen — niet alleen bij inrichting. Wie een gecompromitteerde worker beperkt, beperkt ook de reikwijdte van wat eraan ontsnapt.

Welke controles moet je aantoonbaar hebben

De officiële richtlijnen voor AI-werklasten beschrijven vier lagen die je in samenhang inricht:

1. Authenticatie en segmentatie per endpoint — zorg dat elke API-grens geauthenticeerd is en dat tenants netwerkmatig gescheiden zijn.
2. Snelle patching van serveframeworks — volg CVE's voor vLLM, Ollama, NVIDIA Triton en TensorRT-LLM actief en patch binnen dagen, niet weken.
3. Cryptografische verificatie van modelartefacten — onderteken en verifieer modellen voordat ze geladen worden, zodat ongeautoriseerde versies niet draaien.
4. Beperkte identiteiten en kortlevende credentials — zorg dat worker-processen alleen de rechten hebben die ze nodig hebben, en dat credentials snel verlopen.
5. Traceerbare logging zonder gevoelige inhoud — log welk model, welke tenant en welke fout, maar niet de prompts of completies zelf.

Wat confidential computing toevoegt en niet toevoegt

Confidential computing — CPU-TEE's, confidential GPU's en attestatie — versterkt bescherming tegen bevoorrechte infrastructuurbeheerders. Maar het vervangt geen kwetsbaarheidsmanagement, applicatiecontroles of incidentrespons. Onderzoek toont aan dat confidential GPU-uitvoering meetbare overhead introduceert, vooral bij kleinere batchgroottes. Bovendien blijven orchestratie- en denial-of-service-risico's bestaan. Confidential computing hoort in de keten thuis als versterking, niet als vervanging van de rest.

Hoe je aantoonbaar maakt dat een werkstroom binnen zijn grenzen bleef

Om aan te tonen dat inferentie veilig verliep, heb je per werkstroom vastlegging nodig. Dit moet traceerbaar zijn en aansluiten op bredere incidentrespons over de hele AI-keten. Voor de vertrouwelijkheidskant is het nuttig om herleidbare persoonsgegevens in embeddings te beheersen, omdat residuele data zich niet tot GPU-geheugen beperkt. Wat tooling kan vastleggen — welk model, welke tenant, welke fout — is duidelijk. Wat blijft je eigen professionele oordeel, is hoe je die logs interpreteert en wat je daarvan in je incidentrespons doet.