KENSAI-onderzoek: RAG-backendlekken zijn een architectuurfout, geen prompt-ongeluk

RAG-systemen lekken niet omdat één prompt vreemd deed. Ze lekken omdat teams backend-bedrading, debugsporen en gespreksresten blootstellen aan de clientlaag en dat vervolgens een implementatiedetail noemen.

Waarom dit signaal vandaag telt

Een recente audit van een medische RAG-chatbot is belangrijk omdat die liet zien dat gewone, client-zichtbare oppervlakken prompts, configuratiedetails, schema’s, metadata en zelfs nabije gespreksgeschiedenis kunnen lekken. Daar was geen filmwaardige jailbreak voor nodig. Nieuwsgierigheid plus browserinspectie waren genoeg.

Wat er echt kapotging

De kernfout zat niet alleen in de modeloutput. Het product stelde backend-artefacten bloot via paden die de client kon inspecteren, waardoor privé operationele details publieke aanwijzingen werden. Vanaf dat moment leert een aanvaller hoe het systeem gevoelige context ophaalt, routeert en opslaat.

Waarom dit een architectuurbug is

Als prompts, routeringsregels, retrievalmetadata en recente sessiesporen te dicht op de frontend zitten, ziet de gebruiker meer dan de interface hoort te tonen. Dat is geen formuleringprobleem. Het is een grensprobleem van toestand. Losse plumbing creëert kansen voor promptinjectie, sturing en exfiltratie.

Wat teams nu moeten doen

Beperk client-zichtbare metadata, splits debug-oppervlakken van gebruikerslevering, laat tijdelijke sporen snel vervallen en inspecteer browser-zichtbare payloads alsof het vijandige onthullingen zijn. Als een veld niet nodig is voor de gebruikersactie, moet het niet voor gemak meereizen.

De KENSAI-les

Agentprivacy win je in interfaces, headers, payloads en toestandsgrenzen. Als de browser meer kan zien dan de gebruiker nodig heeft, staat het systeem al te los. Veilige RAG is saai op de juiste manier: minder blootstelling, strakkere naden, minder verrassingen.