Förhindra RAG-dataförgiftning: Källproveniens, karantän och reindexeringstester

En chatbot på en webbplats kan ge ett artigt, språkligt övertygande och tekniskt korrekt genererat svar – och ändå arbeta utifrån en förgiftad kunskapsbas. Vid RAG-dataförgiftning är det inte i första hand formuleringen i en enskild förfrågan som manipuleras. I stället hamnar felaktigt, förvanskat eller otillräckligt granskat innehåll i den permanenta datakedjan: källa, parser, chunk, metadata, embedding och slutligen det produktiva retrieval-indexet. Felet kvarstår därmed över många sessioner och kan även påverka helt vanliga frågor.

Ett effektivt skydd börjar därför långt före prompten. För varje kunskapsbyggsten måste teamen kunna svara på: Varifrån kommer den, vem är ansvarig, vilken version behandlades, vilka transformationer ägde rum och efter vilken granskning godkändes den för sökning? Källproveniens ger detta spår. En tekniskt avskild karantän kan förhindra att ogranskade ändringar blir tillgängliga direkt. Riktade reindexeringstester kontrollerar därefter om rensat innehåll faktiskt har ersatt de gamla chunkarna.

Vad RAG-dataförgiftning är – och inte är

Klassificeringen OWASP LLM04:2025 Data and Model Poisoning beskriver manipulationer av förtränings-, finjusterings- eller embeddingdata som en integritetsrisk. För en webbplats-chatbot är särskilt den sista varianten påtaglig: Ett dokument tas in och delas upp i avsnitt; dessa chunks bäddas in och sparas som vektorer i retrieval-indexet. Om detta dokument avsiktligt eller av misstag förvanskas kan det vid passande frågor dyka upp som ett skenbart relevant underlag.

Riskerna måste skiljas åt, men kan överlappa varandra: Prompt injection försöker vid körtid slussa in instruktioner eller data så att systemet ändrar sitt avsedda beteende; indirekt prompt injection kan då även nå kontexten via hämtade dokument. Dataförgiftning ändrar däremot det mer långlivade kunskapsbeståndet eller dess härledningar. Även åtkomsträttigheter löser ett annat problem: De avgör vilken person som får se ett dokument. Proveniens och godkännande avgör om detta dokument ska nå indexet som en tillförlitlig kunskapskälla. I en robust arkitektur behöver alla tre riskerna egna kontroller och avstämda övergångar.

Angreppsytan finns i hela datakedjan

Ett RAG-index skapas sällan utifrån en enda, manuellt granskad samling. Crawlers läser webbplatser, konnektorer synkroniserar molnmappar, användare laddar upp filer och gränssnitt importerar produktdata. Till detta kommer parsrar, OCR, språkrensning, chunking och berikning av metadata. Varje steg kan ta över felaktigt innehåll eller lösrycka ett ursprungligen korrekt påstående från sitt sammanhang.

Typiska orsaker är ett komprometterat källsystem, ett nyligen länkat spegeldokument, en utkastfil som publicerats av misstag, en felaktigt kopplad kundinstans eller en parseruppdatering som kopplar tabellvärden till fel rubriker. Att jämföra en kryptografisk innehållshash med ett betrott referensvärde kan upptäcka avvikelser; en överensstämmande hash bevisar varken sanningshalt, aktualitet eller att innehållet är godkänt.

Proveniens som en granskningsbar datapost

För varje dokument och varje chunk som härleds ur det bör det finnas en proveniensdatapost. I praktiken är det användbart med minst ett stabilt käll-ID, den kanoniska ursprungs-URL:en, ansvarig ägare, hämtningstidpunkt, dokumentversion, innehållshash, godkännandestatus, förtroendeklass, parserversion, chunkingversion, embeddingmodell och indexgeneration. Vid manuella uppladdningar tillkommer den uppladdande personens roll och den granskade licensen. Vid synkroniserade system är det dessutom viktigt att registrera via vilken autentiserad konnektor filen kom.

Dokumentet NIST AI 600-1 Generative AI Profile behandlar content provenance, spårbar dokumentation samt tester och utvärderingar som viktiga byggstenar i riskhanteringen för generativ AI. Översatt till RAG-system innebär detta: Det är inte bara det aktuella indexet som räknas. Även det spårbara sambandet mellan källrevision, bearbetningskörning och publicerad indexgeneration hör till driftsdokumentationen.

