Prompt Injection tīmekļa vietņu čatbotos: RAG, rīku un datu aizsardzība

Tīmekļa vietnes čatbots neapstrādā tikai nekaitīgus jautājumus. Apmeklētāji var mēģināt pārrakstīt tā noteikumus, atklāt iekšējās instrukcijas vai izraisīt neatļautas darbības. Vēl grūtāk pamanāmas ir komandas, kas atrodas nevis tieši tērzēšanā, bet gan ir paslēptas nolasītajā tīmekļa lapā, augšupielādētā dokumentā vai pievienotā trešās puses sistēmā.

Ievērojot to, ikviens, kurš vēlas ierobežot prompt injection tīmekļa vietņu čatbotos, nedrīkst paļauties tikai uz īpaši stingri formulētu sistēmas promptu. Ir nepieciešama daudzzonu arhitektūra: ievades un avoti tiek apstrādāti kā neuzticami, piekļuves tiesības tiek tehniski ierobežotas, izvades tiek pārbaudītas pirms tālākās apstrādes, un riskantas darbības apstiprina deterministisks kods vai cilvēks.

Ko nozīmē prompt injection tīmekļa vietnes čatbotā

OWASP raksturo prompt injection kā ievadi, kas nejauši vai neparedzēti maina valodas modeļa uzvedību vai izvadi. Tiešā prompt injection nāk tieši no lietotāja, piemēram, kā aicinājums ignorēt iepriekšējos noteikumus. Savukārt netiešā prompt injection atrodas ārējā saturā, ko sistēma vēlāk iegūst: tīmekļa lapās, zināšanu dokumentos, e-pastos, produktu datos vai failos.

Šī atšķirība ir svarīga tīmekļa vietņu uzturētājiem. Vienkāršam BUJ čatbotam ir mazāka uzbrukuma virsma nekā sistēmai, kas nepārtraukti pārmeklē tīmekļa lapas, pārmeklē iekšējos dokumentus, lasa CRM datus vai spēj izpildīt funkcijas. Retrieval-Augmented Generation jeb RAG gan uzlabo atbilžu satura precizitāti, taču nenovērš injection risku. Arī labi uzturēta avotu bāze var saturēt manipulētas vai pārprastas instrukcijas.

Novērtēt risku pēc funkcijām, nevis modeļa nosaukuma

Izšķirošais jautājums ir ne tikai: "Kādu modeli mēs izmantojam?", bet gan: "Kādu ietekmi var radīt manipulēta atbilde?" Izveidojiet čatbotam vienkāršu funkciju un datu karti:

• Kādus publiskos un iekšējos avotus tas drīkst lasīt?
• Kādi personas dati, konfidenciāli vai uzņēmējdarbībai kritiski dati ir pieejami?
• Vai tas spēj tikai ģenerēt tekstu, vai arī izveidot pieteikumus, piesaistīt interesentus (leads), sūtīt e-pastus, plānot tikšanās vai noformēt pasūtījumus?
• Kādas darbības maina ārējās sistēmas?
• Kādi lēmumi tiek pieņemti automātiski, bez cilvēka pārbaudes?

Jo lielākas kļūst lasīšanas un rakstīšanas tiesības un automatizācijas pakāpe, jo svarīgākas kļūst tehniskās robežas ārpus paša modeļa. Esošais pārskats par biežākajām AI čatbotu kļūdām palīdz vispārējā inventarizācijā. Lai aizsargātos pret prompt injection, jums papildus jādokumentē datu plūsmas, uzticības robežas un darbību tiesības.

Skaidri nošķirt četras uzticības zonas

Praktisks drošības modelis izdala četras zonas, pat ja tehniskā ziņā tās tiek apstrādātas vienā un tajā pašā lietotnē.

1. zona: Sistēmas noteikumi un vadlīnijas

