LLM-beveiliging in 2026: dreigingen, verdediging en verificatie

U moet extern beheerde content als onbetrouwbaar behandelen, toegangsrechten buiten het model afdwingen, toolgebruik beperken tot minimale vereisten, en ingrijpende output en acties onafhankelijk verifiëren voordat ze worden uitgevoerd.

Een analyse van 29 augustus 2026 van prompt injection, ophaalrechten, tooluitvoering en architectuurcontroles stelt dat het beveiligingsrisico van LLM-toepassingen niet primair uit modelgedrag voortvloeit, maar uit wat het systeem rondom het model het kan lezen, ophalen, welke rechten het krijgt, en welke acties het kan uitvoeren. Een juridische assistent kan bijvoorbeeld een instructie van een gebruiker combineren met een document dat door een derde partij is aangeleverd, waarna een agent die combinatie gebruikt om een toolaanroep te kiezen. In onze beoordeling betekent dit dat beveiliging niet kan afhangen van de vraag of een LLM een instructie correct interpreteert, maar moet worden verankerd in afdwingbare mechanismen buiten het model zelf.

Waar ontstaat het risico van prompt injection?

Prompt injection is in twee vormen erkend. Directe injectie treedt op wanneer invoer die rechtstreeks aan het model wordt aangeleverd het gedrag op onbedoelde wijze verandert. Indirecte injectie treedt op wanneer instructies zijn ingebed in extern materiaal dat door de LLM wordt verwerkt, zoals webpagina's, documenten of e-mails. Dit onderscheid is belangrijk omdat enterprise-AI-systemen veel van hun nut ontlenen aan externe informatie.

Een juridisch AI-systeem is waardevol omdat het contracten, bewijsmateriaal en correspondentie kan verwerken. Een compliance-assistent kan beleid en dossiers inspecteren. Een retrieval-augmented systeem is afhankelijk van informatie uit andere gegevensopslagen. 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.

Prompt injection is niet beperkt tot gewone zichtbare tekst. Kwaadaardige invoer hoeft niet leesbaar voor mensen te zijn, zolang het model die kan verwerken. Dit omvat ook multimodale injectie met instructies die in afbeeldingen zijn ingebed. Systemen die gescande documenten, screenshots, presentatiebestanden of ander multimodaal materiaal accepteren, moeten die kanalen opnemen in hun dreigingsmodel.

Welke faalcategorieën moet u voorkomen?

• Directe prompt injection — onbedoelde gedragsverandering door gebruikersinvoer die rechtstreeks aan het model wordt aangeleverd.
• Indirecte prompt injection — kwaadaardige instructies ingebed in externe content zoals webpagina's, documenten of e-mailbijlagen.
• Multimodale injectie — adversariële instructies verborgen in afbeeldingen, PDF's of andere niet-tekstuele formaten.
• Ongeautoriseerde gegevensopenbaring — gevoelige informatie blootgesteld via prompt injection tegen databases of retrieval-systemen.
• Ongeautoriseerde tooluitvoering — een model dat manipulatie gebruikt om acties uit te voeren waartoe het geen toestemming heeft.
• Vervuiling van audit-trails — onvoldoende logging van wat het systeem heeft ontvangen, voorgesteld, geverifieerd en uiteindelijk heeft gedaan.

Wat toont het beschikbare onderzoek over ernst en omvang?

Echte organisaties zijn geconfronteerd met kwaadaardige misbruik van legitieme generatieve-AI-tooling. Aanvallers hebben in 2025 legitieme GenAI-tools misbruikt bij meer dan 90 organisaties, waarbij zij kwaadaardige prompts injecteerden om commando's te genereren die werden gebruikt voor diefstal van inloggegevens en cryptovaluta.

Indirecte prompt injection is experimenteel aangetoond. Onderzoek naar indirecte injectie constateerde dat geteste LLM's kwetsbaar waren voor kwaadaardige instructies ingebed in externe content. 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.

