OWASP LLM Top 10 uitgelegd: risico's, voorbeelden en controles

Een AI-antwoord kan geen kwaadaardige instructies bevatten en toch onbetrouwbaar zijn om op te vertrouwen. OWASP's update over de LLM-risico's voor 2025 behandelt misinformatie als een afzonderlijk aandachtspunt naast beveiligingsfouten. Voor een advocaat die een processtuk voorbereidt, een arts die dossiers beoordeelt of een bestuurder die een actie goedkeurt, toont de bescherming van vertrouwelijke gegevens niet aan dat het antwoord juist is. De OWASP LLM Top 10 is een gedeeld vocabulaire voor het beoordelen van risico's in applicaties die rond grote taalmodellen zijn gebouwd, en beslaat gegevens, retrieval-systemen, afhankelijkheden, rechten en acties, niet alleen chatbotantwoorden. Onze analyse maakt onderscheid tussen wat OWASP vaststelt, wat dat operationeel betekent, en wat de verantwoordelijke professional nog moet beslissen. De nuttige uitkomst is geen afgevinkte checklist. Het is een vastlegging die laat zien waarom een bepaalde applicatie, met bepaalde rechten en beperkingen, geschikt werd geacht voor het beoogde werk.

De OWASP LLM Top 10 is een gedeeld vocabulaire voor het beoordelen van risico's in applicaties die rond grote taalmodellen zijn gebouwd. Het beslaat de omliggende gegevens, retrieval-systemen, software-afhankelijkheden, rechten en acties, niet alleen chatbotantwoorden. Een verdedigbaar gebruik is om het te behandelen als een bewustwordingskader voor dreigingsbeoordeling en bewijsverzameling, in plaats van als certificering dat een applicatie veilig is. Professionele teams moeten elke categorie vertalen naar een governancebeslissing: wie is eigenaar van de blootstelling, welke verificatie is vereist voordat erop wordt vertrouwd, welke wijzigingen hebben goedkeuring nodig, en welke onzekerheid blijft bestaan. Technische maatregelen kunnen blootstelling verminderen, maar ze vervangen geen professioneel oordeel en stellen de waarheid van een antwoord niet vast.

1. Wat maakt LLM01 (2025) Prompt Injection tot een governancebeslissing?

Prompt injection is een kwestie van wiens instructies een applicatie opvolgt. Het OWASP-document over applicatiebeveiliging voor LLM's onderscheidt directe injectie via gebruikersinvoer van 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.

De grens tussen een bedrijfsdocument en een instructie verdient expliciete toetsing.

Eigenaarschap, verificatie en de onopgeloste grens

Onze analyse: 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.

• Toets de grens. Test kwaadaardige instructies in geüploade documenten, opgehaalde passages en toolresponses.
• Beperk de gevolgen. Beperk toolrechten en vereis goedkeuring voor het verzenden, verwijderen of publiceren.
• Bewaar het bewijs. Behoud de invoer, de opgehaalde context, de geprobeerde acties en de beslissing van de beoordelaar.

Onze richtlijn over verdediging tegen prompt injection op architectuurniveau werkt dit onderscheid tussen modelgedrag en applicatiebevoegdheid verder uit.

De resterende beslissing: welke externe content mag de applicatie verwerken, en met welke bevoegdheid? Geslaagde tests leveren bewijs over de geteste omstandigheden, geen bewijs tegen elke toekomstige injectie.

De volgende video biedt aanvullende context voor het beoordelen van dit risico.

2. Wie is eigenaar van LLM02 (2025) Sensitive Information Disclosure?

De gegevenseigenaar moet bepalen wat een applicatie mag vrijgeven voordat een model het materiaal ontvangt. OWASP's officiële bron over applicatierisico's plaatst het vrijgeven van gevoelige informatie binnen een applicatiebrede beoordeling, in plaats van de verantwoordelijkheid te beperken tot de modelaanbieder.

Het praktische aandachtspunt omvat vertrouwelijke informatie die verschijnt in antwoorden, retrieval-resultaten, bewaarde prompts of operationele logs. Een privacybeoordeling moet de informatie daarom door de workflow heen volgen, inclusief plaatsen die gebruikers gewoonlijk niet zien.

