Een nieuwe kwetsbaarheid in de manier waarop AI-aanbieders hun interne redenering tussen API-aanroepen uitwisselen, zet ontwikkelaars op scherp. In het onderzoek staat centraal: een API-lek AI-redenering waarbij verborgen “reasoning objects” uit sessielogs kunnen worden gereplayd. Daardoor kunnen onderzoekers interne inhoud en zelfs gevoelige gegevens terughalen.
Belangrijk: de onderzoekers benadrukken dat ze geen kwaadaardige exploit in het wild hebben gedocumenteerd. Wel adviseren ze teams die agentlogs of ruwe API-transcripten delen om verborgen reasoningblokken te verwijderen.
Wat is er precies mis met de AI-redenering?
OpenAI, Anthropic en Google gebruiken in hun reasoning-API’s mechanismen om redenering tussen API-calls te bewaren zonder dat de onderliggende tekst direct bij de client terechtkomt. In plaats daarvan worden gevoelige tussenstappen als “encrypted reasoning” of vergelijkbare, afgeschermde blokken overgedragen.
Volgens het onderzoek is de zwakte niet dat de encryptie werd gekraakt. De crux ligt in het feit dat een blok dat in de ene sessie is gemaakt, in een andere sessie kan worden hergebruikt (replay). Als de provider zo’n opaque/afgeschermd blok accepteert en verwerkt, kan het systeem de “verborgen” inhoud alsnog reconstrueren.
Vier manieren van misbruik uit het onderzoek
De onderzoekers beschrijven meerdere misbruikroutes. Die laten zien dat het gevaar breder is dan alleen het uitlekken van één gebruiker.
- Stelen van proprietary redenering om modellen te distilleren: verborgen denkstappen kunnen worden omgezet naar trainingsmateriaal voor een kleiner model.
- Gegevens uit traces van andere gebruikers: wanneer traces publiek worden gedeeld, kan een aanvaller proberen privé-informatie te reconstrueren uit die gepubliceerde redeneringsobjecten.
- Ontsnappen aan veiligheidsmechanismen: gevoelige output die achter een “veilig zichtbare” beantwoording is verstopt, kan alsnog worden achterhaald via de verborgen reasoningblokken.
- Prompt-injectie verstoppen in opaque reasoning blocks: een instructie kan in de afgeschermde structuur worden ingebouwd, waardoor deze niet in de zichtbare tekst verschijnt, maar wél effect heeft bij replay.
Hoe groot is het effect? Getallen uit publieke agentlogs
Het onderzoek baseert zich op een grote set openbare agent-trajectory’s. Over 6.708 openbare agent-journey’s rapporteert het team dat er 315.320 thinking blocks werden gedecodeerd.
Na het uitsluiten van benchmarkbronnen telden de onderzoekers 704 privacy-gerelateerde artefacten die herleidbaar zijn naar echte gebruikerssessies. In de bewijsvoering kwamen onder meer 62 API-keys, 33 wachtwoorden, 24 access tokens en zeven private keys naar voren.
Dat zijn enorme categorieën van gegevens. Tegelijk is er een belangrijke nuance: het cross-user misbruik vereist dat een aanvaller een geschikt encrypted reasoning block in handen krijgt (bijvoorbeeld uit een log die is gepubliceerd) én API-toegang tot een compatibel model binnen dezelfde provider-familie.
Beperking: geen “zomaar toegang” tot privéchats
De aanval levert niet automatisch willekeurige toegang tot privégesprekken. Volgens de paper valt het risico in een begrensd profiel: ontwikkelaars en teams die agentlogs met intacte reasoningobjecten delen, vormen een herkenbare groep. Het gaat dus niet om “iedere API-gebruiker” als algemene kwetsbaarheid.
Wel kan het probleem ontstaan wanneer leesbare conversaties netjes zijn geschoond, maar verborgen velden niet worden verwijderd. Dan kan de afgeschermde informatie alsnog als puzzelstukje blijven zitten in het opaque blok.
Waarom kunnen zwakkere modellen toch informatie onthullen?
In de testopstelling zagen de onderzoekers dat de reasoningblokken draagbaar bleken over sessies, gebruikers en zelfs modellen binnen dezelfde provider-ecosystemen. Daarbij vonden ze een aanvalspad waarbij een “zwakker” compatibel model kan optreden als wat zij een fuzzy decoder noemen.
Concreet noemen ze voorbeelden van “ontvangers” zoals Claude Haiku 4.5 voor Claude-traces, GPT-5.6 Luna voor GPT-traces en Gemini Robotics ER-1.6 voor Gemini-traces. De onderzoekers zetten die aanpak in om redenering te transcriberen die oorspronkelijk door een sterker model was geproduceerd.
Dat maakt de beveiligingsimplicatie breder: het is niet alleen de oorspronkelijke sessie die risico vormt, maar ook latere verwerking door (compatibele) modellen die de afgeschermde structuur kunnen interpreteren.
Prompt-injectie zonder zichtbare instructie
Naast het terughalen van privacy-artikelen beschrijft het onderzoek ook een proof of concept met prompt-injection. De kern is dat de aanvaller een kwaadaardige instructie kan “verstoppen” in een opaque reasoning block.
Bij replay wordt die instructie door het ontvangende model geactiveerd, terwijl de geïnjecteerde tekst niet zichtbaar is in de normale transcriptweergave. Het effect dat de onderzoekers rapporteren is dat het model daarna een actie kan toevoegen die de aanvaller stuurt—zonder dat die instructie in de zichtbare velden terug te vinden is.
Is de kwetsbaarheid nog te misbruiken? Wat onderzoekers zeggen
De onderzoekers melden dat ze de bevindingen hebben gedeeld met de getroffen partijen. In het openbaar beschikbare verhaal geven zij aan dat mitigaties de aanvalstop zetten na correctie.
In hun reproduceerbaarheid stellen ze dat de hoofdextractie-aanval niet meer reproduceerbaar is vanaf augustus 2026. Tegelijk plaatsen ze kanttekeningen: omdat er geen publieke bevestiging van de providers in het dossier zichtbaar was, hangt een deel van de “fix-status” vooral op hun eigen reproduceerbaarheidsverklaring.
Dat betekent voor organisaties: ga er niet vanuit dat “het wel losloopt”, maar zorg dat je je eigen data-uitwisseling en logging juist inricht—ook omdat bestaande repositories mogelijk al risico bevatten.
Wat moeten ontwikkelaars en security teams nu doen?
De praktische aanbevelingen uit het onderzoek zijn helder en vooral gericht op dataminimalisatie. Als je werkt met agentlogs of je deelt traces, maak dan een expliciete keuze om verborgen reasoningblokken te verwijderen.
- Strip reasoning blocks en opaque reasoning velden voordat je traces deelt of archiveert.
- Voorkom dat raw API-transcripten terechtkomen in openbare repositories, issues of externe logging.
- Sanitize is niet genoeg: focus niet alleen op de leesbare conversatie, maar ook op afgeschermde velden.
- Controleer compatibele model-switches in je integratie: het onderzoek wijst erop dat handling en documentatie per aanbieder is aangepast.
De onderzoekers benoemen dat providers hun documentatie en omgang met “encrypted reasoning” hebben bijgesteld. OpenAI beschrijft nog steeds dat applicaties stateless history soms handmatig kunnen afspelen met encrypted reasoning items, terwijl Google stelt dat de backend thought-compatibiliteit beheert bij sessiewissels. Bij Anthropic zou het denkenblok volgens hun huidige uitleg tied to the model zijn en verwijderd moeten worden bij modelwissel.
Focus op logging: dit soort lekken start vaak bij gedeelde traces
Een opvallend onderdeel van het verhaal is dat de zwakte in feite pas een groot probleem wordt als verborgen componenten in publieke data belanden. Het onderzoek laat zien dat honderden duizenden thinking blocks al in openbare omgevingen terug te vinden waren.
Daarom is het verstandig om je keten rondom “observability” en “debugging” te herzien. Wat je logt voor analyse moet niet automatisch deelbaar zijn. Zet liever geautomatiseerde filters op gevoelige velden en bouw een beleid voor het delen van agentoutput.
Meer context: wat dit betekent voor je LLM security
Dit soort incidenten past in een bredere trend: LLM-veiligheid gaat niet alleen over input, maar ook over hoe je tussenstappen opslaat, doorgeeft en opnieuw gebruikt. Als je je meer wilt verdiepen in aanvallen waarbij supply chain-achtige patronen of ketencompromissen een rol spelen, kan dit relevant zijn: LiteLLM supply chain aanval: 2.500 organisaties geraakt.
Ook kun je kijken naar hoe aanvallen gebruikmaken van verwerking en componenten in de omgeving. Een gerelateerde invalshoek is het scenario rond Malicious LiteLLM en Trivy-hack: 3 stappen, waar misbruik juist in de keten ontstaat.
Conclusie
Het onderzoek naar een API-lek AI-redenering maakt één ding heel duidelijk: zelfs als encryptie niet “gebroken” wordt, kan het hergebruik (replay) van intacte opaque reasoningblokken alsnog leiden tot datalekkage. In het bewijs kwamen privacy-artikelen naar voren op schaal, waaronder API-keys, wachtwoorden en tokens.
Voor ontwikkelaars ligt de sleutel vooral in preventie: verwijder verborgen reasoningblokken uit gedeelde traces en publiceer geen ruwe API-transcripten. Hoewel de onderzoekers aangeven dat de belangrijkste aanval vanaf augustus 2026 niet meer reproduceerbaar is, is het verstandig om je eigen logging en tracebeleid nu direct te verscherpen.
Bron: https://thehackernews.com/2026/08/openai-anthropic-google-api-flaw-let.html