Šeit atrodas loma, atļautais mērķis, atbilžu robežas un eskalācijas noteikumi. Šie noteikumi dod modelim orientāciju, taču nav uzticama piekļuves kontrole. OWASP izteikti brīdina neuzskatīt sistēmas promptus par noslēpumu vai drošības mehānismu. Piekļuves dati, savienojuma atslēgas un jutīga iekšējā informācija tajos nedrīkst atrasties.

2. zona: Apmeklētāju ievades

Katra tērzēšanas ziņa tiek uzskatīta par neuzticamu. Ierobežojiet garumu, failu tipus un atļautās funkcijas; normalizējiet ievades tehniskajai apstrādei un promptā skaidri apzīmējiet tās kā lietotāja datus. Filtrs var atpazīt zināmus uzbrukumu paraugus, taču tas nedrīkst vispārīgi bloķēt leģitīmus jautājumus. Apmeklētājam, kurš drošības dokumentācijā jautā par "ignore previous instructions", var būt pilnīgi pamatots iemesls.

3. zona: Iegūtie avoti un RAG konteksts

Arī nolasītais saturs, PDF faili un ārējo pakalpojumu rezultāti paliek dati, nevis instrukcijas. Redzami nošķiriet to saturu no vadības konteksta, saglabājiet izcelsmi un ieguves laiku, kā arī atļaujiet tikai apstiprinātus avotus. Raksts par AI čatbotu zināšanu bāzes aktualitāti parāda, kā savstarpēji mijiedarbojas avotu inventārs, pārmeklēšanas biežums un QA.

4. zona: Rīki, darbības un izvades

Funkciju izsaukumus nedrīkst izpildīt tikai tāpēc, ka modelis ģenerē atbilstošu tekstu. Deterministisks kontrolieris pārbauda funkcijas nosaukumu, parametrus, atļaujas, sesijas kontekstu un atļautās mērķa sistēmas. Modeļa izvadei, kas vēlāk tiek izmantota kā HTML, Markdown, SQL, faila ceļš vai API parametrs, nepieciešama šim kontekstam atbilstoša validācija un kodēšana.

Minimālo privilēģiju principa (Least Privilege) pielietošana seku ierobežošanai

Ar pašreizējām tehnoloģijām prompt injection nav iespējams pilnībā novērst ar vienu paņēmienu. Tāpēc lietotne ir jāizstrādā tā, lai veiksmīgs manipulācijas mēģinājums darītu pēc iespējas mazāku kaitējumu. OWASP un Microsoft šim nolūkam iesaka minimālo privilēģiju (Least Privilege) principu.

• Izmantojiet nošķirtas tehniskās identitātes lasīšanai un rakstīšanai.
• Piešķiriet piekļuvi tikai tiem datiem, kas ir nepieciešami konkrētajam čatbota mērķim.
• Ierobežojiet funkcijas ar mazām, skaidri definētām parametru shēmām.
• Izmantojiet īslaicīgas atļaujas, ja darbībai tādas vispār nepieciešamas.
• Pieprasiet skaidru apstiprinājumu riskantiem vai neatgriezeniskiem soļiem.
• Nekad neuzticiet autorizāciju modeļa brīvajam tekstam.

Atbalsta čatbots, piemēram, var sagatavot pieteikuma melnrakstu, taču tam nevajadzētu automātiski noteikt patvaļīgus saņēmējus, prioritātes vai iekšējās piekļuves tiesības. Potenciālo klientu piesaistes čatbots var pieņemt strukturētus kontaktinformācijas datus, neiegūstot lasīšanas tiesības visai CRM sistēmai.

RAG avotu pārbaude un izolēšana

Netiešā prompt injection padara avotu konveijeru (pipeline) par drošības arhitektūras sastāvdaļu. Manipulēta lapa vizuāli var izskatīties nekaitīga, taču joprojām saturēt tekstu, ko modelis interpretē kā instrukciju. Multimodālās sistēmās lomu var spēlēt arī attēli vai citi failu formāti.

