LLM-beveiliging in 2026: dreigingen, verdediging en verificatie

Enterprise LLM-beveiliging is niet langer voornamelijk een kwestie van modelgedrag. Het grotere probleem ontstaat uit het systeem rondom het model: wat het kan lezen, ophalen, welke rechten het krijgt, en welke acties het kan uitvoeren. OWASP rangschikt Prompt Injection als LLM01:2025 en onderscheidt directe en indirecte aanvallen via externe content zoals websites en bestanden. OWASP stelt dat waterdichte preventie onduidelijk blijft en beveelt gelaagde mitigatie aan. [1] Het 2026 Global Threat Report van CrowdStrike stelt dat aanvallers legitieme generatieve-AI-tools misbruikten bij meer dan 90 organisaties in 2025 . [7] Google rapporteerde, op basis van Common Crawl-snapshots, een relatieve toename van 32% in materiaal geclassificeerd als kwaadaardige prompt injection tussen november 2025 en februari 2026 , hoewel veel activiteit weinig geavanceerd was. Dat cijfer is een verandering in gedetecteerd materiaal, geen toename van 32% in geslaagde AI-compromitteringen . [6]

Voor juridische, zorg-, compliance-, financiële en andere omgevingen met een hoog vertrouwensniveau moet een LLM-beveiligingsbeoordeling daarom verder reiken dan weigergedrag en waarborgen op modelniveau. Zij moet prompt injection, ophaalrechten, blootstelling van gevoelige data, logging, externe content, tooluitvoering en de controls omvatten die bepalen of door het model gegenereerde output een echte actie in de praktijk kan worden.

Direct antwoord: In 2026 betekent LLM-beveiliging dat u extern gecontroleerde content als onbetrouwbaar behandelt, rechten buiten het model afdwingt, toolgebruik beperkt en ingrijpende output en acties onafhankelijk verifieert. Het kernrisico is niet alleen wat het model zegt, maar wat het omringende systeem het laat lezen, ophalen en doen.

Het risico blijft niet beperkt tot laboratoriumdemonstraties. Het 2026 Global Threat Report van CrowdStrike stelt dat aanvallers legitieme generatieve-AI-tools misbruikten bij meer dan 90 organisaties in 2025, waarbij zij kwaadaardige prompts injecteerden om commando's te genereren die werden gebruikt voor diefstal van inloggegevens en cryptovaluta. [7]

Dat onderscheid is belangrijk. Detectiefrequentie, aanvalssuccespercentage, prevalentie van kwetsbaarheden en bevestigde beveiligingsincidenten zijn verschillende metingen en mogen niet worden gepresenteerd alsof zij uitwisselbaar zijn.

Waarom LLM-beveiliging een operationele discipline werd

De traditionele benadering van LLM-beveiliging concentreerde zich sterk op wat een model zou kunnen genereren. Dat wordt onvolledig zodra een assistent documenten kan ophalen, e-mail kan inspecteren, databases kan bevragen, externe content kan doorbladeren of tools kan aanroepen.

Op dat punt hangt beveiliging af van de volledige applicatiearchitectuur.

Een juridische assistent kan bijvoorbeeld een instructie van een gebruiker combineren met een document dat door een andere partij is aangeleverd. Een bedrijfsassistent kan een verzoek van een medewerker combineren met zoekresultaten, e-mails, interne documenten en API-antwoorden. Een agent kan vervolgens zijn interpretatie van die invoer gebruiken om een toolaanroep te kiezen.

De fundamentele vraag wordt:

Welke informatie mag het model beïnvloeden, en welke informatie mag een actie beïnvloeden?

Onderzoek naar indirecte prompt injection levert direct bewijs voor dit probleem. Het BIPIA-onderzoek van Yi et al. constateerde dat de geteste LLM's binnen de geëvalueerde benchmark kwetsbaar waren voor kwaadaardige instructies die in externe content waren ingebed. De onderzoekers identificeerden twee belangrijke oorzaken: de moeite om informatieve context van uitvoerbare instructies te onderscheiden, en het niet herkennen dat instructies in externe content niet noodzakelijkerwijs moeten worden uitgevoerd. [3]

