OWASP Top 10 for Agentic Applications

Wat is de OWASP Top 10 for Agentic Applications?

De OWASP Top 10 for Agentic Applications is een lijst van de tien beveiligingsrisico's die opduiken bij AI-systemen die zelf plannen, onthouden, tools aanroepen en handelen met eigen rechten. Het OWASP GenAI Security Project publiceerde ze op 9 december 2025, als editie 2026. De items dragen de nummers ASI01 tot ASI10, en zo verwijzen leveranciersdocumentatie en securityrapporten er intussen naar.

OWASP staat voor Open Worldwide Application Security Project, een non-profitorganisatie die in 2001 van start ging en sinds begin deze eeuw een Top 10 voor webapplicatiebeveiliging publiceert. Zo'n Top 10 is geen norm en je kan er niets tegen laten certificeren. Het is de securitygemeenschap die opschrijft wat er in de praktijk misgaat, in een volgorde waar het vakgebied grotendeels achter staat, zodat een team ergens kan beginnen in plaats van bij een leeg blad.

Deze lijst ging door een reviewronde met nationale cybersecurityagentschappen, standaardisatie-instellingen, leveranciers en onderzoekers. In het expertenpanel zaten onder meer Apostol Vassilev van NIST en mensen van het AI red team van Microsoft. Ze bouwt verder op een taxonomie van agentic dreigingen en maatregelen die hetzelfde project in februari 2025 publiceerde. De Top 10 is de korte, leesbare voordeur naar dat materiaal.

De tien risico's

Elk item krijgt in het gepubliceerde document een hoofdstuk met aanvalsscenario's en maatregelen. Dit is waar ze elk over gaan.

1. ASI01 Agent Goal Hijack
   Iemand verandert wat de agent probeert te bereiken, via tekst die de agent leest en niet via code die hij uitvoert. Dit is prompt injection die terechtkomt op iets dat handelt: de agent denkt nog altijd dat hij jouw opdracht uitvoert, en elke stap daarna zit fout met opzet.

2. ASI02 Tool Misuse and Exploitation
   De agent zet zijn eigen tools tegen je in: onschuldige tools die aan elkaar geregen worden tot een schadelijke reeks, output die zonder controle belandt in een commando dat kan verwijderen of versturen, of een tool waarvan de beschrijving geschreven is om het model te misleiden. Tool poisoning is daar het best gedocumenteerde voorbeeld van.

3. ASI03 Identity and Privilege Abuse
   De agent werkt onder een gedeelde login, een geleend token van een medewerker of een rechtenset die niemand ooit heeft bijgeknipt. Wie de agent te pakken krijgt, krijgt alles waar hij bij kan. Langlopende credentials maken van één agent een doelwit dat de moeite loont.

4. ASI04 Agentic Supply Chain Vulnerabilities
   Een agent wordt tijdens het draaien samengesteld uit een framework, een model, plugins, toolbeschrijvingen en MCP-servers. Het meeste daarvan heb je niet zelf geschreven. Een gemanipuleerde afhankelijkheid laadt zichzelf in de agent zonder dat er een buildstap tussenkomt die dat opmerkt.

5. ASI05 Unexpected Code Execution
   Agents schrijven code en voeren ze uit, en ze geven tekst door aan shells, bestandspaden en interpreters. Tekst die van buiten binnenkwam draait dan ergens waar dat nooit de bedoeling was, en de sandbox is het enige dat tussen die code en de rest van de machine staat.

6. ASI06 Memory and Context Poisoning
   Wat de agent vandaag opslaat, stuurt wat hij volgende maand beslist. Een verzonnen feit dat in de gespreksgeschiedenis of een documentindex belandt, blijft werken lang nadat de sessie die het plantte voorbij is. Net dat maakt het zo moeilijk om terug te traceren.

7. ASI07 Insecure Inter-Agent Communication
   Als agents werk aan elkaar doorgeven, hebben die berichten authenticatie en controle op integriteit nodig, net als elk ander netwerkverkeer. Zonder dat kan een aanvaller zich voordoen als een agent, een bericht onderweg aanpassen, of een valse tegenpartij registreren die de anderen gewoon aanvaarden.

8. ASI08 Cascading Failures
   Eén fout antwoord reist verder. Een agent verderop in de keten vertrouwt het resultaat van de vorige, handelt ernaar en geeft zijn eigen resultaat door. Zo groeit één hallucinatie of één vergiftigde record uit tot een reeks zelfverzekerde acties voor iemand het doorheeft.

9. ASI09 Human-Agent Trust Exploitation
   Dit item mikt op de mens, niet op het systeem. Een vlotte samenvatting verbergt wat de agent echt gedaan heeft, of de agent vraagt om een wachtwoord, een goedkeuring of een rechtenwijziging in taal die klinkt als gewone ondersteuning. Mensen keuren goed wat goed leest.

10. ASI10 Rogue Agents
    Een agent die blijft draaien buiten waarvoor hij bedoeld was, door een compromittering, door afgedreven gedrag, of omdat niemand die van een vertrokken collega heeft uitgezet. Elke actie op zich lijkt legitiem; het patroon over enkele weken niet.

Het verschil met de OWASP Top 10 for LLM Applications

Hetzelfde project publiceert beide lijsten en legt er bewust een verband tussen. De dimensie die telt: wat wordt er precies aangevallen.

