Verborgen instructies in geüploade documenten kunnen LLM-oordelen sturen, ook als detectie aanslaat

Onderzoekers tonen aan dat verborgen instructies in gewone documenten de output van taalmodellen kunnen sturen, zelfs in gevoelige workflows zoals CV-screening, en dat detectie het effect niet betrouwbaar wegneemt. Behandel elke externe inhoud als onvertrouwde data, scheid die van instructies en laat gevolgtrekkingen pas na menselijke goedkeuring tot handelingen leiden.

In een op 23 juni 2026 gepubliceerde, peer-reviewed studie beschrijven Milani, Franzoni en Florindi hoe kwaadaardige instructies verstopt in ogenschijnlijk onschuldige documenten het gedrag van een taalmodel veranderen zonder dat de gebruiker zelf een vijandige prompt invoert. De onderzoekers testten 27 CV-documenten, zes consumentgerichte taalmodellen en vier aanvalsscenario's, en stelden vast dat alle geteste systemen gevoelig waren voor de onderzochte aanvallen.

Wat hebben de onderzoekers precies vastgesteld over indirecte prompt-injectie in documenten?

Zij definiëren indirecte prompt-injectie als instructies die zijn ingebed in externe inhoud die het model geacht wordt te analyseren, zoals een geüpload CV. Het model verwerkt die tekst niet alleen als gegevens om te beoordelen, maar volgt soms de erin verstopte opdracht op. Onze lezing: in een CV-screeningworkflow kan zo'n injectie de vergelijking tussen kandidaten vertekenen, omdat de verborgen opdracht de weging van de ene kandidaat tegenover de andere kan verschuiven.

De kern van hun bijdrage is een onderscheid dat in de praktijk vaak door elkaar loopt: een model kan een injectie detecteren en toch gedeeltelijk door die injectie beïnvloed blijven. Detectie en neutralisatie zijn dus niet hetzelfde. De onderzoekers wijzen er daarbij op dat eenvoudig filteren op trefwoorden tekortschiet, omdat ingevoegde instructies semantisch plausibel of versluierd kunnen zijn. Prompt-injectie staat ook bij de OWASP Foundation, de non-profit die de veelgebruikte lijst van topkwetsbaarheden voor LLM-applicaties onderhoudt, bekend als een leidende kwetsbaarheid; de studie sluit aan bij die bredere securitycontext.

Waarom biedt detectie van een injectie geen bescherming tegen het effect ervan?

Omdat detectie alleen aangeeft dat er iets verdachts in de inhoud zit, niet dat de uitkomst daardoor onaangetast blijft. Een waarschuwing in de output sluit niet uit dat de verborgen instructie het oordeel al heeft verschoven. Dit is precies het punt waarop organisaties zich kunnen verkijken op hun beveiliging.

Een preprint van Zhu en collega's van 4 april 2026 breidt dit beeld uit naar agentische, meerstaps tool-calling-omgevingen, waarin geïnjecteerde inhoud het gedrag van een agent en diens toolgebruik kan beïnvloeden. Over negen modellen en vier injectievectoren rapporteren zij hoge kaapratio's en constateren zij dat veelgebruikte oppervlakkige verdedigingen — promptwaarschuwingen, trefwoordfilters, parafrasering, spotlighting en LLM-as-a-judge (een tweede model dat de uitvoer beoordeelt) — vaak beperkte bescherming bieden. Hun analyse plaatst detectie vóór een toolaanroep boven controle achteraf. Dit is een preprint en nog niet peer-reviewed; wij lezen het als ondersteunend bewijs, niet als vaststaand feit.

De officiële veiligheidsrichtlijn van OpenAI, bijgewerkt op 7 oktober 2026, beschrijft prompt-injectie langs dezelfde lijn: onvertrouwde tekst of data die de instructies van een AI-systeem probeert te overschrijven, met mogelijke gevolgen als datalekkage, onbedoelde toolaanroepen en handelingen die afwijken van de bedoeling. OpenAI adviseert onvertrouwde variabelen uit bevoorrechte ontwikkelaarsinstructies te houden, gestructureerde uitvoer te gebruiken, toolgoedkeuringen aan te laten staan en externe data niet rechtstreeks het gedrag van een agent te laten sturen. Het bedrijf stelt expliciet dat deze maatregelen het risico verkleinen, maar niet wegnemen. Dit is leveranciersrichtlijn, geen onafhankelijke validatie.

