OWASP LLM Top 10 uitgelegd

U bent verantwoordelijk voor het aanwijzen van eigenaren voor elk risico dat de OWASP LLM Top 10 beschrijft, voor het vastleggen van verificatie voordat u op de applicatie vertrouwt, en voor het documenteren van welke onzekerheid overblijft nadat technische maatregelen zijn genomen.

Een analyse van 13 november 2026 van het OWASP-raamwerk voor risico's in toepassingen rond grote taalmodellen stelt dat governance en technische beheersing samen moeten werken, en dat geen enkele maatregel alleen volstaat. Een juridisch memorandum kan toegangsbeperkingen respecteren en toch onbetrouwbare bronnen citeren; een assistent kan beveiligd zijn tegen injectie en toch bevoegdheden hebben die geen enkele taak rechtvaardigt. In onze beoordeling ligt de praktische waarde van het raamwerk niet in het afvinken van categorieën, maar in het vertalen van elk risico naar een inspecteerbare beslissing: wie bezit het, welk bewijs toont dat het onder controle is, en welke wijzigingen vereisen herbeoordeling.

Wie bepaalt wat de applicatie mag doen met vertrouwelijke informatie?

De gegevenseigenaar moet vooraf bepalen wat een applicatie mag vrijgeven voordat het model het materiaal ontvangt. Vertrouwelijke informatie kan verschijnen in gegenereerde antwoorden, in opgehaalde passages, in bewaarde prompts of in operationele logs — niet alleen in wat gebruikers zien. Een privacybeoordeling moet de informatie daarom door de volledige workflow volgen.

Voor een bedrijfsgezondheidssamenvatting kunt u synthetische dossiers gebruiken met onderscheidende identificatoren en vervolgens uitgaande verzoeken, antwoorden, logs en retrievalresultaten inspecteren op onbedoelde vrijgave. Een voorgestelde workflowwijziging moet aangeven welke velden de omgeving verlaten, welke worden gemaskeerd, en waar originelen worden hersteld. Onafhankelijke beoordeling moet bepalen of de resterende context de betrokkene nog identificeert. Praktische regel: het verwijderen van een naam toont niet aan dat het omliggende verhaal veilig is om vrij te geven.

• Onbedoelde vrijgave in antwoorden — vertrouwelijke gegevens die het model reproduceert of afleidt uit trainingsgegevens of retrieval.
• Blootstelling in logs en tussenresultaten — gevoelige informatie in bewaarde prompts, indexen of operationele sporen die gebruikers niet zien.
• Onjuiste retrievalrechten — systemen die documenten ophalen zonder te controleren of de gebruiker ze mag zien.
• Pseudonimisering zonder juridische beoordeling — naamverwijdering die niet garandeert dat de context geen heridentificatie toestaat.
• Gedeelde indexen voor gescheiden gegevens — embedding-systemen die cross-cliënt of cross-zaak retrieval mogelijk maken.

Welke afhankelijkheden moet u inspecteerbaar maken voordat u de applicatie goedkeurt?

Inkoop heeft een overzicht nodig van de componenten die de applicatie binnenkomen en van het proces om ze te wijzigen. De relevante afhankelijkheden reiken verder dan het basismodel: embedding-diensten, softwarebibliotheken, connectoren, datasets en hostingafspraken kunnen allemaal van invloed zijn op wat de applicatie uitvoert en waar informatie naartoe gaat.

Geef de platformeigenaar verantwoordelijkheid voor technische afhankelijkheden, waarbij inkoop- en privacyspecialisten hun respectieve blootstelling beoordelen. Stel dat een onderzoeksteam een bibliotheek voor documentparsing toevoegt om vertrouwelijke rapporten te verwerken. De beoordeling moet de herkomst, versie, uitvoeringsgedrag en netwerktoegang vaststellen voordat goedkeuring volgt. Een subprocessorbeleid waarin externe leveranciers worden beschreven is één type document; het is geen bewijs over de regelingen van een andere leverancier.

1. Inventariseer alle binnenkomende componenten — documenteer modellen, embedding-diensten, bibliotheken, connectoren en datasets met versie en herkomst.
2. Bepaal wie wijzigingen mag goedkeuren — wijs eigenaarschap toe voor technische updates en definieer welke wijzigingen een herbeoordeling activeren.
3. Test wijzigingen voordat u ze implementeert — voer regressietests uit en inspecteer gedragsveranderingen voordat nieuwe versies live gaan.
4. Volg de netwerktoegang van elke afhankelijkheid — bepaal welke externe diensten elke component aanroept en wat het verzendt.
5. Bewaar configuratieversies met goedkeuringssporen — link elke geteste configuratie aan de beoordelaar die deze heeft gevalideerd.

Hoe voorkomt u dat ongeautoriseerde instructies de applicatie overnemen?

Prompt injection is een kwestie van wiens instructies een applicatie opvolgt. Het onderscheid ligt tussen directe injectie via gebruikersinvoer en indirecte injectie via opgehaalde documenten, webpagina's, e-mails en toolresponses. Een document kan daarom zowel bewijs zijn om te analyseren als een vehikel voor instructies die de applicatie niet zou moeten opvolgen. Het onderscheid is van belang wanneer het model toegang heeft tot vertrouwelijke dossiers of verbonden tools kan aanroepen.

