LLM-beveiliging in 2026: dreigingen, verdediging en verificatie

U moet extern beheerde content als onbetrouwbaar behandelen, rechten buiten het model afdwingen, toolgebruik beperken tot het noodzakelijke minimum, en ingrijpende output en acties onafhankelijk verifiëren voordat zij worden uitgevoerd.

Een analyse van 29 augustus 2026 van prompt injection, ophaalrechten en tooluitvoering in LLM-systemen stelt dat enterprise-LLM-beveiliging niet langer voornamelijk een kwestie van modelgedrag is, maar van het systeem eromheen: wat het model kan lezen, ophalen, welke rechten het krijgt, en welke acties het kan uitvoeren. Het onderzoek gebruikt juridische, zorg- en compliance-omgevingen als voorbeelden waar deze architecturale scheiding kritiek is. In onze beoordeling betekent dit dat u niet langer kunt volstaan met prompts die het model instrueren zich correct te gedragen. U moet beveiligingsbeslissingen verplaatsen naar afdwingbare mechanismen buiten het model zelf.

Waarom extern gecontroleerde content een dreigingsmodel vereist

De traditionele benadering van LLM-beveiliging concentreerde zich sterk op wat een model zou kunnen genereren. Dit 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 vraag die u moet stellen is: welke informatie mag het model beïnvloeden, en welke informatie mag een actie beïnvloeden?

OWASP onderscheidt twee belangrijke vormen van prompt injection. 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. 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.

Welke faalcategorieën moet u in uw dreigingsmodel opnemen?

• Directe prompt injection — kwaadaardige instructies die rechtstreeks door een gebruiker aan het model worden aangeleverd.
• Indirecte prompt injection — kwaadaardige instructies die zijn ingebed in externe content zoals documenten, webpagina's of e-mails die het model verwerkt.
• Multimodale prompt injection — instructies die zijn ingebed in afbeeldingen, gescande documenten of ander niet-tekstueel materiaal dat het model kan verwerken.
• Ongeautoriseerde dataverzameling — het model dat gevoelige informatie ophaalt waartoe de gebruiker geen toestemming heeft.
• Ongeautoriseerde tooluitvoering — het model dat acties initieert die niet zijn toegestaan, zoals het verzenden van berichten of het wijzigen van records.
• Gevoelige data in logs — het vastleggen van prompts, retrieval en modeloutput op een manier die zelf gevoelige informatie blootstelt.

Hoe scheidt u vertrouwde instructies van onbetrouwde content?

BIPIA, onderzoek dat op KDD 2025 werd geaccepteerd, evalueerde prompt injection die via externe informatie werd binnengebracht. De onderzoekers constateerden dat de geëvalueerde modellen kwetsbaar waren voor kwaadaardige instructies die in externe content waren ingebed. Hun analyse identificeerde het onderscheid tussen informatieve context en uitvoerbare instructies als een centrale factor bij geslaagde aanvallen. Dit onderscheid wordt vooral belangrijk wanneer een AI-systeem tools kan aanroepen.

Denk aan een agent die het volgende kan aanvragen: het verzenden van een bericht naar een e-mailadres, het exporteren van een document naar een locatie, of het bijwerken van een record in een database. 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. 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.

Welke concrete 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, RAG-repositories, screenshots, afbeeldingen en API-antwoorden.
2. Inventariseer alle mogelijke acties — leg vast welke operaties het AI-systeem kan initiëren, waaronder het verzenden van berichten, het exporteren van bestanden, het bijwerken van records, het bevragen van databases en het aanroepen van externe API's.
3. Valideer permissies onafhankelijk van modelredenering — zorg ervoor dat als een actie een bepaalde permissie vereist, die permissie onafhankelijk wordt gevalideerd en niet afhankelijk is van wat het model voorstelt.
4. Test indirecte injectie tegen daadwerkelijke workflows — plaats gecontroleerde adversariële instructies in representatieve documenten, webpagina's en berichten, en test de volledige workflow in plaats van alleen generieke jailbreak-prompts te testen.
5. Implementeer verificatie voordat acties worden uitgevoerd — zorg ervoor dat ingrijpende tool-acties buiten het model worden gevalideerd en dat deterministische applicatielogica bepaalt of een operatie is toegestaan.
6. Behoud auditeerbare logs met toegangscontrole — leg vast wat het systeem heeft ontvangen, voorgesteld, geverifieerd, geautoriseerd en uiteindelijk heeft gedaan, met inachtneming van de gevoeligheid van de loggegevens zelf.

Hoe hangt dit samen met echte incidenten?

CrowdStrike rapporteert dat aanvallers in 2025 legitieme generatieve-AI-tools misbruikten bij meer dan 90 organisaties, waarbij zij kwaadaardige prompts injecteerden om commando's te genereren die werden gebruikt voor diefstal van inloggegevens en cryptovaluta. Dit is niet een theoretische demonstratie. Dit is operationeel misbruik. Google mat tussen november 2025 en februari 2026 een relatieve toename van 32% in materiaal geclassificeerd als kwaadaardige prompt injection, hoewel veel activiteit relatief weinig geavanceerd bleek te zijn. Dit onderscheid is belangrijk: detectiefrequentie, aanvalssuccespercentage en bevestigde beveiligingsincidenten zijn verschillende metingen.

SecureSQL evalueerde 932 voorbeelden in 34 domeinen met 15 modellen en vond significante effecten van prompt-injection- en inferentie-aanvallen op gevoelige gegevens. Dit toont 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.

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, en gebruik menselijke goedkeuring waar de impact een verantwoordelijk oordeel rechtvaardigt.

Tooling kan u helpen om logs vast te leggen, workflows uit te voeren en verificatie uit te voeren. Maar de architecturale beslissingen over waar beveiligingsgrenzen liggen, welke informatie welke gebruikers mogen zien, en welke acties welke autorisaties vereisen, blijven uw eigen professionele oordeel. Verificatie kan de zekerheid over een antwoord vergroten. Autorisatie bepaalt of een actie is toegestaan. Ze lossen verschillende problemen op, en beide zijn nodig.