# Vraag naar je documenten, niet naar het model dat ze leest

**Samenvatting:** Koppel je een documentenbron aan een AI-platform, dan is de beveiligingsvraag niet hoe goed het model is, maar of je documenten ongeschonden blijven.

**Kort samengevat:** Eén vraag scheidt hier de leveranciers, en die gaat niet over intelligentie: komt onze content ongewijzigd door jullie systeem?

**Gepubliceerd:** 2026-08-03

**Laatst bijgewerkt:** 2026-08-10

Elke keer dat er een beveiligingsincident met AI naar buiten komt, gaat bij inkoop dezelfde vraag rond: op welk model draait dit, en is dat model veilig? Dat is de verkeerde vraag. Sta je op het punt een documentenbron aan een AI-platform te koppelen, dan bepaalt het oordeelsvermogen van het model je risico niet. Wat telt, is wat er in de pipeline met je tekst gebeurt, voordat welk model dan ook die te zien krijgt.

Heel concreet is er dus één vraag die het waard is om aan een leverancier te stellen: als jullie onze documenten inlezen, komt die content dan ongewijzigd door jullie systeem? Meestal is het antwoord ja, en ja is het riskante antwoord.

Een publicatie van eind juli laat zien waarom.

## De aanval die het punt maakt

Op 28 juli publiceerde beveiligingsonderzoeker Håkon Måløy het derde deel van zijn reeks "Context Collapse", over een prompt injection die Word-documenten verandert in dragers van hun eigen instructies. Simon Willison [besprak het de dag erna](https://simonwillison.net/2026/Jul/29/ai-worming-through-word/ "AI Worming through Word").

Een aanvaller zet verborgen instructies in een document, meestal witte tekst op een witte achtergrond, piepklein afgedrukt. Copilot voor Word haalt kleur en lettergrootte weg voordat de tekst wordt verwerkt, en leest dus precies het deel dat een mens niet kan zien. Copilot kan die instructies vervolgens behandelen als deel van de vraag van de gebruiker, ernaar handelen en ze overnemen in het document dat eruit komt. Dat uitvoerbestand is dan zelf ook een drager: gebruik je het als bronmateriaal in een andere workflow, dan kunnen de instructies opnieuw afgaan, terwijl het oorspronkelijke document van de aanvaller nergens in de buurt is.

[CSO Online](https://www.csoonline.com/article/4203630/copilot-worm-can-spread-through-microsoft-word-docs.html "Copilot worm can spread through Microsoft Word docs") en [CyberInsider](https://cyberinsider.com/microsoft-copilot-for-word-vulnerable-to-self-propagating-worm-like-attack/ "Microsoft Copilot for Word vulnerable to self-propagating worm-like attack") schreven er allebei over, en [Malwarebytes](https://www.malwarebytes.com/blog/ai/2026/07/hidden-microsoft-copilot-ai-worm "Hidden prompt turns Microsoft Copilot into an AI worm") beschreef hetzelfde zichzelf verspreidende gedrag. Dit is niet het randgeval van één onderzoeker. Het is reproduceerbaar.

## Een beter model was nooit de oplossing

Voor een koper is de tijdlijn van de melding het interessantste deel. Måløy meldde het probleem op 6 maart 2026 bij het Security Response Center van Microsoft, en Microsoft bevestigde het later die maand. Begin april kwam er een herziene versie van "Edit with Copilot", en de oorspronkelijke payload werkte niet meer.

Daarna herformuleerde hij de payload en kwam die er alsnog door. Microsoft opende een tweede zaak. Op 14 juli werd het onderliggende model van Copilot voor Word geüpgraded, en op 15 juli had Måløy ook dat gebroken. [iTnews meldde](https://www.itnews.com.au/news/microsoft-cant-kill-dogged-researchers-copilot-for-word-worm-627830 "Microsoft can't kill dogged researcher's Copilot for Word worm") dat aangepaste payloads deze klasse aanvallen tot en met 28 juli bleven reproduceren, na 144 dagen gecoördineerde melding.

Eer wie eer toekomt: Microsoft reageerde twee keer, en snel, en Måløy hield de precieze payload achter juist omdat er geen robuuste maatregel bestaat. Dat is geen slordigheid. Het punt is dat een payload dichten en een model upgraden allebei ingrepen aan het model zijn, terwijl de kwetsbaarheid daar niet zit. Een beter model verandert waar het systeem waarschijnlijk in trapt. Het verandert niets aan de vraag of verborgen tekst in een brondocument de instructies van het systeem kan bereiken.

## Waarom dit niet alleen een probleem van Copilot is

De redelijke tegenwerping is dat dit één integratie van Microsoft betreft, en dat Microsoft die uiteindelijk wel inperkt. Terecht. Maar kijk wat de aanval werkelijk nodig heeft: een pipeline die brontekst grotendeels intact doorgeeft, naar een uitvoer die de volgende invoer wordt.

Dat is niet exotisch. Dat is wat de meeste AI die met documenten werkt nu eenmaal doet, want je documenten bewaren is normaal gesproken juist de bedoeling. Indexeert een leverancier je bestanden en haalt daar passages uit op, dan is de oorspronkelijke tekst nog steeds wat er door het systeem beweegt, en een verborgen instructie daarin beweegt gewoon mee. De integratie was specifiek. De eigenschap is algemeen.

Daarom gaat de vraag over jouw documenten in plaats van over hun model.

## Hoe wij die vraag beantwoorden

Bij UNLESS bewaart Living Knowledge je documenten niet zoals ze binnenkwamen. Alles wat jouw bedrijf weet, wordt [doorlopend opnieuw gestructureerd en herschreven tot één ondubbelzinnige Library](https://unless.com/en/engine/ "Engine: het platform dat zichzelf onderhoudt"), en de homepage zegt het in gewone woorden: wat de agent weet, is geschoond, herschreven, ondubbelzinnig en actueel. Wat de retrieval-index vasthoudt, is een gegenereerde content node en niet het bestand dat jij hebt gestuurd.

Ons antwoord op de vraag is dus nee, je content komt er niet ongewijzigd door, en dat is precies de bedoeling. Een verborgen instructie overleeft het kopiëren. Wat die niet overleeft, is herschreven worden tot iets anders. De verspreidingsstap waar deze aanval van afhangt, wordt niet geblokkeerd maar bestaat simpelweg niet.

Datzelfde ontwerp levert een tweede voordeel op. Omdat elk ingelezen item door die herschrijving heen moet, is daar ook de plek waar alles kan worden nagekeken: op beveiligingsproblemen, en op de vraag of het in deze Content Library thuishoort. Over één knelpunt valt veel makkelijker na te denken dan over duizend documenten die er rechtstreeks doorheen stromen.

Daaromheen staan maatregelen die we al beschrijven. Tegenstrijdige beweringen worden aan het licht gebracht in plaats van stil samengevoegd, zodat een bibliotheek die zichzelf tegenspreekt zichtbaar werk oplevert: de Inbox brengt het conflict naar voren en één klik op Accepteren of Weigeren lost het op. Automatische wijzigingen in content wachten op die menselijke beslissing. [Gescheiden contentsilo's](https://unless.com/en/trust/ "Trust: vanaf dag één gebouwd voor de EU") zorgen dat de data van de ene klant nooit bij de agent van een andere klant komt. En de agent zet geen onomkeerbare stap zonder dat een mens de grens eerst goedkeurt.

## Wat we niet beweren

Wij lezen documenten in voor de kost, dus we zitten middenin dit probleem in plaats van ernaar te kijken. Niemand die eerlijk is, zegt dat een categorie dreigingen voorgoed dicht is. Een leverancier die dat wel zegt, vertelt je iets over de eigen ontwikkelcultuur en niets over het product.

Wat wij beweren is beperkter, en het gaat over architectuur. Een pipeline die herschrijft wat er binnenkomt, draagt een ander soort risico dan een pipeline die documenten doorgeeft. Dat verschil komt niet uit een beter model, en het komt ook niet met het volgende model.

## De vraag, nog één keer

Komt de volgende melding, en die komt, dan is de nuttige vraag niet welk model erin trapte.

Vraag wat de pipeline van je leverancier met je tekst doet tussen het moment dat die binnenkomt en het moment dat een agent die leest. Vraag of je documenten er aan de andere kant herkenbaar uitkomen. Is het antwoord ja, vraag dan wat tegenhoudt dat wat erin verborgen zit er net zo herkenbaar uitkomt.

Vraag het voordat je de documentenbron koppelt, niet erna.