Vertrouwelijke dossiers hebben maatregelen nodig vóór verwerking, niet alleen zorgvuldige formulering achteraf.

Test vrijgave zonder echte vertrouwelijke dossiers te gebruiken

Onze analyse: de verantwoordelijke voor informatiebeheer moet afstemmen met de applicatie-eigenaar. Gebruik voor een bedrijfsgezondheidssamenvatting synthetische dossiers met onderscheidende identificatoren, en inspecteer vervolgens uitgaande verzoeken, antwoorden, logs en retrieval-resultaten op onbedoelde vrijgave.

Een voorgestelde workflowwijziging moet aangeven welke velden de gecontroleerde omgeving verlaten, welke worden gemaskeerd, en waar originelen worden hersteld. Onafhankelijke beoordeling moet beoordelen 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.

De resterende beslissing: welke informatie is noodzakelijk voor de taak, en welke restblootstelling is aanvaardbaar? Pseudonimisering kan blootstelling verminderen, maar vervangt geen jurisdictiespecifieke juridische beoordeling en voorkomt geen vrijgave via te brede retrieval-rechten.

3. Wat moet inkoop vereisen voor LLM03 (2025) Supply Chain Vulnerabilities?

Inkoop heeft een inspecteerbaar overzicht nodig van de componenten die de applicatie binnenkomen en van het proces om ze te wijzigen. Het OWASP-overzicht van zijn kader voor 2025 omvat supply-chain-risico over ontwikkeling, implementatie en beheer.

De relevante afhankelijkheden reiken verder dan het basismodel. Embedding-diensten, softwarebibliotheken, connectoren, datasets en hostingafspraken kunnen van invloed zijn op wat de applicatie uitvoert en waar informatie naartoe gaat.

Een componenteninventaris is een beslissingsvastlegging

Onze analyse: 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.

• Inventariseer componenten. Leg modellen, datasets, bibliotheken, connectoren en implementatieversies vast.
• Verifieer integriteit. Controleer handtekeningen of checksums waar beschikbaar en beoordeel formaten die code kunnen uitvoeren tijdens het laden.
• Valideer wijzigingen. Test betrokken workflows opnieuw na componentupdates en bewaar het goedkeuringsdossier.

Een subprocessorbeleid waarin externe subprocessors worden beschreven die gebruikersgegevens verwerken is één type inkoopdocument, geen bewijs over de regelingen van een andere leverancier.

De resterende beslissing: welke afhankelijkheden zijn aanvaardbaar wanneer het zicht op upstream onvolledig is? Een inventaris maakt blootstelling inspecteerbaar; het toont niet aan dat elk vermeld component betrouwbaar is.

4. Hoe zou LLM04 (2025) Data and Model Poisoning het beheer van bronnen moeten veranderen?

Poisoning maakt de integriteit van binnenkomend materiaal een beveiligingsverantwoordelijkheid, niet louter een redactionele voorkeur. OWASP onderscheidt deze categorie van gewone misinformatie omdat gemanipuleerd trainings-, fine-tuning- of retrievalmateriaal later gedrag kan beïnvloeden.

Het vroege community-raamwerk van het project omvatte al poisoning van trainingsdata. De implicatie voor beheer is om te onderzoeken hoe materiaal vertrouwd wordt, niet alleen of een afzonderlijk antwoord redelijk lijkt.

Beoordeel wat de kennisbank binnenkomt

Stel dat een compliance-assistent gebruikmaakt van een interne beleidsbibliotheek. Iemand voegt een onofficiële uitzondering toe die stelt dat een beperkte transactie niet langer goedkeuring vereist, en de assistent presenteert die uitzondering later als vastgesteld beleid.

Onze analyse: de eigenaar van de kennisbank moet gevoelige bronwijzigingen goedkeuren, terwijl een onafhankelijke beoordelaar controleert of het herziene materiaal de beoogde interpretatie ondersteunt. Houd de bronversie, uploader, goedkeuring en betrokken indexitems bij elkaar.

