Privacy in LLM-agents: het lek zit niet in de output, maar in de informatiestromen

We denken verkeerd over privacy bij AI-agents. Het risico zit niet in wat ze zeggen, maar in wat ze onderling delen. De eerste reactie is vaak: filter de output. Scan gegenereerde tekst op BSN’s, namen of medische gegevens en verwijder die. Maar dat helpt niet als het water al door de muren loopt. De echte problemen zitten in de informatiestromen: de queries die een agent verstuurt, de tussenresultaten die hij opslaat, de notities in zijn geheugen en de berichten naar andere agents. Een recente studie op arXiv (2606.26866) maakt dit duidelijk. Privacy in multi-agent LLM-systemen draait niet om betere filters op de output, maar om controle op de informatie die tussen componenten stroomt. Zowel compositie als communicatie tussen agents moet daarbij in scope zijn.

Onlangs testte ik een multi-agent systeem voor een zorginstelling. De opdracht leek eenvoudig. Een triage-agent haalt patiëntgegevens op uit het EPD, vat de voorgeschiedenis samen en stuurt die door naar een planningsagent die een afspraak inplant. De output voor de patiënt was netjes op orde, geen BSN, geen medicatie. Maar in de logs viel het op. De triage-agent schreef de ruwe EPD-data, inclusief BSN en labuitslagen, weg naar een gedeeld geheugenblok. Dat blok werd vervolgens ook gelezen door een rapportage-agent die alleen geanonimiseerde statistiek hoefde te zien. De output was schoon. De informatiestroom was een lek. En dat is precies wat we over het hoofd zien. We beoordelen agents op wat ze zeggen, niet op wat ze doen.

Het probleem zit hem in de structuur. LLM-agents zijn geen afzonderlijke chatbots. Ze bestaan uit meerdere lagen: een taalmodel, tools zoals API’s en databases, een geheugen (kort, lang, gedeeld) en in multi-agent setups ook communicatiekanalen tussen agents. Privacygevoelige data kan op elk niveau binnenkomen en elders weer naar buiten sijpelen. Een query naar een interne API bevat vaak meer dan nodig. Denk aan een zoekopdracht die een volledige naam meestuurt in plaats van een anoniem ID. Tussenresultaten worden gelogd of gecached zonder dat iemand controleert of die logs onder dezelfde beveiliging vallen. Memory writes zijn riskant. Een agent slaat een samenvatting op voor later gebruik, maar die bevat nog steeds herleidbare gegevens. En inter-agent communicatie verloopt vaak via ongestructureerde kanalen zonder toegangscontrole. Het gevolg is een netwerk van datastromen dat geen enkele outputfilter volledig kan afdekken.

Wat opvalt: de oplossing komt niet uit de AI-wereld, maar uit klassieke beveiliging. Information-flow control (IFC) bestaat al decennia. Het wordt gebruikt in besturingssystemen en netwerken. Het idee is simpel. Elke data-eenheid krijgt een label, zoals gezondheidsdata, BSN of publiek. Elke bewerking van die data moet voldoen aan regels die bepalen of het label mag stromen naar de volgende stap. Bij een LLM-agent label je niet alleen de uiteindelijke output, maar ook de tussenliggende stappen: de query, het API-antwoord, de geheugeninhoud, het bericht naar een andere agent. De IFC-controller blokkeert acties zodra een datastroom een label wil doorgeven aan een component dat daar niet geautoriseerd voor is.

Een voorbeeld. Stel je een agent voor die een tool aanroept: query_epd(patient_id). Het resultaat krijgt het label L{gezondheidsdata, BSN}. Als de agent dat resultaat wil doorsturen naar een externe LLM voor samenvatting, checkt de IFC-controller of die LLM in de policy staat als toegestane bestemming voor BSN. Is dat niet zo, dan wordt de actie geblokkeerd. Niet pas bij de output, maar op het moment dat de informatiestroom ontstaat. Dat geldt ook voor een memory write. Als de agent een notitie wil opslaan met label L{gezondheidsdata}, moet het geheugencomponent in de policy staan als geautoriseerde bestemming voor dat label. Zo voorkom je dat gevoelige data onbedoeld wordt opgeslagen of gedeeld.