Kort samengevat: cross-tenant lekkage van AI-API-responses
- Geen privékanaal: Een LLM-API-response behandelen als een privékanaal tussen jou en het model is de fout. Het is data die terugkomt uit een enorme gedeelde stack van caches, routers en pools, en op een slechte dag belandt de output van de ene tenant in de sessie van een andere.
- Gedeelde-state-fout: Het Claude API-incident van 2026-06-05 raakte Opus 4.5 tot 4.8 en Sonnet 4.6 uren lang. Het komt overeen met de redis-py-fout van 2023 bij OpenAI die beperkte factureringsgegevens van 1,2% van ChatGPT Plus-abonnees blootlegde, en cside bewaakt de browserlaag waar AI-output, third-party scripts en geauthenticeerde sessies elkaar treffen.
- Saneren en valideren: Render je modeloutput in de browser, saneer voordat het de DOM raakt en valideer de vorm op elke response. Werk je met gereguleerde data, kies zero-retention-voorwaarden en log request- en response-metadata om een modelfout van een tenantlek te onderscheiden.
Weinig tijd? Bekijk cside's AI-agentdetectie. Dit dekt alles hieronder in één deployment.
Een paar uur lang in de middag van 2026-06-05 lijkt de Claude-API antwoorden te hebben teruggegeven die niet toebehoorden aan de gebruiker die ze had opgevraagd. Je stuurt een verzoek en je krijgt uitvoer terug die leest als een antwoord op de prompt van iemand anders.
De statuspagina van Anthropic registreerde het voorval als "verhoogde fouten op veel Claude-modellen", met gevolgen voor Opus 4.5 tot en met 4.8 en Sonnet 4.6. Het beschrijft, op het moment van schrijven, geen datalek. De lezing dat het om gegevens tussen gebruikers ging, komt uit rondgaande screenshots en eerstehands meldingen, dus behandel het als een vroege interpretatie, niet als een bevestigde inbreuk.
De foutklasse is belangrijker dan of één aanbieder toevallig een slechte middag had. Wanneer zoiets gebeurt, is het bijna altijd terug te voeren op gedeelde, muteerbare state onder belasting, en dat is een risico dat elke snel opschalende AI-aanbieder op dit moment met zich meedraagt.
Wat er lijkt te zijn gebeurd
Volgens de statuspagina van Anthropic liep het incident door de middag van 2026-06-05: het onderzoek werd geopend rond 15:19 UTC, het probleem werd geïdentificeerd rond 15:43 UTC en als opgelost gemarkeerd rond 18:28 UTC. De getroffen modellen waren Claude Opus 4.5, 4.6, 4.7 en 4.8, samen met Sonnet 4.6. Het officiële label was "verhoogde fouten", de generieke bak die aanbieders gebruiken voor alles van time-outs tot misvormde antwoorden.
De meldingen die de aandacht trokken, beschrijven iets specifiekers. Gebruikers zeiden dat sommige API-aanroepen inhoud teruggaven die niets met hun eigen prompt te maken had en, in minstens één veelgedeeld geval, verscheen de taak van de ene persoon binnen het antwoord van een volledig niet-gerelateerde gebruiker. Meerdere mensen zeiden dat ze ontvingen wat leek op de inferentie-uitvoer van een andere klant, en dat ze het zorgvuldig hadden gecontroleerd voordat ze concludeerden dat het een fout aan de serverkant was en geen bug aan hun kant.
Twee dingen zijn tegelijk waar. Anthropic heeft geen blootstelling van gegevens tussen gebruikers bevestigd, en het publieke bewijs is daarmee consistent. Een verantwoorde lezing houdt beide vast: dit lijkt op cross-tenant lekken van antwoorden, en het is nog niet officieel als zodanig bevestigd. Ik geef de gelekte screenshots hier niet weer, omdat ze de prompt en uitvoer van een andere klant bevatten, precies de gegevens die niet verder zouden mogen circuleren.
De foutklasse: gedeelde, muteerbare state onder belasting
Cross-tenant lekken is wanneer de gegevens van de ene klant opduiken in de sessie van een andere. Het is een van de oudste en gevaarlijkste bugs in multi-tenant systemen, en het komt zelden van een spectaculaire inbreuk. Het komt meestal van een stuk gedeelde, muteerbare state dat per verzoek geïsoleerd had moeten zijn en dat, onder de verkeerde omstandigheden, dat niet was.
Een moderne AI-API is geen enkel programma dat één verzoek tegelijk beantwoordt. Het is een stapel gedeelde lagen: load balancers, request routers, gateways, queues, in-memory caches en connectiepools, die allemaal tegelijk elke klant bedienen om latentie en kosten laag te houden. Elk van die lagen houdt state vast. Elke laag is een plek waar een verzoek het verkeerde antwoord kan oppikken als een cachesleutel botst, een connectie wordt hergebruikt nadat ze had moeten worden weggegooid, of een geannuleerd verzoek een verouderd object achterlaat.
Het symptoom is bijna altijd hetzelfde: je vraagt je eigen gegevens op en je krijgt die van iemand anders. De oorzaak is bijna altijd saai: een kleine fout in hoe een gedeeld object wordt hergebruikt, getriggerd door belasting of door een randgeval zoals een geannuleerd of verlopen verzoek.
We hebben dit patroon eerder gezien
Het duidelijkste precedent is OpenAI, in maart 2023. Op 2023-03-20 veroorzaakte een wijziging aan hun servers een piek in geannuleerde Redis-verzoeken, die een bug in de clientbibliotheek redis-py activeerde. Gedurende een venster die dag konden sommige ChatGPT-gebruikers de gesprekstitels van andere actieve gebruikers zien en, in sommige gevallen, het eerste bericht van een nieuw aangemaakt gesprek.
Hetzelfde incident stelde beperkte factureringsgegevens bloot. OpenAI stelde ongeveer 1,2% van de ChatGPT Plus-abonnees op de hoogte dat een andere gebruiker hun voor- en achternaam, factuuradres, kaarttype, vervaldatum en de laatste vier cijfers van hun kaart had kunnen zien. Volledige kaartnummers werden nooit blootgesteld. Zoals Help Net Security destijds berichtte, en zoals OpenAI in zijn eigen post-mortem bevestigde, was de hoofdoorzaak een gedeelde cache- en connectielaag die na geannuleerde verzoeken gegevens aan de verkeerde client teruggaf.
Dat is dezelfde foutklasse als het symptoom dat in de meldingen over Claude wordt beschreven: een gedeelde, muteerbare laag die de gegevens van de ene klant onder belasting aan een andere overhandigt. Ander bedrijf, andere bibliotheek, dezelfde vorm.
Waarom opschalen dit waarschijnlijker maakt, niet minder
Hier is het ongemakkelijke structurele deel. AI-aanbieders voegen capaciteit sneller toe dan vrijwel elke infrastructuur in de geschiedenis van de informatica. De vraag overtreft de hardware, dus teams blijven lagen toevoegen om het bij te benen: meer caching om tokenkosten te drukken, meer routing om de belasting over regio's en modelversies te spreiden, meer proxy's en gateways om quota's en failover te beheren.
Elk van die lagen is een prestatiewinst en een nieuwe plek waar state kan lekken. Een cache die de verkeerde sleutel serveert, een router die een connectie hergebruikt, een proxy die het ene antwoord in een andere stroom vouwt: elk is één bug verwijderd van cross-tenant lekken. Hoe agressiever een aanbieder opschaalt, hoe meer van deze lagen hij draait en hoe meer belasting hij erdoorheen duwt.
Dit is dus minder een verhaal over Anthropic dan een verhaal over iedereen. De aanbieders die het hardst rennen om capaciteit toe te voegen, zijn precies degenen die het meest blootgesteld zijn aan deze klasse bugs, omdat snelheid en gedeelde infrastructuur de manier zijn om miljoenen verzoeken goedkoop te bedienen. Het is een eigenschap van de architectuur waarop de hele sector bouwt, geen teken dat één bedrijf nalatig is.
AI-API-beveiliging in apps die in de browser worden weergegeven
Het cross-tenant lekkagerisico dat hierboven wordt beschreven, bevindt zich aan de kant van de API-aanbieder, maar AI-API-beveiliging stopt daar niet. Wanneer modeluitvoer in de browser terechtkomt, opent zich een nieuwe reeks risico's die de SLA van uw AI-leverancier niet dekt.
Moderne applicaties sluizen AI-antwoorden rechtstreeks naar de pagina: gestreamde antwoorden, door AI gegenereerde UI-elementen, inline weergegeven toolaanroepresultaten. Elk van deze patronen creëert een oppervlak waar een gemanipuleerd, vertraagd of gekruist antwoord echte schade kan veroorzaken in de echte sessie van een echte gebruiker.
Responsinjection. Als een gekruist antwoord opmaak bevat en de app die weergeeft zonder sanering, wordt die opmaak uitgevoerd binnen een geauthenticeerde sessie. Het incident van de aanbieder is al opgelost, maar het injectierisico is structureel: elk pad waarbij ruwe modeluitvoer de DOM raakt is een doelwit, of de bron nu lekkage aan de aanbiederskant is of prompt-injection vanuit inhoud die het model heeft verwerkt.
Inmenging van scripts van derden. Scripts die op dezelfde pagina draaien als uw AI-integratie kunnen uitgaande API-aanroepen onderscheppen, responsladingen lezen voordat uw code ze verwerkt, of de modeluitvoer uit de DOM exfiltreren. Een gecompromitteerd analysefragment of ondersteuningswidget heeft dezelfde netwerk- en DOM-toegang als uw applicatie. AI-API-beveiliging kan niet worden beperkt tot de API-aanroep alleen; de paginaomgeving waar het in terechtkomt doet er ook toe.
Gegevensexfiltratie via AI-context. Applicaties die AI-agents toegang geven tot gebruikersgegevens, sessietokens of gevoelige staat creëren een kanaal dat aanvallers kunnen misbruiken door instructies in te bedden in inhoud die het model verwerkt; dit is prompt-injection op de applicatielaag. Het model beantwoordt de vraag die voor hem ligt; het is zich er niet van bewust dat het wordt gebruikt als gegevensexfiltratievector.
Kruissessielekken binnen uw product. Wanneer meerdere gebruikers een paginacontext delen (ingebedde AI-widgets in multi-tenant SaaS, gedeelde sessiepooling), dekt de isolatiegarantie van de API-aanbieder alleen zijn eigen infrastructuur. Als uw applicatie sessiestaat tussen gebruikers mengt, vindt cross-tenant lekken op uw laag plaats.
Geen van deze risico's vereist het compromitteren van de backend van de AI-aanbieder. Ze exploiteren de kloof tussen "de API-aanroep is geslaagd" en "het antwoord is veilig aangekomen in de juiste gebruikerssessie".
Wat dit betekent als je op LLM-API's bouwt
De praktische conclusie is een mentaliteitsverandering. Een antwoord van een LLM-API is data die terugkomt van een enorm gedeeld, snel veranderend systeem, geen vertrouwd, privékanaal tussen jou en het model. Op een slechte dag kan het fout, verouderd of gekruist met een andere klant zijn.
Behandel ze zo:
- Ga ervan uit dat een antwoord af en toe bij het verkeerde verzoek kan horen. Ontwerp geen flows waarin één gekruist antwoord stilletjes het record van een gebruiker beschadigt of het aan iemand anders blootstelt.
- Stuur geen gegevens naar een LLM-API die je niet zou tolereren als ze ergens anders opduiken, tenzij je contract en de controles van de aanbieder ze echt dekken. Voorwaarden voor zero-retentie en enterprise-isolatie zijn hier belangrijk.
- Valideer en beperk antwoorden voordat je ernaar handelt. Controleer vorm, type en plausibiliteit, zoals je elke niet-vertrouwde invoer zou valideren.
- Log genoeg om lekken te detecteren. Als je nooit verzoek- en antwoordmetadata opslaat, kun je het verschil niet zien tussen een modelfout en een antwoord dat nooit van jou was.
Wat je deze week kunt doen
- Breng elke plek in kaart waar een LLM-API-antwoord je systeem binnenkomt en markeer welke rechtstreeks in de browser worden weergegeven.
- Behandel die antwoorden als niet-vertrouwde invoer: valideer de structuur, escape alles wat in de pagina wordt weergegeven en injecteer nooit ruwe model-HTML zonder die te ontsmetten.
- Beslis expliciet welke gegevens je bereid bent naar elke aanbieder te sturen en bevestig de retentie- en isolatievoorwaarden die van toepassing zijn.
- Voeg logging en alerts toe die een misvormd antwoord kunnen onderscheiden van een antwoord dat niet bij het verzonden verzoek past.
- Houd de browserlaag in de gaten, waar AI-uitvoer, scripts van derden en gebruikersgegevens nu in dezelfde sessie samenkomen.
Hoe cside past
cside draait niet binnen de backend van Anthropic of van welke aanbieder dan ook, en kan een cache die de gegevens van de verkeerde klant teruggeeft niet repareren. Wat het wel aanpakt, is dezelfde klasse problemen een stap dichter bij je gebruiker: de browser, waar AI-antwoorden, scripts van derden en geauthenticeerde sessies nu dezelfde pagina delen.
cside biedt runtime-zichtbaarheid op wat er werkelijk in die browsersessie wordt uitgevoerd: welke scripts laden, hoe ze na deployment veranderen, welke gegevens ze lezen en waar ze die naartoe sturen. Naarmate meer applicaties modeluitvoer rechtstreeks in de pagina weergeven, is die zichtbaarheid de manier om de gevolgen aan de clientkant van een fout of gekruist antwoord te betrappen, zoals inhoud die in de verkeerde sessie wordt weergegeven of een script dat reikt naar gegevens die het nooit zou mogen aanraken.
Het bredere punt is hetzelfde dat cside altijd over scripts van derden heeft gemaakt, nu veralgemeend naar AI-infrastructuur. Elke laag die je toevoegt om sneller te gaan, is een laag waar gegevens op de verkeerde plek kunnen opduiken. Je kunt die lagen niet verwijderen, maar je kunt de laag instrumenteren die het dichtst bij je gebruiker staat.
Begin met client-side security voor runtime-scriptmonitoring, of met Privacy Watch om precies te zien wat de code op je pagina's verzamelt en verstuurt.
Verder lezen op cside
- Hoe gecompromitteerde scripts van derden prompts kunnen injecteren bij AI-agents
- On-device inferentie komt eraan voor je beveiligingsstack
- AI comprimeert de exploitcyclus
- Best practices voor het beveiligen van scripts van derden
Per 2026-06-05. De details van het Claude-API-incident weerspiegelen de statuspagina van Anthropic en de openbare gebruikersmeldingen die op die datum beschikbaar waren. Anthropic heeft het voorval gekarakteriseerd als verhoogde fouten en heeft, op het moment van schrijven, geen blootstelling van gegevens tussen gebruikers bevestigd.