• Vóór ingestie. Beoordeel herkomst, autoriteit en relevantie, vooral voor openbaar of door gebruikers ingediend materiaal.
• Vóór release. Test gerichte vragen en adversariële triggers tegen de bijgewerkte verzameling.
• Na ontdekking. Verwijder verdacht materiaal, bouw waar nodig betrokken indexen opnieuw op en herbeoordeel afhankelijke outputs.

De resterende beslissing: hoeveel brononzekerheid kan de workflow verdragen? Steekproeven en gedragstests kunnen gerichte manipulatie missen. Een model dat zich normaal gedraagt bij routinevragen kan toch falen wanneer een bepaald onderwerp of een bepaalde trigger verschijnt.

5. Waar zou LLM05 (2025) Improper Output Handling moeten worden beheerst?

De beheersing hoort thuis waar gegenereerde inhoud een ander systeem binnenkomt. De categorie improper-output-handling van OWASP 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.

Scheid een voorstel van een uitvoerbare bewerking

Onze analyse: 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.

Gebruik waar passend geparametriseerde query's, allow-lists voor bewerkingen, outputcodering en sandboxed rendering. Bewaar het goedgekeurde plan en het werkelijke uitvoeringsresultaat, zodat beoordelaars verschillen kunnen vaststellen.

De resterende beslissing: welke bewerkingen mogen na validatie automatisch doorgaan? Schemacontroles kunnen structuur en toegestane waarden vaststellen, maar ze stellen niet vast dat de voorgestelde zakelijke wijziging feitelijk gerechtvaardigd of professioneel passend is.

6. Welke bevoegdheid is gerechtvaardigd onder LLM06 (2025) Excessive Agency?

Een toepassing zou alleen de bevoegdheid moeten krijgen die haar taak vereist. Het excessive-agency-item van OWASP identificeert overmatige functionaliteit, overmatige rechten en overmatige autonomie als 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.

Goedkeuring moet de voorgestelde actie tonen, niet louter een geruststellende samenvatting.

Geef de workfloweigenaar verantwoordelijkheid voor bevoegdheid

Onze analyse: 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.

• Verifieer rechten. Probeer verboden acties uit met de werkelijke runtime-identiteit van de toepassing.
• Beoordeel de bewerking. Toon ontvangers, bijlagen en voorgestelde wijzigingen vóór goedkeuring.
• Houd een audittrail bij. Leg toolaanroepen, goedkeuringsbeslissingen en uitvoeringsresultaten vast.

Onze uitleg over least-privilege runtime-beheersing voor AI-agents gaat in op dit onderscheid tussen een gedragsinstructie en een afdwingbare beperking.

De resterende beslissing: hoeveel autonomie wordt gerechtvaardigd door de omkeerbaarheid en impact van de taak? 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.

7. Waarom is geheimhouding niet voldoende voor LLM07 (2025) System Prompt Leakage?

Een verborgen prompt zou niet de last moeten dragen van het afdwingen van toegangscontrole. OWASP behandelt system-prompt-lekkage als een afzonderlijk risico, omdat het blootstellen van interne instructies het gedrag van de applicatie en andere in de prompt geplaatste informatie kan onthullen.

De governance-zorg is niet dat iemand de formulering zou kunnen kopiëren. Het gaat erom of de organisatie de beveiliging afhankelijk heeft gemaakt van het onthuld blijven van instructies of het consistent opvolgen ervan.

Ontwerp controlemaatregelen die onthulling overleven

Stel dat de prompt van een interne assistent goedkeuringsdrempels beschrijft en het model opdraagt geen beperkte records te tonen. Onze analyse: de eigenaar van de applicatiebeveiliging zou moeten verifiëren dat de retrievaldienst die beperkingen onafhankelijk afdwingt.

Houd inloggegevens en geheimen buiten prompts. Plaats autorisatiecontroles in applicatiecode en infrastructuur, en test vervolgens of verzoeken geblokkeerd blijven wanneer de gebruiker de bedoelde workflow en de beleidsformulering kent.