En karantän skiljer intag från publicering

En central arkitekturbyggsten är en konsekvent separation: Nytt eller ändrat innehåll blir inte sökbart direkt. Det hamnar först i en intagszon. Där validerar pipelinen ursprung, filtyp, storlek, signatur eller förväntad hash, tillåten kundinstans, att metadata är kompletta samt ändringens omfattning. Först därefter skapas text och chunks i en icke-produktiv indexgeneration.

Reglerna bör vara riskbaserade. En ändring på en autentiserad FAQ-sida som förvaltas internt kan godkännas efter automatiska tester. En ny domän, en ovanligt omfattande textändring, en okänd filägare eller en källa utan ansvarig person utlöser däremot karantän och mänsklig granskning. Om en obligatorisk uppgift saknas gäller ”fail closed”: Den gamla, bekräftade generationen förblir aktiv; det nya läget publiceras inte i tysthet.

Godkännande som en oföränderlig indexgeneration

Efter granskningen skrivs ett produktivt index inte över steg för steg. Bättre är en ny, versionerad generation med ett manifest: förväntade dokument, förväntade chunks, källhashar, transformationsversioner och tidsstämplar. Först när testerna visar grönt växlar ett alias eller en routingkonfiguration atomärt till denna generation. Den föregående generationen finns kvar för återrullning under en begränsad, definierad tidsperiod.

Förfarandet liknar en kontrollerad migrering. Vår artikel om att byta RAG-embeddingmodell visar varför parallella indexgenerationer och jämförelsetester är användbara även vid tekniska ändringar. Vid misstanke om förgiftning tillkommer dessutom säkerhetsfrågan: Vilken källrevision och vilka härledda chunks måste spärras?

Fiktivt exempelscenario: En felaktig returfrist når supportboten

Anta att en återförsäljare driver en chatbot för produkt- och servicefrågor. Kunskapsbasen synkroniserar varje natt det officiella hjälpcentret och några godkända tillverkarportaler. Efter en länkändring följer en konnektor dock en omdirigering till en icke godkänd spegelsida. Där står det i en visuellt trovärdig PDF att returfristen är 90 i stället för 30 dagar. Filen delas upp i chunks; flera avsnitt hamnar i indexet med hög semantisk likhet.

Morgonen därpå utlovar boten en felaktig returfrist vid returfrågor. Språkmodellen har inte programmerats om och användarna har inte skrivit in någon skadlig instruktion. Retrieval-steget levererar helt enkelt ett felaktigt underlag. Övervakningen slår larm eftersom en ny domän för första gången dyker upp som svarskälla och ett golden set-test för returfristen avviker från det förväntade belägget.

Kontrollerad karantän och återstart

1. Teamet stoppar endast den berörda intagskällan och fryser den aktuella indexgenerationen för ytterligare ändringar.
2. Det misstänkta dokument-ID:t, alla chunks som härletts ur det och deras svarsträffar loggas i incidenten.
3. Spegeldomänen spärras och dess chunks flyttas till karantän. För frågor om returfristen ger boten tillfälligt en säker hänvisning till den mänskliga supporten eller den bekräftade policysidan.
4. Aliaset återställs till den senaste bevisligen rena indexgenerationen. Andra, oberörda kunskapsområden förblir därmed tillgängliga.
5. Konnektorn begränsas till den kanoniska källan. Därefter bygger pipelinen en ny generation utifrån det bekräftade manifestet.
6. Först efter reindexeringstester och en sakkunniggranskning tas denna generation i produktiv drift.

Denna ordningsföljd begränsar skadan utan att i förtid stänga av hela chatboten. Det avgörande är kopplingen mellan ursprungsdata och härledningar: Utan koppling från dokument till chunks skulle det vara oklart vilka vektorer som måste tas bort.

Reindexeringstester måste visa mer än en framgångsrik pipeline

En grön jobbstatus bevisar bara att processen avslutades tekniskt. Den bevisar varken att gamla chunks har försvunnit eller att rätt källor vinner vid realistiska frågor. Ett robust testpaket kontrollerar därför bestånd, retrieval och svarsbeteende.

1. Manifest- och raderingskontroll