Tāpēc ieviesiet avotu ievades procesu ar apstiprināšanas noteikumiem: atļautie domēni un dokumentu sadaļas, izsekojami īpašnieki, versiju vadība, ļaunprātīgas programmatūras un failu pārbaude, kā arī pārskatīšana jaunam vai neparasti izmainītam saturam. Modeļa kontekstā skaidri atzīmējiet iegūtās rindkopas kā neuzticamu saturu (untrusted content). Meklēšanas rezultāts drīkst sniegt informāciju, bet nedrīkst mainīt sistēmas noteikumus vai rīku tiesības.

Papildus pārbaudiet, vai atbilde patiešām ir pamatota ar avotiem. Ceļvedis par AI čatbotu atbilžu kvalitātes mērīšanu ar Golden Set un RAG testiem apraksta pamatojamību (groundedness) un avotu salīdzināšanu. Šī kvalitātes pārbaude papildina drošības kontroles, taču neaizstāj tās.

Ievades un izvades filtri ir tikai viens slānis, nevis viss risinājums

Specializēti aizsardzības pakalpojumi var atpazīt tiešos un netiešos uzbrukumu mēģinājumus. Piemēram, Microsoft Prompt Shields nošķir uzbrukumus lietotāja ievadē no paslēptām instrukcijām dokumentos. Google savās drošības vadlīnijās tāpat iesaka aizsardzības pasākumus pret prompt injection, šaurāk definētus uzdevumus, lietotāju identifikatorus, apjoma ierobežojumus un cilvēka uzraudzību augstāka riska gadījumos.

Šādi filtri sniedz varbūtības signālus. Tāpēc plānojiet pakāpenisku uzvedību: bloķēt, atbildēt drošā veidā, pāriet uz stingri ierobežotu režīmu vai nodot ziņu cilvēkam. Reģistrējiet lēmuma klasi un tehnisko versiju, taču izvairieties no nevajadzīgas pilna teksta saglabāšanas. Apstrādājot personas datus, papildus piemērojami pārbaudes jautājumi, kas aprakstīti rakstā par AI čatbotiem un VDAR. Šis raksts nav juridisks padoms.

Validēt modeļa izvadi pirms tālākās apstrādes

Droša ievade negarantē drošu izvadi. OWASP norāda uz nepietiekamu izvades apstrādi kā atsevišķu risku: modeļa teksts vēlāk var nonākt HTML, skriptos, datubāzes pieprasījumos vai failu ceļos. Tāpēc katru modeļa izvadi vispirms uzskatiet par neuzticamu.

Pieprasiet automatizētiem procesiem stingru strukturētu formātu un validējiet to pret shēmu. Izmantojiet balto sarakstu funkciju nosaukumiem un mērķa sistēmām. Kodējiet redzamo tekstu atbilstoši attiecīgajam izvades kontekstam. Noidzēsiet negaidītus laukus, ārējās URL adreses un parametrus ārpus atļautajām vērtībām. Jutīgiem datiem pirms parādīšanas vai pārsūtīšanas vajadzētu iziet vēl vienu atsevišķu politiku pārbaudi.

Prompt injection pārbaude ar drošības testu kopu

Papildiniet nozares Golden Set ar uzbrukumu (adversarial) testa gadījumiem. Testiem ir jāpārbauda faktiskā produkcijas sistēma, ieskaitot informācijas iegūšanu (retrieval), rīkus un atļauju loģiku, nevis tikai bāzes modelis. Noderīga kopa satur:

• tiešos mēģinājumus aizstāt noteikumus vai pieprasīt iekšējās instrukcijas;
• daudzvalodu, kodētas un caur vairākām ziņām izkliedētas variācijas;
• nekaitīgus nozares jautājumus, kas satur līdzīgus atslēgvārdus un kurus nedrīkst kļūdaini bloķēt;
• manipulētas rindkopas testa zināšanu avotā;
• neatļautus funkciju nosaukumus, papildu parametrus un svešas mērķa adreses;
• mēģinājumus izvadīt konfidenciālus datus vai iepriekšējo sesiju saturu;
• testus HTML, Markdown un saišu izvadei;
• pārtraukšanas, nodošanas (handoff) un apstiprināšanas ceļus riskantām darbībām.

