Veiligheid & grenzen
Waar de stemming en het incidentregister uiteenlopen, telt de richting
De OWASP-lijst van 2026 legde de stem van practitioners naast 7.714 incidenten. Waar die twee uiteenlopen zegt de richting meer dan de omvang.
Een ranglijst van risico's is een optelsom van meningen, en dat is jarenlang het bezwaar geweest tegen de OWASP-lijsten. De editie van 2026 doet daar voor het eerst iets aan.
In het voorwoord bij de GenAI/LLM Top 10 schrijft de projectleiding dat ze de stemming naast een register van echte incidenten hebben gelegd. De uitkomst was niet dat de twee elkaar bevestigden.
De kloof tussen wat bouwers vrezen en wat er is misgegaan, loopt twee kanten op. Eén kant krijgt een verklaring mee, de andere niet.
Wat er voor het eerst gemeten is
Volgens het voorwoord telt het register 7.714 gemelde incidenten uit publieke kwetsbaarheidsdatabases en een database met AI-schade. Daarvan droegen er 6.639 genoeg detail om door hun classificeerders ingedeeld te worden.
De weging staat er expliciet bij: de stem van de gemeenschap draagt driekwart, de incidentdata een kwart. Die verhouding is een keuze die ze uitleggen — een kwart is genoeg om een entry een tier te verplaatsen wanneer de kloof breed is, en te weinig om één rommelig jaar aan data de lijst te laten herschrijven.
De kloof loopt twee kanten op
Promptinjectie is het bekende geval. Het staat op nummer één in de stemming, en het valt buiten de top tien zodra je uitsluitend op het ruwe incidentregister rangschikt.
Het voorwoord noemt dat een verdedigingseffect: teams bestrijden injectie hard, waardoor er minder schone exploits in een publieke database belanden. Die verklaring is aannemelijk, en ze presenteren hem ook als uitleg en niet als bevinding.
Het interessante geval is het andere. Over misinformatie schrijft de projectleiding dat stemmers het onderaan zetten en het incidentregister bovenaan, en ze noemen dat“the widest gap in the direction that actually hurts”. Daar staat geen verklaring bij die het gat wegneemt.
Wat er in de onderschatte entry staat
De entry over misinformatie beschrijft geen taalprobleem maar een systeemfout. Modeluitvoer stuurt tool-aanroepen aan, genereert code en leidt systeemtoestand af.
De formulering die ertoe doet staat er letterlijk: “In agentic systems, misinformation often manifests as incorrect state, reasoning, or evidence that is consumed by downstream components, leading directly to unintended actions.” Een verkeerd antwoord wordt dus een verkeerde handeling, via een keten die niemand meer leest.
De maatregelen die die entry noemt, zijn opvallend bekend. Scheid generatie van uitvoering, controleer een claim vóórdat er iets gebeurt, valideer de argumenten van een tool-aanroep, en beperk de blast radius met least privilege en sandboxing.
Waarom dat lijstje bekend voorkomt
Het is dezelfde vorm als wat het vorige stuk in deze rubriek vaststelde voor promptinjectie: de controle hoort rond de handeling, niet rond de tekst. Daar kwam die conclusie uit vijf preprints en een leveranciersdocument; hier staat hij in de aanbevelingen bij een risico dat met promptinjectie weinig te maken heeft.
Dat twee verschillende oorzaken bij dezelfde maatregel uitkomen, is op zichzelf een aanwijzing. Het suggereert dat de maatregel niet bij de oorzaak hoort maar bij de plek waar beide eindigen.
De lijst trekt zelf een grens
Twee dingen in deze editie maken die plek expliciet. Het voorwoord zegt dat het risico verhuist zodra het model een actor wordt met gereedschap, geheugen en gevolgen — dan hoort het bij een aparte lijst voor agentische systemen, en de twee dekken elkaars grond niet.
En de entry over te veel handelingsruimte definieert de kwetsbaarheid als het mogelijk maken van schadelijke handelingen “regardless of what is causing the LLM to malfunction”. Hallucinatie en promptinjectie staan er als twee aanleidingen naast elkaar.
Wat daaruit volgt
De lijst zegt hier zelf dat de schade niet aan de oorzaak hangt maar aan de ruimte om te handelen. Een verdediging die om de handeling ligt, hoeft dus niet te weten of de verkeerde uitvoer van een aanvaller kwam of van het model zelf.
Vanaf hier: mijn interpretatie
Alles hierboven is terug te lezen in de drie bronnen onderaan. Wat nu volgt staat daar niet in: het is wat ik uit die meetmethode afleid voor het lezen van elke risicolijst, ook die van mezelf. Neem het als voorstel, niet als bevinding.
Wat hieruit volgt
- De richting van een kloof zegt meer dan de omvang. Staat de stemming hoog en het register laag, dan is er een verklaring die je kunt toetsen. Staat het omgekeerd, dan is er iets dat je onderschat, en dan gaat de kloof niet over de meting maar over jou.
- Een verklaring bij een gat is zelf een claim. “Onze verdediging werkt” is een aantrekkelijke uitleg voor weinig incidenten, en hij is niet te onderscheiden van “we meten het niet”. Wie die uitleg gebruikt, hoort erbij te zeggen hoe hij zou merken dat hij ernaast zit.
- De maatregel hoort bij de plek, niet bij de oorzaak. Beide entries komen uit op scheiden, controleren en begrenzen. Dat is goedkoper dan per oorzaak een eigen verdediging bouwen, en het dekt de oorzaak die je nog niet kent.
- Rangschik twee keer. Eén keer op wat je vreest, één keer op wat je incidenten laten zien. Elk verschil zonder verklaring is het eerstvolgende ding om te bouwen — dat is de oefening die de prompt onderaan dit stuk uitvoert.
Waar het ophoudt
Drie voorbehouden, waarvan één die het stuk zelf raakt
Alle drie de bronnen komen uit één publicatie. Dat is voor dit onderwerp verdedigbaar — een stuk over hoe deze lijst is samengesteld, leunt op die lijst — maar het betekent dat er geen tweede partij is die de weging of de classificatie bevestigt. Dit stuk toetst de rangschikking dus niet; het leest hem.
Het incidentcorpus is niet per categorie openbaar. Of de classificeerders 6.639 incidenten goed hebben ingedeeld, is van buitenaf niet na te gaan. De projectleiding noemt de data zelf rommelig, en dat is precies de reden dat ze er een kwart gewicht aan geven.
De rangorde veroudert sneller dan de methode. Welke entry op welke plek staat, is een momentopname van augustus 2026. Wat blijft staan is de vorm van het antwoord: twee rangschikkingen naast elkaar, en de richting van het verschil als het signaal.
Toets het op je eigen systeem
Toetst of jouw risicolijst op vrees of op bewijs is gerangschikt, en wat het verschil betekent.
Ik wil weten of de risico's die wij het zwaarst wegen ook de risico's zijn die ons het vaakst raken. Stap 1 — noem de vijf risico's die dit systeem volgens de bouwers het zwaarst zijn. Baseer je op wat er in de code, de reviews en de documentatie aan verdediging is ingebouwd: waar het meeste werk in zit, staat blijkbaar bovenaan. Stap 2 — rangschik dezelfde risico's opnieuw, nu alleen op wat er werkelijk is misgegaan: incidenten, rollbacks, hotfixes, postmortems. Geen inschatting, alleen geregistreerde gevallen. Stap 3 — zet de twee lijsten naast elkaar en benoem elk risico dat van plaats verschilt. Zeg per verschil welke kant het op loopt. Stap 4 — voor elk risico dat in de tweede lijst hoger staat dan in de eerste: is daar een verklaring voor? Als die er niet is, is dat het eerstvolgende ding om aan te werken. Zeg erbij wat je zou bouwen en waarom dat de handeling begrenst in plaats van de invoer.
De promptknop plakt de bronnen en de vindplaats van dit artikel eronder.
Bronnen
- OWASP GenAI/LLM Top 10 2026 — LLM00 PrefaceOWASP GenAI Security Project (Wilson & Lambros) · OWASP Foundation, editie 2026, gelezen 26 augustus 2026 · 2026
- OWASP GenAI/LLM Top 10 2026 — LLM07 MisinformationOWASP GenAI Security Project · OWASP Foundation, editie 2026, gelezen 26 augustus 2026 · 2026
- OWASP GenAI/LLM Top 10 2026 — LLM03 Excessive AgencyOWASP GenAI Security Project · OWASP Foundation, editie 2026, gelezen 26 augustus 2026 · 2026