Wijs de applicatie-eigenaar de verantwoordelijkheid toe voor het gehele verwerkingspad, niet alleen voor het promptvak. Stel dat een juridische assistent een contract ophaalt dat instructies bevat om de zaaksamenvatting naar een extern adres te sturen. Verificatie moet pogingen tot toolaanroepen en gegevenstoegang vastleggen, zelfs als het uiteindelijke antwoord onschuldig lijkt. Gebruik geparametriseerde query's, allow-lists voor bewerkingen en sandboxed rendering waar passend. Bewaar het goedgekeurde plan en het werkelijke uitvoeringsresultaat, zodat beoordelaars verschillen kunnen vaststellen.

Welke acties mag de applicatie automatisch uitvoeren zonder goedkeuring?

Een toepassing zou alleen de bevoegdheid moeten krijgen die haar taak vereist. Overmatige functionaliteit, overmatige rechten en overmatige autonomie zijn terugkerende oorzaken van schadelijke acties. De trigger hoeft geen aanval te zijn: een dubbelzinnig verzoek, foutieve output of gecompromitteerd verbonden component kan ingrijpend worden wanneer de toepassing toestemming heeft om te handelen.

Een communicatie-assistent die correspondentie opstelt, heeft niet automatisch toestemming nodig om die te verzenden. De workfloweigenaar moet elke tool rechtvaardigen, leestoegang scheiden van schrijftoegang en acties identificeren die expliciete goedkeuring vereisen. Goedkeuring moet de voorgestelde actie tonen, niet louter een geruststellende samenvatting. Menselijke goedkeuring kan de blootstelling verminderen, maar een gehaaste beoordelaar kan een onjuiste actie goedkeuren. Onafhankelijke beoordeling is nuttiger wanneer de beoordelaar de onderliggende operatie en het ondersteunende bewijs kan inspecteren.

Hoe zorgt u ervoor dat opgehaalde informatie niet over cliënten, patiënten of zaken heen lekt?

De eigenaar van het retrievalsysteem zou de toegang op het moment van retrieval moeten verifiëren, voordat documenten in de context van het model terechtkomen. Voor professionele kennisbanken zijn relevantie en autorisatie afzonderlijke vragen. Een passage kan nauw aansluiten bij een zoekopdracht terwijl deze bij een andere cliënt, patiënt, afdeling of vertrouwelijke zaak hoort.

Denk aan een notariskantoor dat retrieval-augmented generation toepast over cliëntdossiers. Testen zou cross-cliënt-retrieval moeten proberen met realistische documentovereenkomsten, en vervolgens de teruggegeven document-identifiers en passages moeten inspecteren. Een antwoord dat beperkte tekst weglaat, toont niet aan dat de retrievallaag deze heeft achtergehouden. Beoordelaars hebben bewijs nodig vanuit de retrievalgrens zelf. Wijzigingen aan filters, indexen of embeddingdiensten zouden regressietests moeten ondergaan vóór uitgave. Onafhankelijke beoordeling zou gevallen van geweigerde toegang moeten omvatten, en niet alleen voorbeelden die het verwachte antwoord ophalen.

Wat doet u wanneer gegenereerde inhoud naar een ander systeem gaat?

De categorie improper-output-handling betreft toepassingen die modeloutput doorgeven zonder passende validatie, codering of beperking. Het onderscheid ligt tussen het lezen van een voorgestelde actie en het uitvoeren ervan. Een door een model gegenereerde databasequery, shellopdracht of webfragment moet worden beoordeeld als niet-vertrouwde input, zelfs wanneer het binnen een goedgekeurde toepassing is ontstaan.

De eigenaar van de integratie moet verantwoordelijk zijn voor downstreamvalidatie. Denk aan een analist die een assistent vraagt een klantrecord bij te werken: het model moet de beoogde velden en waarden voorstellen, terwijl applicatiecode het schema, de rechten en de toegestane bewerking controleert. Een gevalideerd wijzigingsplan moet het doelrecord, de voorgestelde wijzigingen, de geldende beperkingen en het verwachte resultaat tonen. Een onafhankelijke beoordelaar kan het plan vervolgens vergelijken met het oorspronkelijke verzoek voordat een beperkte uitvoeringsstap het toepast. Een leesbare uitleg is geen validatie van de opdracht eronder.

Technische maatregelen kunnen blootstelling verminderen, maar ze vervangen geen professioneel oordeel. Begin met een inventaris van modellen, databronnen, retrievalopslag en gekoppelde tools. Identificeer wie ze kan wijzigen, welke versies zijn getest en welke wijzigingen een herbeoordeling activeren. Vraag vervolgens om een beknopt bewijspakket dat de ingezette configuratie beschrijft. Resultaten van een smaller prototype tonen niet aan hoe een applicatie zich gedraagt nadat nieuwe documenten, rechten of tools zijn toegevoegd. Het bewijs moet voldoende zijn voor het beoogde gebruik van de bewering, en niet slechts voldoende om het antwoord aannemelijk te maken.