Prompt injection-försvar för on-premises RAG: att härda retrieval-augmented generation

Varför RAG förändrar hotbilden

Retrieval-augmented generation ser ut som en ren arkitektur: håll modellen på privat infrastruktur, förankra svar i godkända korpusar och skicka inte känsliga promptar till externa tjänster. I praktiken blir den hämtade texten en del av prompten. Om en angripare kan påverka vad som hämtas, eller smyga instruktioner i källdokument, kan de styra modellen utan att någonsin röra ditt API-gateway.

On-premises distribution tar bort vissa molnrelaterade leverantörskedjeproblem, men den eliminerar inte missbruk på applikationsnivå. Team som bara hårdför nätverksvägar och behandlar hämtat innehåll som betrodd data upptäcker ofta indirekt prompt injection vid interna red team-övningar eller i första större piloten med opålitliga dokumentkällor.

Direkt kontra indirekt injection

Direkt prompt injection riktar sig mot användarmeddelandet eller systemprompten: en användare försöker åsidosätta policyer, läcka systeminstruktioner eller utlösa otillåtna verktygsanrop. Standardåtgärder inkluderar strikt rollseparation, policypromptar, utdatafiltrering och tillåtlista för verktyg.

Indirekt prompt injection gömmer instruktioner i dokument, ärenden, e-post eller webbsidor som senare dyker upp i hämtningsmängden. Modellen följer dessa instruktioner eftersom den uppfattar dem som mer kontext. Det är särskilt relevant när RAG-pipelines matas med wikis, supporttrådar eller kunduppladdningar där innehållet inte enhetligt skrivs av betrodd personal.

Försvar förutsätter att varje chunk som skickas till modellen kan innehålla attackerande text. Den antagandet ska forma hämtningsdesign, chunk-gränser, metadatahantering och hur verktyg exponeras för LLM:en.

Lager ett: begränsa vad hämtningen får returnera

Börja med att minska attackytan i indexet. Använd tydliga dokumentklasser och förtroendenivåer: till exempel policyhandböcker i ett högförtroende index, användargenererat innehåll i ett separat index med strängare nedströmsregler. Vektorsökning förstår inte förtroende; din applikation måste föra nivåmetadata till promptmonteringssteget.

Implementera chunk-hygien: rensa HTML och inbäddade skript från webbfångster, normalisera kodningar och undvik att slå ihop orelaterade källor till ett enda ogenomskinligt block. Mindre, väl attribuerade chunkar gör det enklare att logga vilket dokument som påverkade ett svar och att tillämpa nivåspecifika policyer.

Där det är möjligt, lägg till trösklar och diversifieringsvillkor vid hämtning så att ett enda förgiftat dokument inte kan dominera kontextfönstret genom upprepade nästan-duplikat.

Lager två: separera instruktioner från opålitligt underlag

Promptmontering ska göra modellens roll entydig. Ett praktiskt mönster är att wrappa hämtat material i tydligt avgränsade block märkta som opålitligt underlag och att ange att instruktioner däri inte får följas. Det är inte vattentätt, men minskar tydligt lyckade jailbreaks i intern testning i kombination med andra kontroller.

Använd strukturerade systempromptar som versionshanterade artefakter, inte redigerbara strängar utspridda i tjänster. Para ihop dem med utdatascheman eller styrd avkodning där uppgiften tillåter det, så att modellen leds mot maskinläsbara svar som nedströmsvalidatorer kan kontrollera.

Lager tre: verktyg, identitet och dataexfiltration

RAG sitter ofta före agenter som anropar SQL, API:er eller ärendesystem. Om modellen kan övertygas att generera ett verktygsanrop kan indirekt injection gå från textgenerering till handling. Åtgärder inkluderar:

• Begränsade behörigheter: körningsidentiteten för verktygsanrop ska ha minsta möjliga privilegier för arbetsflödet, inte bred användarimitation.

• Mänsklig godkännande för känsliga verktyg: i linje med operativ agentstyrning: högriskåtgärder går via uttryckliga godkännandeköer.

• Utgående filtrering: blockera eller larma när genererat innehåll försöker inkludera hemligheter, interna URL:er eller bilagemönster som tyder på exfiltration.

Loggning ska korrelera hämtade dokument-ID, verktygsanrop och användarsessioner så säkerhetsteam kan återskapa en incident utan att enbart förlita sig på råpromptar.

Test, övervakning och ansvar

Kör periodiska adversariella regressionssviter mot staging: kurerade poison-dokument, harmlöst utseende instruktioner inbäddade i tabeller och flerspråkig kringgående. Följ om policyer och filter fortfarande håller efter modell- eller embeddinguppgraderingar.

Produkt- och säkerhetsansvar ska vara tydligt: vem godkänner nya korpusar, vem får ändra hämtningsparametrar och vem signerar när modell- eller embeddingversionen ändras. On-premises RAG misslyckas oftare på grund av oklart ansvar när beteendet skiftar efter en tyst konfigurationsändring än på grund av saknad GPU-kapacitet.

Operativa mätvärden värda att dashboarda inkluderar toppar i avslag, ovanliga verktygsanropsmönster, hämtningskluster dominerade av lågförtroendekällor och plötsliga förändringar i genomsnittlig kontextlängd. Para tekniska signaler med periodisk granskning av representativa transkript så team märker kvalitativ drift innan användare rapporterar det.

Sammanfoga skydden

Effektivt försvar är kumulativt. Nätverkssegmentering och privat drift avgör var inferens körs; RAG-specifika kontroller avgör om hämtad text kan kapra beteende. Behandla dokumentkorpusar som potentiellt fientliga, separera policy från underlag i promptar, minimera verktygsblastrad och bevisa din hållning med repeterbara tester varje gång stacken ändras.

I arbete med nordiska och europeiska kunder ser vi ofta att de tekniska kontrollerna skapas snabbt medan processdisciplinen släpar efter: vem godkänner en ny källa, vem uppdaterar hotbilden när ett nytt verktyg kopplas in? Utan tydliga svar riskerar även stark arkitektur att urholkas över tid.

Utvald bild av Kirill Sh på Unsplash.