Dit ondersteunt een praktisch beveiligingsprincipe:

Als een AI-systeem extern gecontroleerde content kan lezen, mag die content niet automatisch gezag over de workflow krijgen.

Directe en indirecte prompt injection

OWASP onderscheidt twee belangrijke vormen van prompt injection. [1]

Directe prompt injection treedt op wanneer een invoer die direct aan het model wordt aangeleverd het gedrag op een onbedoelde manier verandert.

Indirecte prompt injection treedt op wanneer instructies zijn ingebed in extern materiaal dat door de LLM wordt verwerkt, zoals een webpagina of bestand.

Dit onderscheid is belangrijk omdat enterprise-AI-systemen een groot deel van hun nut ontlenen aan externe informatie.

Een juridisch AI-systeem is waardevol omdat het contracten, bewijsmateriaal, correspondentie en dossiermateriaal kan verwerken. Een compliance-assistent kan beleid en dossiers inspecteren. Een browseragent is afhankelijk van webcontent. Een retrieval-augmented systeem is afhankelijk van informatie die uit een andere gegevensopslag wordt opgehaald.

Het elimineren van externe informatie zou daarom een groot deel van de waarde van de applicatie elimineren.

De beveiligingsuitdaging is in plaats daarvan om onbetrouwbare informatie te gebruiken zonder toe te staan dat die informatie onbedoelde controle over het systeem verkrijgt.

Experimenteel bewijs: prompt injection is sterk contextafhankelijk

Een reden waarom beveiligingsclaims rond prompt injection zorgvuldige nuancering vereisen, is dat de prestaties van aanval en verdediging aanzienlijk variëren tussen configuraties.

Liu et al. evalueerden, in onderzoek gepresenteerd op het 33rd USENIX Security Symposium, systematisch:

• 5 prompt-injection-aanvallen
• 10 verdedigingsmechanismen
• 10 LLM's
• 7 taken

Het onderzoek was specifiek opgezet om een gemeenschappelijke benchmark te bieden voor het evalueren van prompt-injection-aanvallen en -verdedigingen. [2]

Dit betekent dat uitspraken zoals "prompt injection heeft een succespercentage van 80%" niet verdedigbaar zijn zonder de specifieke aanval, het model, de taak, de verdedigingsconfiguratie en de evaluatiemethodologie te benoemen.

Een percentage dat onder één experimentele configuratie is gemeten, kan niet automatisch worden veralgemeend naar enterprise-LLM-systemen als geheel.

BIPIA kwam vanuit het perspectief van indirecte aanvallen tot een verwante conclusie. Yi et al. evalueerden prompt injection die via externe informatie werd binnengebracht en constateerden dat de geëvalueerde modellen in de benchmark kwetsbaar waren. Hun analyse identificeerde het onderscheid tussen informatieve context en uitvoerbare instructies als een centrale factor bij geslaagde aanvallen. Het werk werd geaccepteerd op KDD 2025. [3]

De onderzoekers stelden boundary awareness en explicit reminder als verdedigingsmechanismen voor. Hun experimenten toonden aanzienlijke mitigatie, waaronder vrijwel nul-succespercentages voor aanvallen bij de geëvalueerde white-box-verdediging. Die resultaten behoren tot de specifieke benchmark- en verdedigingsconfiguraties en mogen niet worden geïnterpreteerd als bewijs dat indirecte prompt injection universeel is opgelost. [3]

Waarom architectonische controls belangrijk zijn

Prompt engineering is nuttig, maar het is niet gelijk aan een beveiligingsgrens.

De mitigatierichtlijnen van OWASP bevelen expliciet aan om toegangscontrole en het principe van minimale rechten af te dwingen, menselijke goedkeuring te vereisen voor risicovolle acties, externe content te scheiden en adversarieel testen uit te voeren. [1]