Nemēriet tikai to, vai filtrs nostrādā. Pārbaudiet galarezultātu: vai tika novērsta neatļauta darbība? Vai konfidenciālie dati palika aizsargāti? Vai leģitīms pieprasījums turpināja darboties? Vai aizdomīgs gadījums tika izsekojami reģistrēts?

Praktisks ieviešanas plāns tīmekļa vietņu komandām

1. Aptvert apjomu: dokumentēt datu avotus, rīkus, rakstīšanas tiesības un ārējos mērķus.
2. Nošķirt uzticības zonas: tehniski marķēt sistēmas noteikumus, lietotāja ievadi, RAG saturu un darbību izvadi.
3. Samazināt tiesības: noņemt neizmantotās piekļuves un sadalīt rakstīšanas darbības mazās funkcijās.
4. Papildināt validāciju: ieviest ievades ierobežojumus, strukturētas izvades, balto sarakstu un kontekstam specifisku kodēšanu.
5. Noteikt apstiprināšanu: nodrošināt riskantas darbības un jutīgas datu plūsmas ar cilvēka līdzdalību (Human-in-the-Loop).
6. Izpildīt testu kopu: pārbaudīt tiešos, netiešos un leģitīmos kontroles gadījumus pirms katra nozīmīga laidiena.
7. Novērot darbību: regulāri pārskatīt filtru notikumus, noraidītās darbības, neparastas avotu izmaiņas un viltus trauksmes.

Pārbaudes saraksts: aizsardzība pret prompt injection

• Sistēmas prompts nesatur noslēpumus un neaizstāj autorizāciju.
• Lietotāja teksti un ārējie avoti pēc noklusējuma tiek uzskatīti par neuzticamiem.
• RAG avotiem ir apstiprinājums, izcelsme, versija un atbildīgie īpašnieki.
• Rīki ievēro minimālo privilēģiju principu un pieņem tikai validētus parametrus.
• Riskantām darbībām ir nepieciešams izsekojams apstiprinājums.
• Modeļa izvades tiek pārbaudītas pirms HTML, API, CRM vai citām mērķa sistēmām.
• Drošības filtri tiek vērtēti pēc kļūdaini pozitīvajiem (False Positives) un kļūdaini negatīvajiem (False Negatives) rādītājiem.
• Tiešie un netiešie uzbrukumu testi tiek veikti regulāri un pēc izmaiņām.

Secinājums

Prompt injection nav tikai promptu inženierijas problēma. Tīmekļa vietņu čatbotiem uzticama aizsardzība rodas tikai tad, ja lietotne apstrādā ievades, avotus, izvades un darbības kā nošķirtas uzticības zonas. Filtri var atpazīt uzbrukumus, taču minimālās privilēģijas, deterministiska validācija un cilvēka apstiprinājums ierobežo to iespējamo ietekmi.

Sāciet ar sava čatbota funkciju un datu karti. Noņemiet nevajadzīgās tiesības, izolējiet RAG saturu un pārbaudiet pilno ceļu līdz ārējai darbībai. Tādējādi čatbots paliks noderīgs, nepieļaujot, ka brīvais modeļa teksts pieņem lēmumus par atļaujām vai biznesam kritiskām izmaiņām.

Avoti

• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• OWASP GenAI Security Project: LLM07:2025 System Prompt Leakage
• OWASP GenAI Security Project: LLM05:2025 Improper Output Handling
• NIST: Generative Artificial Intelligence Profile (NIST AI 600-1)
• Microsoft Learn: Defend against indirect prompt injection attacks
• Microsoft Learn: Prompt Shields in Azure AI Content Safety
• Google AI for Developers: Safety and factuality guidance