Ga ervan uit dat een vastberaden gebruiker de instructies kan leren kennen. Beoordeel of de applicatie passend beperkt blijft.

Onafhankelijke beoordeling zou zowel prompt-extractietests als de controlemaatregelen buiten het model moeten onderzoeken. Een gevalideerde configuratiewijziging zou moeten vaststellen of nieuwe instructies bedrijfslogica blootleggen of per ongeluk gevoelige waarden introduceren.

De resterende beslissing: welke interne instructies mogen zichtbaar worden? Extractietests kunnen zwakheden aan het licht brengen, maar mislukte pogingen bewijzen geen geheimhouding. Het sterkere bewijs is dat onthulling geen aanvullende toegang of bevoegdheid zou verlenen.

8. Wie verifieert isolatie voor LLM08 (2025) Vector and Embedding Weaknesses?

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. De vector-and-embedding-categorie van OWASP behandelt zwakheden in systemen die embeddings gebruiken om materiaal op te halen voor gegenereerde antwoorden.

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.

Test het retrievalresultaat, niet alleen het antwoord

Denk aan een notariskantoor dat retrieval-augmented generation toepast over cliëntdossiers. Onze analyse: 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.

• Dwing rechten af. Pas gebruikers-, tenant- en documentbeperkingen toe op elke retrievaloperatie.
• Beheer de indexering. Beoordeel documenten en metadata vóór indexering, met gecontroleerde updates.
• Inspecteer toegang. Bewaar voldoende beschermde logs om onverwachte retrieval te onderzoeken, zonder een onnodig duplicaat vertrouwelijk archief te creëren.

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.

De resterende beslissing: rechtvaardigt het vertrouwelijkheidsmodel afzonderlijke indexen of omgevingen? Segmentatie kan gedeelde blootstelling verminderen, maar corrigeert geen onjuiste rechten en toont niet aan dat opgehaalde inhoud juist is.

9. Welk bewijs is voldoende voor LLM09 (2025) Misinformation?

Bewijs zou voldoende moeten zijn voor het beoogde gebruik van de bewering, en niet slechts voldoende om het antwoord aannemelijk te maken. De misinformation-categorie van OWASP erkent valse, misleidende en niet-onderbouwde output als een zelfstandig risico.

Beveiligingstests en feitelijke verificatie beantwoorden verschillende vragen. Een applicatie kan toegangsbeperkingen respecteren en toch een professioneel onbruikbaar antwoord produceren omdat de bronnen de conclusie niet ondersteunen.

Verificatie vereist een traceerbaar verband tussen elke ingrijpende bewering en het bijbehorende bewijs.

Houd onenigheid zichtbaar

Onze analyse: wijs de uiteindelijke professionele beoordelaar het eigenaarschap van het vertrouwen toe. Verifieer voor een juridisch memorandum dat elke aangehaalde bron bestaat, de stelling ondersteunt, van toepassing is in de relevante jurisdictie en geschikt blijft voor de vraag.

Onafhankelijke modelbeoordeling kan tegenstrijdigheden, ontbrekende nuanceringen en niet-onderbouwde beweringen identificeren. Het is geen onafhankelijk bewijs wanneer beoordelaars dezelfde onjuiste premisse herhalen of op dezelfde ongeschikte bron vertrouwen.

Onze richtlijnen over praktische detectie van AI-hallucinaties maken onderscheid tussen het controleren van een antwoord en het accepteren van de vloeiendheid ervan.

De resterende beslissing: moet een onopgeloste bewering worden genuanceerd, geëscaleerd of uitgesloten? Bewaar brondata, bezwaren van beoordelaars en onopgeloste meningsverschillen in het verificatiespoor. Overeenstemming tussen modellen kan de beoordeling ondersteunen, maar stelt geen juistheid vast en draagt de verantwoordelijkheid niet weg van de professional die het resultaat gebruikt.

10. Welke limieten zijn passend voor LLM10 (2025) Unbounded Consumption?