Dit onderscheid wordt vooral belangrijk wanneer een AI-systeem tools kan aanroepen.

Denk aan een agent die het volgende kan aanvragen:

send_document(destination, document)

Een instructie op modelniveau kan de agent vertellen om geen vertrouwelijke informatie naar onbevoegde ontvangers te sturen.

Een sterkere beveiligingsmaatregel is dat de applicatie zelf bepaalt of de aangevraagde bestemming geautoriseerd is voordat de bewerking wordt uitgevoerd.

Het verschil is aanzienlijk:

Controle op promptniveau vraagt het model om zich correct te gedragen.

Controle op autorisatieniveau beperkt wat het systeem kan doen.

Dat laatste blijft afdwingbaar, zelfs als het model gemanipuleerd is.

CaMeL: het scheiden van control flow van niet-vertrouwde data

Een bijzonder relevante architecturale onderzoeksrichting is CaMeL - Defeating Prompt Injections by Design.

CaMeL creëert een beschermende systeemlaag rond de LLM. De architectuur haalt control- en dataflows expliciet uit de vertrouwde query, zodat niet-vertrouwde data die door de LLM worden opgehaald niet de programmaflow kunnen bepalen. Ook past het capability-based controles toe die bedoeld zijn om exfiltratie van privédata via ongeautoriseerde dataflows te voorkomen wanneer tools worden aangeroepen. [5]

De versie van het paper die op 24 maart 2025 werd ingediend, is herzien op 24 juni 2025. De herziene v2 meldt dat CaMeL in de AgentDojo-evaluatie van de onderzoekers 77% van de taken oploste met aantoonbare beveiliging, vergeleken met 84% voor een onbeschermd systeem. [5]

Dit resultaat kwantificeert zowel het beveiligingsvoordeel dat de architectuur claimt als de bruikbaarheidskosten die door de beperkingen worden geïntroduceerd.

Het moet echter worden geïnterpreteerd binnen de benchmark, aannames, beveiligingseigenschap en architectuur die de onderzoekers hebben geëvalueerd. Het toont niet aan dat CaMeL prompt injection universeel oplost.

De belangrijkere bijdrage is architecturaal: beveiliging hoeft niet uitsluitend af te hangen van de vraag of een LLM een instructie correct interpreteert. Sommige beveiligingsbeslissingen kunnen in plaats daarvan worden verplaatst naar afdwingbare mechanismen rond het model.

Prompt injection verschijnt op het openbare web

Google publiceerde in april 2026 eigen bewijs op basis van een analyse van Common Crawl.

De onderzoekers van Google voerden een brede scan uit van gearchiveerde openbare webcontent om patronen van indirecte prompt injection te identificeren. Het onderzoek gebruikte patroonherkenning, LLM-gebaseerde classificatie en handmatige validatie om potentieel kwaadaardige instructies te onderscheiden van legitiem materiaal dat prompt injection bespreekt. [6]

Deze validatiestap is van belang omdat vals-positieven een aanzienlijk meetprobleem vormen. Een webpagina die beveiligingsonderzoek bespreekt, kan voorbeelden van kwaadaardige prompts bevatten zonder zelf een aanval te vormen.

Google observeerde materiaal variërend van experimenten en op AI gerichte manipulatie tot een kleinere categorie kwaadaardige voorbeelden.

Tussen de archiefversies van november 2025 en februari 2026 mat Google een relatieve toename van 32% in de kwaadaardige categorie. [6]

Google waarschuwde tegelijkertijd tegen overinterpretatie van het resultaat. De onderzoekers karakteriseerden veel van de waargenomen activiteit als beperkt geavanceerd en merkten op dat de Common Crawl-dataset geen grote socialemediaplatforms omvat. [6]

Dit voorkomt twee tegenovergestelde fouten:

Onderschatting: claimen dat prompt injection alleen bestaat in academische demonstraties.

Overdrijving: claimen dat elke gedetecteerde kwaadaardige prompt een geslaagde compromittering vormt.

