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.
U moet voortaan aannemen dat externe content — websites, documenten, e-mails — onbetrouwbare invoer voor AI-systemen vormt totdat u het tegendeel hebt aangetoond. Dit is niet langer theorie. Bouw verificatiestappen in voordat u AI-systemen externe bronnen laat verwerken.
De aanleiding is een analyse van 31 juli 2026 van indirecte prompt injection via externe bronnen, die aantoont dat verborgen instructies in websites en documenten AI-systemen kunnen misleiden. Het NIST CSRC Glossary erkent indirecte prompt injection expliciet als aanvalsvector: instructies die via resource control binnenkomen in plaats van via directe gebruikersinvoer. Een empirische studie op arXiv analyseerde 1,2 miljard URLs en vond 15,3 duizend gevalideerde indirecte prompt injections op 11,7 duizend pagina's. In onze beoordeling betekent dit dat u niet langer kunt werken alsof externe content veilig is. De signalen van NIST, Google en OWASP zijn eenduidig: dit is een waargenomen aanvalsvector in productie, niet een labcuriositeit.
Hoe werkt indirecte prompt injection in de praktijk?
Bij klassieke prompt injection geeft een gebruiker kwaadaardige instructies rechtstreeks in. Bij indirecte prompt injection zitten die instructies verborgen in content die een AI-systeem of AI-agent van buitenaf ophaalt: een webpagina, een PDF, een e-mail, een API-response. Het systeem verwerkt die content en voert daarbij onbedoeld de verborgen instructies uit.
Google rapporteerde een stijging van 32% in malicious prompt injections op het openbare web tussen november 2025 en februari 2026. De arXiv-studie toont aan dat dit geen marginaal probleem is. Webpagina's en HTTP-responses zijn onbetrouwbare invoerbronnen voor LLM-gestuurde systemen. Voor professionals die vertrouwelijke informatie verwerken — advocaten, notarissen, journalisten, onderzoekers — is dit relevant zodra zij AI gebruiken om externe documenten samen te vatten, te beoordelen of te analyseren.
Welke aanvalsvectoren moet u blokkeren?
- Verborgen instructies in webpagina's — kwaadaardige code of tekst ingebed in HTML die AI-systemen als commando's interpreteren.
- Prompt injection via documenten — instructies in PDF's, Word-bestanden of andere formaten die een AI-agent verwerkt.
- Misleiding via e-mailinhoud — verborgen commando's in e-mails die een AI-systeem doorleest en uitvoert.
- Context-verwarring — AI-systemen die niet onderscheiden tussen data en instructies, zodat beide als gelijkwaardig worden behandeld.
- Privilege escalation via externe content — een AI-agent krijgt meer rechten dan nodig en voert instructies uit die het niet zou mogen doen.
Welke verdedigingslagen moet u kunnen aantonen?
- Inputsanitatie en validatie — externe content wordt gecontroleerd en schoongemaakt voordat het naar een AI-model gaat.
- Scheiding tussen instructies en data — het systeem behandelt gebruikersinstructies en externe data als verschillende categorieën.
- Least privilege voor AI-agenten — AI-systemen krijgen alleen de rechten die zij nodig hebben voor hun specifieke taak.
- Human-in-the-loop voor gevoelige acties — een mens controleert en keurt goed voordat AI-output wordt gebruikt in kritieke werkstromen.
- Isolatie van context — data en sessies van verschillende gebruikers worden gescheiden zodat instructies niet tussen workflows lekken.
Hoe past dit in uw huidige workflows?
OWASP beschrijft deze verdedigingslagen in de LLM Prompt Injection Prevention Cheat Sheet en de AI Agent Security Cheat Sheet. De rode draad is consistent: behandel data en instructies niet als hetzelfde, geef systemen niet meer rechten dan nodig, en houd een mens in de lus bij gevoelige stappen.
Voor u betekent dit dat u niet langer kunt aannemen dat een AI-systeem veilig externe content verwerkt. Zodra u een AI inzet om een document te beoordelen, een website samen te vatten of een e-mail te analyseren, voert u in feite content in waarvan u de herkomst niet volledig controleert. De empirische bevindingen onderstrepen dat dit reëel is.
Wat kunnen tools doen, wat blijft uw verantwoordelijkheid?
Verificatielagen kunnen inputsanitatie automatiseren, context isoleren en meerdere AI-modellen tegen elkaar afwegen zodat u meer zicht krijgt op wat een antwoord onderbouwt. Wat geen tool kan doen: bepalen of de inhoud waar is, of de conclusie juist is, of het antwoord geschikt is voor uw specifieke casus. Geen verdedigingslaag elimineert het risico van misleidende instructies volledig. Wat wel mogelijk is, is controle inzichtelijker maken en verificatiestappen zichtbaar te houden. Het professionele eindoordeel blijft altijd bij u.
Bronnen: Dit artikel is gebaseerd op berichtgeving en richtlijnen van NIST, BLOG en OWASP.
Geschreven door
Tobias Lindqvist
Adversarial machine learning en de beveiligingseigenschappen van retrieval-systemen.