De eigenaar van de dienst zou afdwingbare resourcelimieten moeten instellen vóór implementatie. De unbounded-consumption-categorie van OWASP omvat ongecontroleerd resourcegebruik, kosten en blootstelling van de servicebeschikbaarheid.

Voor governance-doeleinden omvat het vraagstuk zowel legitieme workflows die onverwacht uitbreiden als opzettelijk misbruik. Een documentbeoordeling kan duur worden als de applicatie herhaaldelijk materiaal ophaalt, mislukte operaties opnieuw probeert of een agentlus voortzet.

Inzicht in kosten zou een beslissing moeten ondersteunen over hoeveel verwerking een taak rechtvaardigt.

Begroot de volledige workflow

Onze analyse: technische operaties en de budgeteigenaar zouden samen limieten moeten afspreken. Definieer voor een onderzoekstaak de invoergrootte, uitvoertoelage, retrievalreikwijdte, toegestane tooldiepte en stopcondities voordat u uitgebreide verwerking inschakelt.

• Handhaaf plafonds. Pas server-side limieten toe op snelheid, tokens, stappen en uitgaven.
• Test beëindiging. Controleer of lussen, nieuwe pogingen en mislukte tools voorspelbaar stoppen.
• Behoud zichtbaarheid. Registreer resourcegebruik per workflow en verwerkingsfase.

Onafhankelijke beoordeling moet nagaan of de voorgestelde limieten voldoende capaciteit overlaten voor zinvolle verificatie. Een gevalideerd wijzigingsplan moet aangeven wanneer extra beoordelingsdiepte het resourcegebruik verhoogt.

De resterende beslissing: wat gebeurt er wanneer de limiet is bereikt? Pauzeren voor goedkeuring is mogelijk beter te verantwoorden dan zonder melding een onvolledig antwoord teruggeven. Resourceplafonds verminderen de blootstelling, maar een te strikt plafond kan belangrijke beweringen ongecontroleerd laten, dus de resulterende beperking moet zichtbaar blijven.

Waar elk LLM-risico in de workflow binnenkomt en waar de controles beginnen

• LLM01:2025 Prompt Injection — Waar het risico binnenkomt: Gebruikersinvoer of opgehaalde en geüploade content; Belangrijkste gevolg: Instructies worden overschreven, waardoor mogelijk data wordt blootgesteld of acties worden geactiveerd; Prioritaire controle: Behandel externe content als niet-vertrouwd; beperk tools en vereis goedkeuring voor acties met gevolgen
• LLM02:2025 Sensitive Information Disclosure — Waar het risico binnenkomt: Prompts, uitvoer, logs, trainingsdata of retrievalsystemen; Belangrijkste gevolg: Persoonlijke of vertrouwelijke informatie wordt blootgesteld; Prioritaire controle: Classificeer en pseudonimiseer data; handhaaf toegang op basis van minimale rechten
• LLM03:2025 Supply Chain Vulnerabilities — Waar het risico binnenkomt: Modellen, datasets, plug-ins, bibliotheken en hostingproviders; Belangrijkste gevolg: Gecompromitteerde componenten introduceren kwaadaardig gedrag of kwetsbaarheden; Prioritaire controle: Inventariseer en verifieer componenten; herbeoordeel ze na updates
• LLM04:2025 Data and Model Poisoning — Waar het risico binnenkomt: Trainings-, fine-tuning- of retrievaldata; Belangrijkste gevolg: Het model leert onjuist, bevooroordeeld of met een achterdeur voorzien gedrag; Prioritaire controle: Houd de herkomst van data bij; beoordeel data en test op triggergedrag
• LLM05:2025 Improper Output Handling — Waar het risico binnenkomt: Modeluitvoer doorgegeven aan browsers, databases, interpreters of API's; Belangrijkste gevolg: Uitgevoerde of weergegeven uitvoer veroorzaakt injectie, codeuitvoering of datawijzigingen; Prioritaire controle: Valideer en codeer uitvoer; gebruik geparametriseerde queries en sandboxing
• LLM06:2025 Excessive Agency — Waar het risico binnenkomt: Toolrechten, functies en autonome acties; Belangrijkste gevolg: Gebrekkige of gemanipuleerde uitvoer veroorzaakt schadelijke acties in de echte wereld; Prioritaire controle: Pas minimale rechten toe; vereis menselijke goedkeuring voor acties met gevolgen
• LLM07:2025 System Prompt Leakage — Waar het risico binnenkomt: Verborgen systeeminstructies die via modelantwoorden worden blootgesteld; Belangrijkste gevolg: Interne regels of architectuur worden onthuld, waardoor omzeilingen mogelijk worden; Prioritaire controle: Houd geheimen buiten prompts; handhaaf beveiligingscontroles buiten het model
• LLM08:2025 Vector and Embedding Weaknesses — Waar het risico binnenkomt: Vectoropslag en retrievalqueries; Belangrijkste gevolg: Gebruikers krijgen toegang tot ongeautoriseerde documenten of broninformatie lekt; Prioritaire controle: Handhaaf rechten bij elke retrieval; segmenteer de opslag waar nodig
• LLM09:2025 Misinformation — Waar het risico binnenkomt: Gegenereerde antwoorden, citaten en beweringen; Belangrijkste gevolg: Op onjuiste of niet-onderbouwde content wordt vertrouwd in professioneel werk; Prioritaire controle: Verifieer beweringen aan de hand van bronnen; wijs een professional aan om de uiteindelijke content te beoordelen
• LLM10:2025 Unbounded Consumption — Waar het risico binnenkomt: Verzoeken, agentlussen en herhaalde modelqueries; Belangrijkste gevolg: Buitensporige kosten, serviceonderbreking of modelextractie; Prioritaire controle: Stel limieten in op snelheid, tokens en uitgaven; begrens het aantal agentstappen