Het beschikbare bewijs ondersteunt geen van beide uitersten.

Multimodale invoer vergroot het aanvalsoppervlak

Prompt injection is niet beperkt tot gewone zichtbare tekst.

De richtlijnen van OWASP LLM01:2025 merken expliciet op dat kwaadaardige invoer niet zichtbaar of leesbaar voor mensen hoeft te zijn, zolang het model die kan verwerken. De voorbeelden omvatten ook multimodale prompt injection met instructies die in afbeeldingen zijn ingebed. [1]

Systemen die gescande documenten, screenshots, presentatiebestanden, afbeeldingen of ander multimodaal materiaal accepteren, moeten die kanalen daarom opnemen in hun dreigingsmodel.

Dat een menselijke beoordelaar een instructie over het hoofd ziet, betekent niet dat een multimodaal model die niet kan verwerken.

Datalekken via natuurlijketaal-database-interfaces

Prompt injection wordt ingrijpender wanneer een LLM toegang heeft tot gevoelige databases.

De SecureSQL-studie, gepubliceerd in Findings of the Association for Computational Linguistics: EMNLP 2024, levert primair empirisch bewijs.

De onderzoekers creëerden een benchmark met:

• 932 samples
• verspreid over 34 domeinen
• geëvalueerd met 15 modellen
• uit zes LLM-families

De domeinen omvatten medische, juridische, financiële en politieke data. [4]

SecureSQL rapporteerde dat het best presterende geteste model een nauwkeurigheid van 61,7% behaalde, vergeleken met 94% voor mensen in de benchmark. De onderzoekers evalueerden daarnaast prompt-injection- en inferentie-aanvallen en rapporteerden dat beide de modelprestaties aanzienlijk beïnvloedden. Hun geteste chain-of-thought-promptingverdediging verbeterde de nauwkeurigheid niet significant. [4]

Deze resultaten gelden specifiek voor de SecureSQL-benchmark. Ze mogen niet worden geïnterpreteerd als bewijs dat elke natuurlijketaal-database-interface data lekt.

Ze tonen wel aan waarom een LLM niet zelf moet worden behandeld als het autorisatiemechanisme van de database.

Als een gebruiker geen toestemming heeft om een record te lezen, moet de database- of applicatiearchitectuur die beperking afdwingen, onafhankelijk van welke SQL het model voorstelt.

Retrieval-systemen hebben hetzelfde onderliggende beveiligingsprobleem

Hetzelfde principe geldt voor retrieval-augmented generation.

Als de permissies van een gebruiker in het bronsysteem geen toegang tot een document toestaan, mag de retrieval-laag dat document niet beschikbaar maken voor het model, alleen omdat het model een semantisch verwante vraag heeft gekregen.

Dit is in de kern niet de vraag of het model bereid is een privacy-instructie op te volgen. Het is een toegangscontroleprobleem.

Hieruit volgt een algemene architecturale regel:

Het model kan deelnemen aan een beveiligingsgevoelige workflow, maar het mag niet het enige handhavingspunt voor het beveiligingsbeleid worden.

Verdedigingslagen en wat ze feitelijk bereiken

Geen enkele verdediging in het hier beoordeelde bewijs biedt universele bescherming tegen prompt injection.

OWASP stelt expliciet dat waterdichte preventie onduidelijk blijft en beveelt daarom meerdere mitigaties aan. [1]

Scheiding van instructies en externe content

Externe informatie moet duidelijk worden onderscheiden van vertrouwde instructies.

Dit wordt rechtstreeks ondersteund door BIPIA, dat het onvermogen om informatieve context te onderscheiden van uitvoerbare instructies aanwijst als een factor die bijdraagt aan het succes van indirecte prompt injection. [3]

De belangrijke kanttekening is dat het markeren van data als niet-vertrouwd niet noodzakelijk hetzelfde is als technisch voorkomen dat die data de uitvoering beïnvloedt.

Verharding van de system prompt

System prompts kunnen verwacht gedrag, taakgrenzen en regels vaststellen.