Er bestaan risico's voor gevoelige gegevens wanneer LLM's de toegang tot databases bemiddelen. Onderzoek naar natuurlijketaal-database-interfaces evalueerde 932 voorbeelden in 34 domeinen met 15 modellen en vond significante effecten van prompt-injection- en inferentie-aanvallen. Het best presterende model behaalde een nauwkeurigheid van 61,7%, vergeleken met 94% voor mensen in dezelfde benchmark.

Kwaadaardige content voor indirecte prompt injection is waarneembaar op het publieke web. Analyse van gearchiveerde openbare webcontent mat een relatieve toename van 32% in materiaal geclassificeerd als kwaadaardige prompt injection tussen november 2025 en februari 2026, hoewel veel activiteit relatief weinig geavanceerd bleef.

Welke controles moet u kunnen aantonen?

1. Documenteer elke informatiebron — leg vast waar het AI-systeem informatie kan verkrijgen, waaronder gebruikersprompts, documenten, e-mail, websites, databases, retrieval-repositories, afbeeldingen en API-antwoorden.
2. Inventariseer elke mogelijke actie — leg vast welke operaties het AI-systeem kan initiëren, waaronder berichten verzenden, bestanden exporteren, records bijwerken, databases bevragen, rechten wijzigen en externe API's aanroepen.
3. Scheidt vertrouwde van onvertrouwde invoer — behandel extern beheerde content als onbetrouwbaar en onderscheid deze duidelijk van vertrouwde instructies in systeemconfiguratie.
4. Valideer autorisatie buiten het model — laat een door een LLM gegenereerd verzoek niet in de plaats komen van deterministische toegangscontrole; valideer permissies onafhankelijk van de redenering van het model.
5. Test indirecte injectie in daadwerkelijke workflows — plaats gecontroleerde adversariële instructies in representatieve documenten, webpagina's en externe content, en test de volledige workflow van invoer tot uitvoering.
6. Implementeer menselijke goedkeuring voor ingrijpende acties — vereist goedkeuring door een beoordelaar die voldoende context heeft wanneer een AI-gegenereerde actie gevoelige informatie zou kunnen onthullen, toegang zou kunnen wijzigen, financiële transacties zou kunnen activeren of juridische gevolgen zou kunnen hebben.

Hoe moet een volwassen LLM-workflow zijn gestructureerd?

De centrale beveiligingsfout in enterprise-AI is dat probabilistische taalinterpretatie beslissingen laat nemen die door deterministische beveiligingscontroles zouden moeten worden afgedwongen. Een sterkere aanpak scheidt verantwoordelijkheden.

Een volwassen workflow kan worden ontworpen rond afzonderlijke controlestappen: externe invoer → vertrouwensclassificatie → permissiebewuste retrieval → beperkte modelverwerking → uitvoerverificatie → deterministische autorisatie → menselijke goedkeuring waar vereist → actie → auditregistratie.

Vertrouwensclassificatie bepaalt waar informatie ontstaan is en hoeveel gezag zij moet krijgen. Retrieval controleert of informatie toegestaan is voor deze gebruiker en taak. Modelverwerking genereert een voorstel. Verificatie controleert of het voorstel wordt ondersteund door beschikbaar bewijs. Autorisatie bepaalt of de gevraagde actie is toegestaan. Menselijke beoordeling vereist verantwoordelijk oordeel waar de impact dit rechtvaardigt. Audit maakt reconstructie van het pad mogelijk.

Al deze vragen combineren in één enkele prompt is zwakker dan het handhaven van onafhankelijke controles waar deterministische handhaving mogelijk is. Dit onderscheid is cruciaal, want verificatie is geen autorisatie. Een model kan een aannemelijk verzoek genereren en toch geen toestemming hebben om de gevraagde operatie uit te voeren.

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. Tooling kan verificatie automatiseren en audit-trails genereren, maar het oordeel over welke acties menselijke goedkeuring vereisen, en welke informatie gevoelig genoeg is om afzonderlijke toegangscontrole te rechtvaardigen, blijft uw eigen professionele verantwoordelijkheid.