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.
Het interessante is niet of één aanbieder een slechte middag had. Het is de foutklasse. 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 volkomen onbekende 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 geen teken dat één bedrijf nalatig is. Het is een eigenschap van de architectuur waarop de hele sector bouwt.
Wat dit betekent als je op LLM-API's bouwt
De praktische conclusie is een mentaliteitsverandering. Een antwoord van een LLM-API is geen vertrouwd, privékanaal tussen jou en het model. Het zijn gegevens die terugkomen van een enorm gedeeld, snel veranderend systeem en die, op een slechte dag, fout, verouderd of gekruist met een andere klant kunnen 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.
Er is een versie hiervan op de browserlaag die gemakkelijk te missen is. Een groeiend aantal apps sluist modeluitvoer rechtstreeks de pagina in: gestreamde antwoorden, door AI gegenereerde HTML, inline weergegeven toolresultaten. Als die uitvoer gekruist of geïnjecteerd kan zijn, verandert het blindelings weergeven ervan een backendprobleem in een probleem aan de clientkant. Je kunt eindigen met het tonen van de inhoud van een andere gebruiker aan jouw gebruiker, of met het uitvoeren van mark-up die je niet hebt geschreven, binnen een sessie waarin je gebruiker al is geauthenticeerd.
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.