Ze zijn nuttig, maar mogen niet worden behandeld als een mechanisme voor toegangscontrole.

De USENIX-benchmark toont aan dat de effectiviteit van een verdediging afhangt van de aanval, de taak, het model en de configuratie. [2]

Validatie van invoer en uitvoer

OWASP beveelt filtering van invoer en uitvoer aan als onderdeel van een bredere mitigatiestrategie. [1]

Deze controles kunnen risico's verminderen, maar mogen niet worden gepresenteerd als een garantie dat elke semantisch kwaadaardige instructie wordt gedetecteerd.

Least privilege

OWASP beveelt aan om de rechten van een LLM-applicatie te beperken tot het minimum dat nodig is voor de beoogde werking. [1]

Dit verkleint de blast radius.

Een samenvattingssysteem dat geen e-mail kan verzenden, kan niet worden gemanipuleerd om het samengevatte document rechtstreeks te versturen via een e-mailfunctie die het niet bezit.

Toolautorisatie

Beveiligingsgevoelige tool-aanroepen moeten buiten het model worden gevalideerd.

Een model kan een operatie voorstellen; deterministische applicatielogica kan beslissen of die operatie is toegestaan.

Dit onderscheid is cruciaal, want verificatie is geen autorisatie.

Een model kan een aannemelijk en goed onderbouwd verzoek genereren en toch geen toestemming hebben om de gevraagde operatie uit te voeren.

Menselijke goedkeuring

OWASP beveelt menselijke goedkeuring aan voor risicovolle acties. [1]

Human-in-the-loop-controle is bijzonder relevant wanneer een AI-gegenereerde actie gevoelige informatie zou kunnen onthullen, toegang zou kunnen wijzigen, een financiële transactie zou kunnen activeren, productiesystemen zou kunnen aanpassen of juridische, klinische of andere aanzienlijke gevolgen zou kunnen hebben.

De beoordeling moet betekenisvol zijn en niet ceremonieel: de beoordelaar heeft voldoende context nodig om de voorgestelde actie en de gevolgen ervan te begrijpen.

Adversarieel testen

OWASP beveelt adversarieel testen en aanvalssimulaties aan. [1]

Het onderzoek van USENIX, BIPIA, SecureSQL en CaMeL toont verder aan waarom workflow-specifieke evaluatie van belang is. De prestaties variëren naargelang de taak, de aanval, de verdediging, het model, de rechten en de architectuur. [2][3][4][5]

Onafhankelijke verificatie

Onafhankelijke modelbeoordeling kan een afzonderlijke controle bieden op feitelijke onderbouwing, bronkwaliteit, inconsistenties, niet-onderbouwde uitspraken of onenigheid tussen gegenereerde conclusies.

Dat is een verificatiecontrole.

Het mag niet worden omschreven als een vervanging voor verdedigingen tegen prompt injection, toegangscontrole of autorisatie.

Als meerdere modellen hetzelfde vergiftigde bronmateriaal ontvangen en binnen dezelfde onveilige rechtenstructuur opereren, maakt overeenstemming tussen die modellen de workflow niet veilig.

Verificatie kan de zekerheid over een antwoord vergroten. Autorisatie bepaalt of een actie is toegestaan. Ze lossen verschillende problemen op.

Een verdedigbare architectuur met hoge zekerheid

Een volwassen LLM-workflow kan daarom worden ontworpen rond afzonderlijke controlestappen:

Externe invoer -> vertrouwensclassificatie -> permissiebewuste retrieval -> beperkte modelverwerking -> uitvoerverificatie -> deterministische autorisatie -> menselijke goedkeuring waar vereist -> actie -> auditregistratie

Elke stap beantwoordt een andere vraag.

Vertrouwensclassificatie: Waar is deze informatie ontstaan, en hoeveel gezag moet ze krijgen?

Retrieval: Is deze informatie toegestaan voor deze gebruiker en taak?

Modelverwerking: Welke conclusie of actie stelt het model voor?