Jämför den nya generationen med det godkända manifestet. Varje förväntad dokumentversion måste finnas på plats; spärrade dokument- och chunk-ID:n får inte förekomma. Särskilt viktiga är ”tombstones” för raderat eller ersatt innehåll. Att bara lägga till nya embeddings gör annars att gamla, förgiftade träffar finns kvar i indexet.

2. Retrieval-tester med förväntade källor

För kritiska frågor räcker det inte med en förväntad svarstext. Definiera dessutom tillåtna och förbjudna käll-ID:n, ett minsta antal träffar och exkluderingsvillkor. Returrätten måste till exempel härstamma från den kanoniska policyn; den karantänsatta spegeldomänen får varken synas i toppträffarna eller i modellkontexten. Hur sådana testset struktureras förklaras i artikeln om svarskvalitet med Golden Set och RAG-tester.

3. Negativ- och manipulationstester

I en isolerad testmiljö kan team mata in en tydligt märkt, icke godkänd testkälla. Pipelinen måste hålla den i karantän; den produktionsliknande sökningen får inte hämta den. Dessutom testas ovanliga domänbyten, saknade ägare, extrema innehållsskillnader och motstridiga datumangivelser. NIST-rapporten AI 100-2 om Adversarial Machine Learning klassificerar förgiftning som en angreppskategori i sin taxonomi och understryker att motåtgärder och deras begränsningar måste betraktas systematiskt.

4. Jämförelse före och efter skiftet

Kör samma frågor mot den senaste rena och den nya generationen. Jämför träffkällor, rangordning, svarsbelägg, no-answer-rate och sakkunnigbedömning. En liten canary-andel kan ge ytterligare produktionssignaler, så länge användarna inte får tillgång till ogranskade källor. Det produktiva skiftet sker först när fastställda säkerhets- och kvalitetsgränser uppfylls.

Övervakning: Upptäck avvikelser i tid

Övervaka inte bara svarsutvärderingar. Betydelsefulla indikatorer är nya eller sällsynta källdomäner, andelen ogranskade källor i intagsflödet, ovanliga dokumentstorlekar, stora hash- eller textskillnader, många nya chunks från en enskild ägare, förändringar av toppkällorna i golden set och svar utan bekräftat belägg. Mätvärden bör hänvisa till proveniens-ID:n, inte till onödigt sparade fullständiga användarfrågor.

Även aktualitet förblir relevant. En gammal policy som sedan länge har ersatts är inte avsiktligt förgiftad, men kan ge samma effekt. Artikeln om aktualitet i kunskapsbaser och Crawl-QA kompletterar säkerhetskontrollerna med kadens, ansvar och raderingsvägar.

Checklista för säkert RAG-intag

• Har varje källa ett stabilt ID, kanoniskt ursprung, ansvarig person och förtroendeklass?
• Loggas hash, dokumentversion, parser, chunking och embeddingmodell tillsammans?
• Stannar nya eller kraftigt ändrade källor utanför den produktiva sökningen tills de granskats?
• Leder nya domäner, saknade signaturer eller orimliga innehållsändringar till karantän?
• Publiceras godkända index som versionerade generationer med ett återrullningsbart alias?
• Tar en reindexering bevisligen bort ersatta chunks i stället för att bara lägga till ny data?
• Testar ett golden set såväl svar som förväntade och förbjudna källor?
• Finns det en säker fallback för ämnen vars källor har spärrats under en incident?
• Är roller för intag, sakkunniggranskning, incidenthantering och återpublicering utsedda separat?
• Dokumenteras det efter varje incident vilken kontroll som brast och vilket regressionstest som lades till?

Slutsats

RAG-dataförgiftning kan inte åtgärdas med en enskild promptregel. Skyddet uppstår ur en granskningsbar leveranskedja för kunskap: dokumentera ursprung, granska ändringar i karantän, versionera index, ta säkert bort gamla härledningar och testa retrieval med förväntade källor. Börja med de mest riskfyllda dokumentklasserna och ett litet golden set. Redan denna kombination gör det synligt vilken källa som bär upp ett svar – och möjliggör en riktad återrullning innan ett felaktigt kunskapsläge blir det permanenta normalläget.

Källor

• OWASP GenAI Security Project: LLM04:2025 Data and Model Poisoning
• NIST AI 600-1: Artificial Intelligence Risk Management Framework – Generative Artificial Intelligence Profile
• NIST AI 100-2: Adversarial Machine Learning – Taxonomy and Terminology of Attacks and Mitigations