Blog

Indirecte prompt injection via documenten en websites in 2026

Verborgen instructies in websites en documenten kunnen AI-systemen misleiden. Wat NIST, Google, arXiv en OWASP melden en wat dit betekent voor workflows.

· Victor Angelier

Indirecte prompt injection is in 2026 geen labcuriositeit meer. Waar een klassieke prompt injection via directe gebruikersinvoer verloopt, komen de kwaadaardige instructies bij de indirecte variant uit externe bronnen: een webpagina, een document of een e-mail. Het NIST CSRC Glossary definieert indirecte prompt injection als prompt injection die via resource control wordt uitgevoerd in plaats van via directe invoer. Daarmee worden externe bronnen expliciet erkend als aanvalsvector voor AI-systemen.

Voor professionals die met vertrouwelijke informatie werken, is dit relevant. Zodra een AI-systeem of AI-agent content ophaalt en verwerkt die niet volledig onder eigen controle staat, ontstaat het risico dat verborgen instructies het gedrag van het systeem sturen. Dat maakt de manier waarop externe content wordt behandeld tot een kernvraag in elke AI-workflow.

Wat de bronnen laten zien

Google beschrijft in het artikel AI threats in the wild: The current state of prompt injections on the web op de Google Security Blog hoe indirecte prompt injection in de praktijk op het openbare web voorkomt. Websites, e-mails en documenten kunnen kwaadaardige instructies dragen. Google rapporteert een stijging van 32% in de malicious category tussen november 2025 en februari 2026. Het gaat dus niet langer om een theoretische mogelijkheid, maar om een waargenomen signaal.

De schaal wordt onderbouwd door een empirische studie op arXiv met de titel Indirect Prompt Injection in the Wild: An Empirical Study of Prevalence, Techniques, and Objectives. De onderzoekers analyseerden 1,2 miljard URLs en vonden 15,3 duizend gevalideerde indirecte prompt injections op 11,7 duizend pagina's. Hun conclusie is nuchter maar belangrijk: webpagina's en HTTP-responses zijn een onbetrouwbare invoerbron voor LLM-gestuurde systemen.

Die conclusie is bruikbaar als vertrekpunt voor een concreet uitgangspunt: externe content is standaard onbetrouwbaar totdat het tegendeel is aangetoond.

Verdediging volgens OWASP

Waar de aanvalskant duidelijk wordt beschreven, biedt OWASP praktische richtlijnen aan de verdedigingskant. De LLM Prompt Injection Prevention Cheat Sheet classificeert remote of indirecte prompt injection als een aanvalspatroon waarbij kwaadaardige instructies verborgen zitten in externe content zoals webpagina's, documenten en e-mails. Als verdedigingslagen noemt OWASP onder meer sanitisatie van invoer, een duidelijke scheiding tussen instructies en data, het principe van least privilege en validatie van de output.

De AI Agent Security Cheat Sheet van OWASP legt dezelfde risico's specifiek bij AI-agents. Prompt injection via websites, documenten en e-mails wordt daar als kernrisico benoemd. De aanbevolen maatregelen omvatten inputsanitatie, scheiding tussen instructies en data, human-in-the-loop voor hoogrisico-acties en isolatie van context tussen gebruikers en sessies.

De rode draad in beide OWASP-documenten: behandel data en instructies niet als hetzelfde, geef systemen niet meer rechten dan nodig, en houd een mens in de lus bij gevoelige stappen.

Wat dit betekent voor gevoelige workflows

Voor advocaten, notarissen, bedrijfsartsen, journalisten, onderzoekers en compliance-teams is het onderliggende principe herkenbaar. Wie een extern document of een webpagina door een AI laat samenvatten of beoordelen, voert in feite content in waarvan de herkomst en betrouwbaarheid niet vaststaan. De empirische bevindingen op arXiv en de waarneming van Google onderstrepen dat dit reëel is.

De praktische vertaalslag die uit deze bronnen volgt, bestaat uit een paar principes:

  • Behandel externe content standaard als onbetrouwbaar en scheid instructies expliciet van data.
  • Beperk de rechten van AI-systemen tot het minimum dat een taak vereist.
  • Houd een mens in de lus bij acties met hoog risico of gevoelige gegevens.
  • Maak validatie en logging zichtbaar, zodat achteraf te controleren is wat er gebeurde.

De verbinding met verifieerbare controle

Deze principes sluiten aan bij de manier waarop een verificatieconsole als I am Vera is opgezet. Vera is geen chatbot en geen eigen taalmodel, maar een verificatielaag rond het werken met AI. In de architectuur vindt voorbewerking en anonimisering plaats op EU-infrastructuur, en is de workflow ontworpen om alleen geanonimiseerde inhoud naar de geselecteerde AI-modellen te sturen. Mislukt de privacycontrole, dan wordt niets doorgestuurd.

Die opzet raakt aan wat OWASP beschrijft als scheiding, controle en minimaal toegangsrecht. Door verificatiestappen zichtbaar te maken en meerdere modellen tegen elkaar af te wegen, kan Vera helpen om meer zicht te krijgen op wat een AI-antwoord onderbouwt. Wie documenten wil bekijken en bewerken binnen dezelfde beveiligde omgeving, doet dat via Vera Office; de Semantic Privacy Shield beschrijft de voorbewerking op EU-infrastructuur.

Belangrijk blijft de nuchtere lezing: geen enkele laag biedt zekerheid over correctheid of waarheid, en geen enkele maatregel elimineert het risico van misleidende instructies volledig. Wat wel mogelijk is, is controle inzichtelijker maken. Het professionele eindoordeel blijft altijd bij de gebruiker. De gecombineerde signalen van NIST, Google, arXiv en OWASP maken vooral één ding duidelijk: externe content verdient in 2026 standaard argwaan, en verdedigingslagen zijn geen luxe meer.

← Alle artikelen