Verificatie: Wordt de conclusie ondersteund door het beschikbare bewijs?

Autorisatie: Is de gevraagde actie toegestaan?

Menselijke beoordeling: Vereist het gevolg een verantwoordbaar menselijk oordeel?

Audit: Kan de organisatie reconstrueren wat er is gebeurd?

Al deze vragen combineren in één enkele prompt is zwakker dan het handhaven van onafhankelijke controles waar deterministische handhaving mogelijk is.

Verificatiechecklist voor risicovolle LLM-implementaties

Voordat een organisatie een LLM-workflow gevoelige informatie of ingrijpende acties toevertrouwt, moet zij het volledige pad van invoer tot uitvoering verifiëren.

Breng elke informatiebron in kaart

Documenteer elke locatie waaruit het AI-systeem informatie kan verkrijgen, waaronder gebruikersprompts, documenten, PDF's, e-mail, websites, zoekresultaten, databases, RAG-repositories, screenshots, afbeeldingen, API-antwoorden, tool-uitvoer en persistent agentgeheugen.

Het onderscheid van OWASP tussen directe, indirecte en multimodale prompt injection toont aan waarom extern gecontroleerde content deel moet uitmaken van het dreigingsmodel. [1]

Breng elke mogelijke actie in kaart

Leg elke operatie vast die het AI-systeem kan initiëren, waaronder het verzenden van berichten, het exporteren van bestanden, het bijwerken van records, het bevragen van databases, het wijzigen van rechten, het uitvoeren van code en het aanroepen van externe API's.

De potentiële impact van prompt injection hangt sterk af van wat het systeem mag doen.

Verifieer autorisatie onafhankelijk

Sta niet toe dat een door een LLM gegenereerd verzoek in de plaats komt van deterministische toegangscontrole.

Als een actie een bepaalde permissie vereist, valideer die permissie dan onafhankelijk van de redenering van het model.

Test indirecte prompt injection

Plaats gecontroleerde adversariële instructies in representatieve documenten, webpagina's, berichten en andere externe content, en test de volledige workflow.

BIPIA bestaat specifiek omdat het uitsluitend testen van directe gebruikersprompts geen dekking biedt voor indirecte injectie via externe content. [3]

Test toolmisbruik apart

Een gemanipuleerd tekstantwoord en een ongeautoriseerde externe actie zijn verschillende faalcategorieën.

Test beide.

Bescherm logs

Het loggen van prompts, retrieval, tool-calls en modeloutput kan belangrijk zijn voor auditeerbaarheid, maar die logs kunnen zelf gevoelige informatie bevatten.

Bewaring, toegang, minimalisatie en redactie vereisen daarom hun eigen controles.

Bereid een incident-responspad voor

Bepaal vooraf hoe agent-credentials kunnen worden ingetrokken, workflows kunnen worden uitgeschakeld, gecompromitteerde bronnen kunnen worden geïsoleerd en relevant bewijs kan worden bewaard.

Het vermogen om een incident te reconstrueren maakt deel uit van de operationele zekerheid.

Wat het bewijs uit 2026 daadwerkelijk ondersteunt

De sterkste conclusie is niet dat "LLM's onveilig zijn".

Het beschikbare bewijs ondersteunt iets preciezer.

Prompt injection blijft een erkend risico met hoge prioriteit voor LLM-toepassingen. OWASP plaatst het op LLM01:2025 en beveelt gelaagde mitigatie aan in plaats van te beweren dat er een universele preventieve maatregel bestaat. [1]

De effectiviteit van aanvallen en verdedigingen verschilt per model en taak. De peer-reviewed USENIX-benchmark evalueerde vijf aanvallen, tien verdedigingen, tien LLM's en zeven taken. [2]

Indirecte prompt injection is experimenteel aangetoond. BIPIA richt zich specifiek op adversariële instructies die zijn ingebed in externe content en identificeert de verwarring tussen instructie en context als een centraal onderdeel van het probleem. [3]