De LLM Top 10 gaat uit van één modelaanroep: er gaat tekst in, er komt tekst uit, en jouw applicatie doet iets met die output. De items gaan dus over die aanroep en wat eraan raakt, van prompt injection (LLM01) over slechte verwerking van output (LLM05) tot het lekken van de system prompt (LLM07), in de nummering van 2025; OWASP heeft de LLM-lijst in augustus 2026 hernummerd. Het meeste daarvan bekijk je door de prompt te lezen, de ophaalstap en de code die het antwoord verwerkt.

De agentic lijst gaat uit van iets dat toestand bijhoudt en acties onderneemt tussen die aanroepen door. Wat daar onder vuur ligt is de loop die de volgende stap kiest, het geheugen dat de sessie overleeft, de tools en credentials die de agent in handen heeft, en de andere agents die zijn output vertrouwen. Niets daarvan zie je in één request.

De twee overlappen waar je het verwacht. Prompt injection is de techniek; agent goal hijack is wat die techniek aanricht zodra de lezer ook kan handelen. Excessive agency (LLM06 in de editie van 2025, LLM03 sinds augustus 2026) is één item in de oudere lijst; in de nieuwe is dat terrein verdeeld over meerdere items, van identity and privilege abuse voor waar de agent aan mag komen tot rogue agents voor wat hij daar na verloop van tijd mee doet.

Wat dat praktisch betekent: draai je een chatbot die alleen tekst schrijft, dan is de LLM Top 10 jouw lijst. Zodra datzelfde model een tool krijgt die ergens naartoe schrijft, begint de agentic lijst vragen te stellen waar de LLM-lijst geen plaats voor heeft, zoals onder wiens identiteit de agent handelt en wie er in zijn geheugen kan schrijven.

Hoe je de lijst gebruikt als KMO

Je hoeft die tien niet allemaal uit te werken. Er zijn twee manieren om er op één namiddag iets uit te halen.

Als checklist bij aankoop of bouw. Loop de tien items af tegen die ene agent die voor je ligt en zet er relevant of niet relevant naast. Een agent die alleen offertes opstelt heeft geen communicatie met andere agents en voert waarschijnlijk geen code uit, dus ASI05 en ASI07 vallen weg. Schrijf op dat je ze hebt weggestreept en waarom. Die notitie herlees je als de tweede agent erbij komt en met de eerste begint te praten.

Als vragenlijst voor je leverancier. De items laten zich omzetten in vragen die een leverancier kan beantwoorden zonder securityteam aan tafel.

• Onder wiens identiteit handelt de agent, en kunnen we die uitzetten los van de medewerker die hem heeft opgezet? (ASI03)

• Welke acties gebeuren zonder dat een mens klikt, en welke kunnen dat niet? (ASI02, ASI09)

• Wat komt er in het geheugen terecht, wie kan daar tekst in krijgen, en hoe maken we dat leeg? (ASI06)

• Welke componenten van derden laden tijdens het draaien, en staan de versies vast? (ASI04)

• Als een ander systeem handelt op zijn output, wat gebeurt er dan als die output fout is? (ASI08)

• Hoe zetten we hem stil, wie mag daarop duwen, en hoe lang duurt het voor hij echt stilligt? (ASI10)

Een leverancier die daar gewoon op antwoordt, heeft erover nagedacht. Een leverancier die met een certificaatlogo antwoordt, heeft niet geantwoord. Voor een snelle eerste doorlichting van het datalek-gedeelte volstaat de lethal trifecta met drie vragen in plaats van tien; de OWASP-lijst haal je erbij zodra het antwoord op die drie ongemakkelijk was.

Wat de lijst niet doet

Het is een risicotaxonomie, geen compliancekader. Er is geen audit, geen artikel om naar te wijzen, en OWASP-conform bestaat niet. De lijst geeft je gedeelde woorden voor een gesprek en een reeks maatregelen om te overwegen. Wat je ermee doet, beslis je zelf en blijft jouw verantwoordelijkheid.

De AI Act is een aparte verplichting. Artikel 15 van de AI Act eist dat hoogrisicosystemen bestand zijn tegen pogingen van onbevoegde derden om hun gebruik, hun output of hun prestaties te wijzigen, en noemt data poisoning, model poisoning en vijandige invoer als zaken waar de technische maatregelen op moeten inspelen. Artikel 14 vraagt menselijk toezicht, met een stopknop erbij. De OWASP-lijst doorlopen helpt je bouwen wat die artikels vragen, en levert je iets concreets voor in een technisch dossier, maar ze zegt niet of jouw systeem hoogrisico is en heeft zelf geen juridisch gewicht.

De lijst rangschikt beveiligingsrisico's, niet de gewone manieren waarop een agent tegenvalt. Foute antwoorden en geld dat opgaat aan een loop die nooit klaar raakt, dat zit in de LLM-lijst onder misinformatie en onbegrensd verbruik, of in je eigen kwaliteitsproces. Een agent kan proper scoren op alle tien de items en nog altijd een slecht idee zijn.

Het is een momentopname met een datum erop. De editie 2026 is de eerste, en de aanvallen die erin staan zijn in de loop van 2025 gedemonstreerd, een groot deel ervan tegen coding agents en MCP-opstellingen. Er komt een volgende editie en de volgorde zal schuiven. Wat de moeite is om over te nemen, is de gewoonte om een lijst af te lopen voor een agent aan productie raakt, niet die tien items precies zoals ze er nu staan.