Wat betekent dit voor bestuurders, juristen en CISO's die met AI documenten beoordelen?

Onze analyse: omdat detectie geen betrouwbare neutralisatie garandeert, blijft iedereen die een AI-oordeel ondertekent of verantwoordt persoonlijk blootgesteld aan een risico dat niet verdwijnt door een waarschuwingslabel; daarom moet elke externe input die een model verwerkt vanaf nu als potentieel gecompromitteerd worden behandeld en afzonderlijk worden vastgelegd. Naar onze analyse raakt de kwetsbaarheid rechtstreeks HR-, juridische en medische workflows die geüploade stukken beoordelen, juist omdat de onderzoekers het effect aantoonden in een CV-screening — een beslissing met gevolgen voor personen; daarom vereist dit volgens ons dat verwerkingsverantwoordelijken nu bepalen welke AI-beoordelingen een menselijke herbeoordeling vereisen voordat ze gevolgen krijgen. Omdat een gemanipuleerde output in een agentische keten kan uitmonden in een ongewenste handeling, loopt het risico door naar systemen waar het model mag lezen of schrijven; daarom moet de CISO naar onze analyse per workflow vastleggen welke tools en gegevens het model mag raken en consequente acties achter een goedkeuringsstap zetten. En omdat de studie één domein onderzocht en niet bewijst dat elk vakgebied dezelfde cijfers kent, is het naar onze inschatting onverstandig om de afwezigheid van een gemeten percentage te verwarren met afwezigheid van risico; daarom moeten auditors en compliance-functionarissen naar onze analyse per run de brontekst, de modelversie, de detectieresultaten, de goedkeuringen en de toolaanroepen bewaren om iedere AI-uitkomst reconstrueerbaar te maken, zodat achteraf te controleren is welke externe inhoud, modelversie en goedkeuring tot een besluit leidden.

Deze verantwoordelijkheid ligt dicht bij het onafhankelijke controlepunt tussen AI-analyse en formeel besluit dat wij eerder beschreven, en bij het risico dat externe inhoud een valse herinnering in een AI-agent plant.

Welke maatregelen scheiden onvertrouwde inhoud betrouwbaar van AI-handelingen?

Het antwoord ligt in gelaagdheid: scheiding, begrenzing en bewijs samen, niet in één filter. De onderzochte bronnen en onze eigen praktijk wijzen in dezelfde richting. Onderscheid daarbij drie dingen die vaak worden verward: detectie (verdachte inhoud herkennen), mitigatie (voorkomen dat die inhoud het resultaat verandert) en containment (voorkomen dat een gemanipuleerde output een ongeautoriseerde handeling wordt).

• Classificeer geüploade bestanden, opgehaalde webpagina's, e-mails en records als onvertrouwde data en houd ze uit de bevoorrechte instructiekanalen van het model.
• Haal waar mogelijk alleen vooraf vastgelegde velden uit een document (schema-gebonden extractie) in plaats van vrije tekst door het model te laten interpreteren.
• Scheid analyse van uitvoering: laat het model beoordelen, maar koppel geen toolaanroep of schrijfactie automatisch aan die beoordeling.
• Vereis menselijke goedkeuring voor gevolgrijke lees- of schrijfacties en pas least privilege op AI-agents toe tijdens de uitvoering.
• Test met adaptieve injecties die zich aanpassen aan uw verdediging, niet alleen met vaste testgevallen.
• Bewaar per run de brontekst, de modelversie, de detectieresultaten, de goedkeuringen en de toolaanroepen, zodat een oordeel achteraf reconstrueerbaar is.

Wie met gevoelige dossiers werkt, vindt in ons themahub over AI-security en aanvalsvlakken meer achtergrond bij deze scheiding tussen onvertrouwde inhoud en uitvoerbare instructies. De gemeenschappelijke boodschap van de drie bronnen is nuchter: deze aanvallen zijn reëel, en geen enkele maatregel neemt ze volledig weg — reden om het ontwerp van de workflow, niet één controle, als uw verdediging te behandelen.

Bronnen: Het artikel steunt op de peer-reviewed studie van Milani, Franzoni en Florindi (Neural Computing and Applications), de arXiv-preprint van Zhu et al. en de veiligheidsrichtlijn van OpenAI.