Er bestaan risico's voor gevoelige gegevens wanneer LLM's de toegang tot databases bemiddelen. SecureSQL evalueerde 932 voorbeelden in 34 domeinen met 15 modellen uit zes families en vond significante effecten van prompt-injection- en inferentie-aanvallen. [4]

Architecturale scheiding is een actieve verdedigingsrichting. CaMeL verplaatst belangrijke beveiligingsbeslissingen weg van onbeperkte modelinterpretatie naar expliciete control-flow- en capability-handhaving. De herziene v2 rapporteert 77% AgentDojo-taakvoltooiing met aantoonbare beveiliging, vergeleken met 84% voor het onverdedigde systeem. [5]

Kwaadaardige content voor indirecte prompt injection is waarneembaar op het publieke web. Google mat een relatieve toename van 32% in zijn kwaadaardige categorie tussen november 2025 en februari 2026 en waarschuwde daarbij expliciet dat een groot deel van de waargenomen activiteit relatief weinig geavanceerd bleef. [6]

Echte organisaties zijn geconfronteerd met kwaadaardige misbruik van legitieme GenAI-tooling. CrowdStrike rapporteert meer dan 90 organisaties die getroffen zijn door de activiteit beschreven in het 2026 Global Threat Report. [7]

Geen van deze bronnen bewijst dat elke AI-workflow gecompromitteerd zal worden.

Samen leveren ze sterk bewijs dat prompt injection en de toegangscontroleproblemen rond LLM-toepassingen beveiligingstechnische zaken zijn en niet slechts ongebruikelijk chatbotgedrag.

Conclusie

De centrale beveiligingsfout in enterprise-AI is dat men probabilistische taalinterpretatie beslissingen laat nemen die door deterministische beveiligingscontroles zouden moeten worden afgedwongen.

Een sterkere aanpak scheidt verantwoordelijkheden.

Behandel extern beheerde content als niet-vertrouwd.

Behoud toegangscontrole op de grenzen van retrieval en uitvoering.

Geef agents de minimale rechten die zij nodig hebben.

Laat modeloutput alleen niet toe om ingrijpende tool-acties te autoriseren.

Gebruik menselijke goedkeuring waar de impact een verantwoordelijk oordeel rechtvaardigt.

Test indirecte injectie tegen de daadwerkelijke workflow in plaats van alleen generieke jailbreak-prompts te testen.

Verifieer belangrijke outputs onafhankelijk.

En houd voldoende bewijs bij om te reconstrueren wat het systeem heeft ontvangen, voorgesteld, geverifieerd, geautoriseerd en uiteindelijk heeft gedaan.

Dat is het verschil tussen het beoordelen van de beveiliging van een LLM en het beoordelen van de beveiliging van een op LLM gebaseerd systeem.

Voor professionele omgevingen waarin gegenereerde antwoorden zelf aanvullende zekerheid vereisen, kunnen onafhankelijke modelbeoordeling, bronverificatie en een inspecteerbaar bewijsspoor een extra verificatielaag bieden. Dergelijke verificatie vervangt geen toegangscontrole, autorisatie of verdedigingen tegen prompt injection, maar behandelt een andere vraag: of een antwoord voldoende onderbouwd is om erop te kunnen vertrouwen.

De feitelijke gegevens in dit artikel zijn gebaseerd op Formalizing and Benchmarking Prompt Injection Attacks and Defenses en Indirect Prompt Injection Goes Operational.

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

Verder lezen op deze blog: De AI Act na de Digital Omnibus: uitstel voor hoog risico, vaste verplichtingen vanaf augustus 2026 en Waarom verificatie met één enkel AI-model tegen zijn grenzen aanloopt.

Bronnen: Belangrijke beweringen worden toegeschreven aan OWASP (LLM01:2025 prompt injection), CrowdStrike's 2026 Global Threat Report, Google Common Crawl-analyse en peer-reviewed onderzoek van Liu et al. (USENIX Security 2024) en Yi et al. (BIPIA, KDD 2025).

← Alle artikelen in dit thema ← Alle artikelen