Behandel private LLM-inferentie als een gelaagd systeem dat je moet beveiligen: geauthenticeerde en gesegmenteerde endpoints, snel gepatchte serveframeworks, cryptografisch geverifieerde modelartefacten, beschermde data tijdens gebruik, least-privilege identiteiten en privacybewuste logging. Confidential computing versterkt de bescherming tegen infrastructuurbeheerders, maar vervangt geen kwetsbaarheidsbeheer, applicatiecontroles of incidentrespons.
De aanleiding is een onderzoeksnotitie van het Cloud Security Alliance AI Safety Initiative van 19 mei 2026. Daarin stelt de CSA vast dat inferentieframeworks zoals vLLM, Ollama, NVIDIA Triton en TensorRT-LLM ernstige kwetsbaarheden hebben opgestapeld, dat onveilige ZeroMQ-deserialisatiecode over meerdere frameworks werd hergebruikt, en dat private of on-premises installaties vaak zonder authenticatie bereikbaar zijn. De CSA adviseert om inferentie-infrastructuur te behandelen als een naar buiten gerichte dienst, met authenticatie op elke API-grens, netwerkisolatie en versnelde patching.
De praktische consequentie: zelf hosten in een eigen datacenter verlaagt sommige blootstelling, maar levert op zichzelf geen vertrouwelijkheid of integriteit op. Wie inferentie draait en wil beveiligen, moet perimeter, software, uitvoering, identiteit en waarneembaarheid tegelijk beleggen.
Waarom is een privaat gehost inferentieframework niet vanzelf veilig?
De aanname dat een systeem veilig is omdat het achter de eigen firewall draait, houdt geen stand tegenover de bevindingen van de CSA. Twee mechanismen springen eruit. Ten eerste worden nieuwe kwetsbaarheden in serveframeworks snel misbruikt, wat de tijd om te patchen kort maakt. Ten tweede blijken standaardinstallaties vaak geen authenticatie af te dwingen, zodat een bereikbaar endpoint direct toegang geeft.
Dat de blootstelling niet alleen aan de rand zit, laat het CVE-record voor CVE-2026-53923 zien. Volgens die vastlegging konden getroffen vLLM-versies niet-geïnitialiseerde GPU-geheugengebieden in de inferentie-uitvoer laten staan, waardoor residuele tensordata van andere gebruikers in multi-tenant-opstellingen konden lekken. Het record noemt het getroffen versiebereik en vermeldt dat het probleem is verholpen in vLLM 0.23.1rc0. Naar onze inschatting is dit het belangrijkste punt van de casus: vertrouwelijkheidsrisico's kunnen ontstaan binnen de GPU-uitvoering zelf, niet alleen aan de perimeter of in de opslag.
Welke beveiligingslagen heeft private LLM-inferentie nodig?
De officiële richtlijn Best practices for AI workload security on GKE van Google Cloud is geschreven voor Kubernetes, maar de controlecategorieën vertalen zich direct naar private datacenters. Google beschrijft private nodes, default-deny NetworkPolicies, edge-bescherming voor blootgestelde endpoints, IAM en Kubernetes-RBAC, kortlevende workload-credentials, versleutelde en toegangsgecontroleerde secrets, ondertekende en geverifieerde modelartefacten, kwetsbaarheidsscans, isolatie per tenant en rate limiting. Google adviseert ook om auditlogs en metrics te verzamelen, maar prompt- of completielogging te vermijden tenzij het beleid dat toestaat.
Wij lezen die controls als vier lagen die je in samenhang inricht om de inferentie te beveiligen:
- Blootstelling beperken: geauthenticeerde gateways, private netwerken, default-deny-segmentatie en strikte scheiding van inferentieworkers van beheer en opslag.
- Software en supply chain: snelle CVE-respons, ondertekende model- en containerartefacten, dependency-scanning en gecontroleerde uitrol.
- Vertrouwelijkheid en isolatie: scheiding per tenant, versleuteling, confidential CPU/GPU-uitvoering en remote attestation.
- Runtime-verantwoording: least-privilege identiteiten, rate limiting, privacyvriendelijke logs, anomaliedetectie en incidentrespons.
De vLLM-casus toont waarom scheiding per tenant en snelle patching niet los te koppelen zijn: een geheugenlek binnen de uitvoering doorbreekt tenant-grenzen die op netwerkniveau intact lijken. Wie least privilege afdwingt tijdens runtime in plaats van bij provisioning, beperkt de reikwijdte van een gecompromitteerde worker.
Wat beschermt confidential computing wel en wat niet?
De academische preprint EnclaveX van onderzoekers van TU Dresden, STACKIT en Scontain presenteert een end-to-end confidential-AI-ontwerp dat CPU-TEE's, confidential GPU's, attestatie op applicatieniveau en beleidsgestuurde vrijgave van secrets combineert. De auteurs benoemen expliciet de beperking dat Kubernetes-beheerders anders toegang kunnen krijgen tot de inhoud van confidential VM's. Ook rapporteren zij dat confidential GPU-uitvoering meetbare overhead introduceert ten opzichte van niet-confidential uitvoering, met relatief lagere overhead bij grotere batchgroottes.
Daarmee wordt de reikwijdte van deze methode scherp. Onze analyse van de bronnen samen:
- Confidential computing en attestatie zijn het sterkst tegen bevoorrechte infrastructuurtoegang, zoals een orchestratiebeheerder die anders bij VM-geheugen zou kunnen.
- Ze compenseren geen kwetsbare serveringscode: het geheugenlek uit CVE-2026-53923 zit in de uitvoering zelf en wordt niet weggenomen door een versleutelde omgeving.
- Ze weren geen kwaadaardige applicatielogica, geen geautoriseerd misbruik en geen zwakke endpointcontroles.
- De prestatietrade-off maakt confidential uitvoering een afweging per werkstroom, geen standaardknop.
De vraag die de bronnen openlaten, is hoe je de aanbevolen controls en confidential computing precies combineert zonder dat beheerders toegang houden. EnclaveX schetst een richting via attestatie en beleidsgestuurde secretvrijgave, maar behandelt orchestratie- en denial-of-service-risico's als restrisico.
Welke controles leg je per inferentiewerkstroom vast?
Om aantoonbaar te maken dat een werkstroom binnen zijn grenzen bleef, is per inferentiestroom vastlegging nodig. Op basis van de genoemde bronnen achten wij deze punten controleerbaar en relevant:
- Serveframework en exacte versie, gekoppeld aan de patchstatus tegenover bekende CVE's.
- Herkomst van het modelartefact en de uitkomst van handtekeningverificatie.
- Het attestatieresultaat wanneer confidential uitvoering wordt gebruikt.
- De data-residency-grens en de scheiding per tenant.
- Actieve identiteiten en het toegangsbeleid dat op de aanroep van toepassing was.
- Gelogde gebeurtenissen, waarbij prompt- en completie-inhoud alleen wordt bewaard als het beleid dat toestaat.
Die vastlegging sluit aan op bredere incidentrespons over de hele AI-keten, niet alleen bij het model. Voor de vertrouwelijkheidskant is het bovendien nuttig om herleidbare persoonsgegevens in embeddings te beheersen, omdat residuele data zich niet tot GPU-geheugen beperkt. Meer achtergrond staat in de themahub over AI-security en infrastructuurbescherming.
Onze conclusie volgt de bronnen: private hosting reduceert blootstelling, maar veilige inferentie ontstaat pas als perimeter-, software-, uitvoerings-, identiteits- en waarneembaarheidscontroles gelijktijdig kloppen. Confidential computing hoort in die keten thuis als versterking tegen bevoorrechte toegang, niet als vervanging van de rest.
Bronnen en referenties
Bronnen: Het artikel steunt op de onderzoeksnotitie van het Cloud Security Alliance AI Safety Initiative, het CVE-record CVE-2026-53923, de GKE-beveiligingsrichtlijn van Google Cloud en de EnclaveX-preprint van TU Dresden, STACKIT en Scontain.