De voorbeelden stapelen zich op. De afgelopen weken was het telkens raak: een AI-model dat tijdens veiligheidstests uit zijn testomgeving brak en andere bedrijven hackte. Eerst OpenAI, toen Anthropic (dat er drie bleek te hebben geraakt, waaronder een securitybedrijf), en daarna Meta. Steeds hetzelfde patroon: een misconfiguratie in de testomgeving, internettoegang die er niet had mogen zijn, en een model dat vervolgens zwakke wachtwoorden en open poorten misbruikte.
Elk verhaal apart is leerzaam. En deels ook PR, want de labs laten graag zien hoe krachtig hun modellen zijn. Maar samen vormen ze geen aanpak. Wat ontbreekt, is een gedeeld raamwerk: een taal om die risico’s te ordenen en met de business te bespreken.
Dat raamwerk is er nu. Het OWASP GenAI Security Project publiceerde op 9 december 2025 de OWASP Top 10 voor Agentic Applications 2026, gemaakt met meer dan honderd experts en door open peer review gehaald. Het is het eerste breed gedragen dreigingsmodel dat echt over autonome agents gaat: agents die plannen, tools aanroepen, geheugen bijhouden en met elkaar samenwerken.
En dat is bruikbaarder dan weer een incident.
Wat de OWASP Top 10 voor Agentic Applications is
Kort gezegd is het een taxonomie van de tien belangrijkste beveiligingsrisico’s van systemen waarin AI-agents zelfstandig handelen met gedelegeerde bevoegdheid. Geen verzameling losse aanvallen, maar tien herkenbare faalmodi, elk met een eigen code (ASI01 tot en met ASI10). Bruikbaar als checklist, als gemeenschappelijke taal, en als iets wat je aan een bestuur kunt uitleggen zonder in jargon te verzanden.
De tien, in het kort:
- ASI01 — Agent Goal Hijack: het doel van de agent wordt gekaapt.
- ASI02 — Tool Misuse & Exploitation: misbruik van de tools die de agent mag aanroepen.
- ASI03 — Agent Identity & Privilege Abuse: misbruik van de identiteit en rechten van de agent.
- ASI04 — Agentic Supply Chain Compromise: compromittering via de toeleveringsketen van de agent.
- ASI05 — Unexpected Code Execution: onbedoelde code-uitvoering.
- ASI06 — Memory & Context Poisoning: vergiftiging van geheugen en context.
- ASI07 — Insecure Inter-Agent Communication: onveilige communicatie tussen agents.
- ASI08 — Cascading Agent Failures: fouten die zich door een keten van agents voortplanten.
- ASI09 — Human-Agent Trust Exploitation: misbruik van het vertrouwen tussen mens en agent.
- ASI10 — Rogue Agents: agents die buiten hun mandaat opereren.
Je hoeft geen securityspecialist te zijn om te zien dat dit geen exotische lijst is. Het zijn gewoon de dingen die in de praktijk misgaan, op een rij.
De rode draad: te veel rechten, en data die de agent nooit had mogen zien
Lees je door de tien heen, dan vallen twee oorzaken op die telkens terugkomen. De meeste agent-incidenten zijn te herleiden tot een agent met te veel rechten, of een agent die handelt op data die hij nooit had mogen zien. Bijna alles op de lijst is een variant of een gevolg van die twee.
Geen nieuw probleem in een nieuw jasje dus. Het is het oude probleem van least privilege en dataminimalisatie, nu op een actor die zelfstandig handelt en veel sneller. Een agent met te ruime rechten is een privileged account dat beslissingen neemt. Een agent die data ziet die niet voor hem bestemd was, is een autorisatiefout die zich in realtime afspeelt.
En daarmee ben je terug bij het fundament. Je kunt een agent pas veilig begrenzen als je weet wat zijn rechten precies inhouden. En die semantiek is in de meeste organisaties nog mistig. Ik betoogde eerder dat je geen intelligent toegangsbeheer voor AI-agents bouwt op een fundament dat je niet kunt uitleggen. De OWASP-lijst bewijst het: de helft van de risico’s verschrompelt zodra rechten en datatoegang op orde zijn.
Waarom dit een governance-baseline is, geen technische checklist
De verleiding is om deze lijst als een technisch afvinkdocument te zien, iets voor het securityteam. Dat verkoopt hem tekort. De echte waarde: het is een baseline die je aan governance kunt ophangen.
Met tien benoemde faalmodi voer je per agent een gesprek dat verder gaat dan “is het veilig?”. Welke van de tien is relevant voor déze agent? Wie is verantwoordelijk? Welke maatregel hoort erbij? Business, security en de eigenaar van de agent krijgen dezelfde taal. En de vraag die ik eerder stelde wordt beantwoordbaar: wie is eigenaar van deze agent, en waarvoor staat die eigenaar in.
Een baseline hoeft niet perfect te zijn om waardevol te zijn. Wel gedeeld, gezaghebbend en toepasbaar. Deze is alle drie. En gratis.
De IAM-lens: ASI03 is geen toeval
Dat identiteit en rechten expliciet als apart risico op de lijst staan (ASI03), is veelzeggend. Het bevestigt wat ik al langer zeg: AI governance loopt stuk zonder IAM. Een agent is een identiteit met rechten. Zonder grip op die identiteit is elke andere maatregel een pleister.
Praktisch betekent dat: een flink deel van je agent-security is geen nieuw vakgebied, maar bestaand IAM-werk op een nieuwe soort actor. Eigenaarschap toewijzen. Rechten minimaliseren. Datatoegang scopen. Lifecycle beheren. Wie dat voor mensen en service accounts al doet, heeft een voorsprong. Wie het nog niet op orde heeft, krijgt met agents een snellere, schaalbaardere versie van hetzelfde gat. En dat is precies waar ongecontroleerd AI gebruik een governanceprobleem wordt.
Wat je nu zou moeten doen
Adopteer de lijst als baseline, niet als leesvoer. Neem de tien faalmodi en loop je bestaande en geplande agents erlangs: welke risico’s zijn relevant, wie is eigenaar, welke maatregel hangt eraan. Begin bij de twee die de meeste andere afdekken: rechten en datatoegang. Minimaliseer wat een agent mag. Beperk wat hij ziet.
En gebruik de lijst als brug naar het bestuur. Tien benoemde risico’s met een eigenaar per stuk is een verhaal dat een directie snapt. Het maakt van “we moeten iets met AI-agents” een concreet, toetsbaar programma. Dat is meer waard dan nog een incident dat je naar boven stuurt.
Tot slot
De OWASP Top 10 voor Agentic Applications is geen spannend nieuws, en dat is juist de kracht. Het zet losse incidenten om in een geordend, gedeeld dreigingsmodel dat je kunt adopteren, uitleggen en toetsen. De rode draad, te veel rechten en te veel data, laat zien dat agent-security voor een groot deel gewoon volwassen IAM en governance is. Op een nieuwe actor.
Wie zijn agents langs deze tien legt en bij het fundament begint, heeft een baseline. Wie wacht op het volgende incident, heeft straks een anekdote.
Veelgestelde vragen
Wat is de OWASP Top 10 voor Agentic Applications?
Het is een taxonomie van de tien belangrijkste beveiligingsrisico’s voor systemen waarin AI-agents zelfstandig plannen, tools aanroepen, geheugen bijhouden en met elkaar samenwerken. De editie 2026 werd op 9 december 2025 gepubliceerd door het OWASP GenAI Security Project, ontwikkeld met meer dan honderd experts en door peer review gehaald. De risico’s lopen van ASI01 (Agent Goal Hijack) tot ASI10 (Rogue Agents).
Waarom is dit belangrijker dan losse incidentverhalen?
Omdat een incident informeert en een raamwerk je laat handelen. De OWASP-lijst zet losse aanvallen om in tien herkenbare faalmodi met een eigen code, zodat je ze kunt gebruiken als checklist, als gemeenschappelijke taal met de business en als baseline die je aan een bestuur kunt uitleggen.
Wat is de rode draad in de tien risico’s?
Twee oorzaken komen telkens terug: agents met te veel rechten, en agents die handelen op data die ze nooit hadden mogen zien. Veel van de tien risico’s zijn varianten of gevolgen daarvan. Het is in de kern het oude least-privilege- en dataminimalisatieprobleem, toegepast op een actor die zelfstandig en snel handelt.
Is agent-security een nieuw vakgebied?
Deels. Een groot deel is bestaand IAM- en governance-werk toegepast op een nieuwe soort actor: eigenaarschap toewijzen, rechten minimaliseren, datatoegang scopen, lifecycle beheren. Dat identiteit en rechten als apart risico op de lijst staan (ASI03), bevestigt dat AI governance zonder IAM strandt.
Hoe gebruik ik de OWASP Top 10 in de praktijk?
Adopteer hem als baseline. Loop je bestaande en geplande AI-agents langs de tien faalmodi: welke zijn relevant, wie is eigenaar, welke maatregel hoort erbij. Begin bij rechten en datatoegang, want die dekken de meeste andere risico’s af. En gebruik de lijst als gedeelde taal richting het bestuur.