Wat moet een besluitvormer vragen voordat LLM-applicaties worden ingezet?

Vraag om bewijs dat de autoriteit, informatietoegang en uitvoer van de applicatie worden beheerst voor het beoogde gebruik. Een beleidsverklaring of een gunstige demonstratie staat niet gelijk aan een geteste workflow met benoemde eigenaren, gedocumenteerde uitzonderingen en een expliciete aanvaarding van de resterende onzekerheid.

Het OWASP GenAI Security Project biedt een gemeenschappelijke taxonomie voor het ordenen van risico's binnen engineering, beveiliging en governance. Onze analyse is dat de grootste praktische waarde ontstaat wanneer teams die terminologie koppelen aan inspecteerbare beslissingen in plaats van categoriedekking te behandelen als een beveiligingsoordeel.

Vereis een registratie van het inzetbesluit

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:

• Benoemd eigenaarschap. Identificeer een verantwoordelijke eigenaar voor elk relevant risico en de persoon die bevoegd is om restrisico te aanvaarden.
• Toegang op basis van minimale rechten. Toon de runtime-rechten, retrievalbeperkingen en de scheiding tussen lees- en schrijfbewerkingen.
• Gedocumenteerde tests. Bewaar gevallen van injectie, openbaarmaking, isolatie en uitvoerverwerking, inclusief mislukkingen en herstel.
• Menselijke goedkeuring. Identificeer onomkeerbare of externe acties die goedkeuring vereisen en toon wat de beoordelaar ziet.
• Verificatiegeschiedenis. Bewaar gecontroleerde beweringen, geraadpleegde bronnen, meningsverschillen tussen beoordelaars, correcties en onopgeloste onzekerheid.
• Operationele limieten. Documenteer resourceplafonds, stopvoorwaarden, rollbackregelingen en escalatieroutes.

Het bewijs moet de ingezette configuratie beschrijven. Resultaten van een smaller prototype tonen niet aan hoe een applicatie zich gedraagt nadat nieuwe documenten, rechten of tools zijn toegevoegd.

Meer artikelen over dit onderwerp zijn verzameld in het overzicht AI-security.

Bronnen: Belangrijke feitelijke claims zijn toegeschreven aan het OWASP Gen AI Security Project, waaronder de 2025-updatespagina, de resource OWASP Top 10 for LLM Applications 2025 en het OWASP LLM application security document.