Tenantisolatie bij AI-inference: lessen uit een cache-incident

Cloudflare publiceerde op 26 oktober een technisch verslag van een isolatieprobleem voor tenants in één Workers AI-model. Het bedrijf meldde dat 155 antwoorden op zeer lange prompts gegevens bevatten uit eerdere requests van andere klanten. Volgens Cloudflare speelde het probleem van 27 augustus tot 9 september 2026, betrof het alleen GLM-5.3 en was er geen bewijs voor doelbewuste uitbuiting.

Dit incident is leerzaam omdat het niet ging om een databasequery die een rij van de verkeerde tenant teruggaf. Het betrof inferencegeheugen: een KV-cache die tussentijdse modelstatus bewaart zodat generatie efficiënter kan verlopen. De fout ontstond toen het ene deel van het systeem een te groot request afwees, maar een ander deel doorging alsof de cache correct was geïnitialiseerd.

Hoe een afgewezen request oude status achterliet

Cloudflare had een contextvenster van 1.048.576 tokens ingesteld, terwijl de prefill-KV-cache ruimte bood aan 681.280 tokens. De verwachte reactie op een request dat niet paste, was een foutmelding. In plaats daarvan verving het afwijzingspad van de inference-engine de te grote prompt door een placeholder van één token. Prefill maakte vervolgens cachedata voor die placeholder aan en meldde dat de cacheoverdracht was voltooid.

De decode-node zag die melding als bewijs dat de volledige aanvraag de cachepagina’s had overschreven. Het merendeel bevatte echter nog eerdere requeststatus. Daardoor kon generatie verouderde cache-inhoud gebruiken en gegevens van een andere klant teruggeven. Het probleem was niet alleen dat gebruikers hardware deelden; de aannames over eigenaarschap en voltooiing liepen uiteen tussen onderdelen van het systeem.

Cloudflare meldde dat alle getroffen antwoorden hoorden bij prompts langer dan 681.280 tokens. Het schakelde het model uit, paste de cachegrootte aan, patchte de inference-engine zodat afgewezen requests een fout teruggeven en bracht het model na validatie terug. Ook beschreef het bedrijf aanvullende maatregelen voor de SGLang-inzet.

Wat engineeringteams hiervan kunnen leren

De kernles is dat afwijzingspaden even zorgvuldig op isolatie moeten worden beoordeeld als succesvolle requests. Een fout kan ontstaan nadat geheugen is toegewezen, nadat werk tussen machines is verplaatst of nadat één dienst aan een andere heeft gemeld dat de overdracht is gelukt. Als die onderdelen het niet eens zijn over welk request eigenaar is van een buffer, betekent ‘mislukt’ niet automatisch ‘geen output’ of ‘geen toegang tot data’.

Beoordeel deze eigenschappen expliciet bij multi-tenant inference:

• Toelating: wijs een request af vóórdat gedeelde status gedeeltelijk wordt geïnitialiseerd, of garandeer dat die gedeeltelijke status niet kan worden gelezen.
• Eigenaarschap: koppel iedere cachetoewijzing en overdracht aan een requestidentiteit en tenantgrens; controleer die identiteit ook bij de ontvanger.
• Voltooiing: definieer precies wat een bevestiging van een geslaagde overdracht bewijst. Een controlebericht vervangt geen validatie van de data waarnaar het verwijst.
• Opruimen na fouten: test te grote prompts, annuleringen, time-outs en herstarts van nodes. Controleer dat pagina’s zijn vrijgegeven of overschreven voordat ze opnieuw worden gebruikt.
• Isolatietests: test met twee accounts en unieke, onschuldige canarystrings. Controleer geslaagde én mislukte requests, niet alleen korte standaardprompts.
• Observability: registreer afwijzingen en overdrachten met request-ID’s zonder promptinhoud op te slaan. Waarschuw bij geschonden invarianten of onverwachte markeringen uit een ander request.

Deze maatregelen betekenen niet dat iedere inferenceprovider hetzelfde probleem heeft. Het zijn controlepunten voor elke dienst die GPU-geheugen, cachepagina’s of tussentijdse status tussen requests hergebruikt.

Capaciteitslimieten moeten overal overeenkomen

Een ingesteld contextvenster is een beloofde capaciteit. Het geheugen, de scheduler, de overdracht en de decoder moeten allemaal een toegelaten request aankunnen. Controleer die relatie bij het uitrollen, in plaats van de requestverwerking onder belasting een mismatch te laten ontdekken.

Test ook precies wat er gebeurt als een request te groot is. Het moet veilig falen: een duidelijke fout voor de client, geen generatie op basis van oude status en geverifieerde opruiming voordat geheugen opnieuw wordt gebruikt. Bestaat de inference-engine uit meerdere processen of machines, test dan beide kanten van de overdracht en injecteer storingen ertussen.

Volgens Cloudflare toonde het gepubliceerde incident geen bewijs dat aanvallers het probleem herhaaldelijk uitbuitten. Het laat wel zien waarom securityreviews de data moeten volgen via resourcegrenzen en foutafhandeling, zeker in snelle gedeelde AI-infrastructuur. Isolatie moet de hele levenscyclus van een request garanderen, ook op het pad waar het request hoort te stoppen.

Bronnen: Cloudflare · SGLang