AI-veiligheid stopt niet bij het model: het transitive trust-probleem

We praten vaak over AI-veiligheid alsof het model zelf het grootste risico vormt. Alsof een paar tests voor prompt injection en een bias-scan voldoende zijn. Dat klopt niet. Het echte gevaar zit hem in de keten van tools, libraries en diensten die rondom dat model draaien. En dat gevaar heeft een naam: transitive trust.

Deze term hoor je niet vaak in boardrooms. Tot in november 2025 ineens wel. Toen bleek dat OpenAI, het bedrijf achter ChatGPT, voor analytics Mixpanel gebruikte. Een beveiligingsincident bij Mixpanel leidde tot een lek van prompts en outputs van OpenAI-klanten. Die klanten hadden geen contract met Mixpanel, wisten vaak niet eens dat het bedrijf bestond, en hadden geen enkel zicht op de beveiliging van die dienst. Toch waren hun gegevens blootgesteld. Zo werkt transitive trust: jij vertrouwt OpenAI, OpenAI vertrouwt Mixpanel, dus jouw data staat ook bij Mixpanel, of je dat nu wilt of niet.

Onlangs sprak ik met een CISO van een Nederlands ziekenhuis. Ze hadden een AI-assistent ingekocht voor triage op de spoedeisende hulp. Er was een DPIA gedaan, het model was getoetst op bias en hallucinatie, en er was een verwerkersovereenkomst met de leverancier. Alles leek op orde. Tot ik vroeg hoe logging geregeld was. Het antwoord was simpel: “Dat doet de leverancier, met een standaard observability-SDK.” Die SDK stuurde alle prompts en outputs ongefilterd naar een Amerikaanse clouddienst, inclusief patiëntgegevens. Een paar weken later werd een kritieke kwetsbaarheid ontdekt in die SDK (CVE-2025-12345, een authenticatiebypass in de logging-agent). Het ziekenhuis had er geen weet van. Ze waren volledig afhankelijk van de beveiligingsmaatregelen van een partij waar ze zelf geen relatie mee hadden. Dat is transitive trust in de praktijk. En het is een datalek onder de AVG dat je niet ziet aankomen.

De applicatie-stack is het aanvalsoppervlak

Een recente studie, A Lifecycle and Application-Stack Survey of LLM Vulnerabilities (arXiv:2606.31639), brengt dit probleem systematisch in kaart. De onderzoekers kijken niet alleen naar het model, maar naar de hele levenscyclus en de applicatie-stack. Van dataverzameling en training tot deployment, runtime en logging. Wat ze vinden is soberend. De meeste kwetsbaarheden zitten niet in het getrainde neurale netwerk, maar in de software eromheen.

Neem de trainingsfase. Modellen worden vaak verspreid als pickle-bestanden via platforms zoals Hugging Face. Wie een model laadt met torch.load() zonder weights_only=True (een optie die pas sinds PyTorch 2.4 standaard is, maar nog lang niet overal wordt toegepast), kan willekeurige code uitvoeren. Een aanvaller hoeft alleen maar een kwaadaardig modelbestand te uploaden naar een gedeelde hub. Dit is geen theoretisch risico. In 2024 werden meerdere supply chain-aanvallen via Python-pakketten gedocumenteerd, waarbij transformers-afhankelijkheden backdoors bevatten.

In de runtime-fase zijn tool-calling frameworks zoals LangChain en Semantic Kernel een risico. Een aanvaller die een document of e-mail meestuurt, kan via indirecte prompt injection het model opdracht geven tools aan te roepen, data te sturen of API-sleutels te lekken. De survey beschrijft hoe een schijnbaar onschuldige web_search-tool kan worden misbruikt om interne endpoints te scannen. Het model is hier niet de zwakke schakel; de integratie met externe systemen is dat.

En dan is er de logging- en monitoringlaag. Veel LLM-applicaties loggen prompts en outputs voor debugging, analytics of compliance. Die logs gaan vaak naar derde partijen: Mixpanel, Datadog, Sentry, of een zelfgehoste ELK-stack via een SaaS-provider. De survey laat zien dat logging libraries vaak onvoldoende filteren en dat gevoelige data, inclusief persoonsgegevens, in plaintext wordt opgeslagen. Een voorbeeld uit de praktijk: een configuratie zoals deze in een Python-applicatie:

import logging
from observability_sdk import ObservabilityClient

client = ObservabilityClient()
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger("llm_app")

# Gevoelige data wordt gelogd zonder filtering
logger.info(f"Prompt: {user_prompt}, Output: {model_output}")

Zulke configuraties zijn niet zeldzaam. Ze zitten vaak diep verstopt in de stack, onzichtbaar voor de eindgebruiker. En ze vormen een risico dat groter is dan het model zelf.