„Prompt Injection“ svetainės pokalbių robotuose: RAG, įrankių ir duomenų apsauga

Svetainės pokalbių robotas tvarko ne tik nekenksmingus klausimus. Lankytojai gali bandyti perrašyti jo taisykles, atskleisti vidines instrukcijas arba inicijuoti neleistinus veiksmus. Dar sunkiau pastebimos komandos, kurios yra ne pačiame pokalbyje, o paslėptos nuskaitytame tinklalapyje, įkeltame dokumente ar prijungtoje trečiosios šalies sistemoje.

Norintys apriboti „prompt injection“ svetainių pokalbių robotuose negali pasikliauti vien tik griežtai suformuluota sistemine užklausa („system prompt“). Reikalinga daugiasluoksnė architektūra: įvestys ir šaltiniai laikomi nepatikimais, teisės techniškai apribojamos, išvestys tikrinamos prieš tolesnį apdorojimą, o rizikingus veiksmus patvirtina deterministinis kodas arba žmogus.

Ką reiškia „prompt injection“ svetainės pokalbių robote

OWASP apibūdina „prompt injection“ kaip įvestį, kuri nenumatytai pakeičia kalbos modelio elgseną arba išvestį. Tiesioginė „prompt injection“ pateikiama tiesiogiai vartotojo, pavyzdžiui, kaip prašymas nepaisyti ankstesnių taisyklių. Netiesioginė „prompt injection“ slypi išoriniame turinyje, kurį sistema gauna vėliau: tinklalapiuose, žinių dokumentuose, el. laiškuose, produktų duomenyse ar failuose.

Šis skirtumas yra svarbus svetainių savininkams. Paprastas DUK pokalbių robotas turi mažesnį atakos plotą nei sistema, kuri nuolat nuskaito tinklalapius, ieško vidiniuose dokumentuose, skaito CRM duomenis ar gali vykdyti funkcijas. Papildytosios paieškos generavimas (angl. Retrieval-Augmented Generation, RAG) pagerina atsakymų turinį, tačiau nepanaikina injekcijos rizikos. Net ir gerai prižiūrimame šaltinių rinkinyje gali būti manipuliuotų ar klaidingai suprastų instrukcijų.

Vertinkite riziką pagal funkcijas, o ne pagal modelio pavadinimą

Svarbiausias klausimas yra ne tik „Kokį modelį naudojame?“, bet ir „Kokį poveikį gali turėti manipuliuotas atsakymas?“. Sudarykite paprastą pokalbių roboto funkcijų ir duomenų žemėlapį:

• Kuriuos viešus ir vidinius šaltinius jis gali skaityti?
• Kokie asmens, konfidencialūs ar verslui kritiniai duomenys yra pasiekiami?
• Ar jis gali tik generuoti tekstą, ar taip pat kurti užklausų bilietus („tickets“), potencialius klientus („leads“), el. laiškus, susitikimus ar užsakymus?
• Kokie veiksmai keičia išorines sistemas?
• Kokie sprendimai priimami automatiškai, neatliekant patikrinimo žmogui?

Kuo didesnės skaitymo, rašymo teisės ir automatizavimo laipsnis, tuo svarbesnės tampa techninės ribos už modelio ribų. Esama apžvalga apie dažnas dirbtinio intelekto pokalbių robotų klaidas padeda atlikti bendrą inventorizaciją. Dėl „prompt injection“ papildomai turite dokumentuoti duomenų srautus, pasitikėjimo ribas ir veiksmų teises.

Aiškliai atskirkite keturias pasitikėjimo zonas

Praktiškas saugumo modelis skiria keturias zonas, net jei techniškai jos apdorojamos toje pačioje programoje.

1 zona: Sisteminės taisyklės ir gairės

Čia nustatomas vaidmuo, leidžiamas tikslas, atsakymų ribos ir eskalavimo taisyklės. Šios taisyklės nukreipia modelį, tačiau nėra patikima prieigos kontrolė. OWASP aiškiai įspėja nesielgti su sisteminėmis užklausomis („system prompts“) kaip su paslaptimi ar saugumo mechanizmu. Prisijungimo duomenys, ryšio raktai ir jautri vidinė informacija čia neturėtų patekti.

2 zona: Lankytojų įvestys

Kiekviena pokalbio žinutė yra nepatikima. Apribokite ilgį, failų tipus ir leidžiamas funkcijas; normalizuokite įvestis techniniam apdorojimui ir užklausoje aiškiai pažymėkite jas kaip vartotojo duomenis. Filtrai gali atpažinti žinomus atakos modelius, tačiau neturėtų aklai blokuoti teisėtų klausimų. Lankytojas, kuris saugumo dokumentacijoje ieško frazės „ignore previous instructions“, gali turėti teisėtą užklausą.

3 zona: Gauti šaltiniai ir RAG kontekstas

Nuskaitytas turinys, PDF failai ir išorinių paslaugų rezultatai taip pat išlieka duomenimis, o ne instrukcijomis. Matomai atskirkite jų turinį nuo valdymo konteksto, išsaugokite kilmę bei gavimo laiką ir leiskite naudoti tik patvirtintus šaltinius. Straipsnis apie DI pokalbių roboto žinių bazės atnaujinimą parodo, kaip sąveikauja šaltinių inventorius, nuskaitymo dažnumas ir kokybės užtikrinimas (QA).

4 zona: Įrankiai, veiksmai ir išvestys

Funkcijų iškvietimai neturi būti vykdomi vien todėl, kad modelis sugeneravo tinkamą tekstą. Deterministinis valdiklis tikrina funkcijos pavadinimą, parametrus, teises, seanso kontekstą ir leidžiamas tikslines sistemas. Modelio išvestims, kurios vėliau naudojamos kaip HTML, „Markdown“, SQL, failo kelias ar API parametrai, reikalingas atitinkamas kontekstinis tikrinimas ir kodavimas.

Mažiausių privilegijų principas sumažina poveikį

Šių dienų duomenimis, „prompt injection“ neįmanoma patikimai išvengti viena priemone. Todėl programa turi būti sukurta taip, kad sėkmingas manipuliavimo bandymas padarytų kuo mažiau žalos. OWASP ir „Microsoft“ tam rekomenduoja mažiausių privilegijų principą (angl. Least Privilege).

• Naudokite atskiras technines tapatybes skaitymui ir rašymui.
• Suteikite prieigą tik prie tų duomenų, kurie būtini konkrečiam pokalbių roboto tikslui.
• Apribokite funkcijas iki mažų, aiškiai apibrėžtų parametrų schemų.
• Naudokite trumpalaikes teises, jei veiksmui jų apskritai reikia.
• Reikalaukite aiškaus patvirtinimo rizikingiems ar negrįžtamiems veiksmams.
• Niekada nepatikėkite autorizavimo laisvam modelio tekstui.

Pavyzdžiui, palaikymo pokalbių robotas gali paruošti užklausos juodraštį, tačiau neturėtų automatiškai nustatyti bet kokių gavėjų, prioritetų ar vidinių prieigos teisių. Potencialių klientų robotas gali priimti struktūrizuotus kontaktinius duomenis, negaudamas skaitymo teisių į visą CRM sistemą.

Patikrinkite ir izoliuokite RAG šaltinius

Netiesioginė „prompt injection“ paverčia šaltinių grandinę saugumo architektūros dalimi. Manipuliuotas puslapis gali atrodyti nekenksmingas, tačiau jame gali būti teksto, kurį modelis interpretuoja kaip instrukciją. Multimodalinėse sistemose vaidmenį gali atlikti ir vaizdai ar kiti failų formatai.

Todėl įdiekite šaltinių įvestį su patvirtinimo taisyklėmis: leidžiami domenai ir dokumentų sritys, atsekami savininkai, versijavimas, kenkėjiškos programinės įrangos ir failų patikra bei naujo ar neįprastai pasikeitusio turinio peržiūra. Gautas ištraukas modelio kontekste aiškiai pažymėkite kaip nepatikimą turinį (angl. untrusted content). Paieškos rezultatas gali suteikti informacijos, tačiau negali keisti sisteminių taisyklių ar įrankių teisių.

Be to, patikrinkite, ar atsakymas tikrai pagrįstas šaltiniais. Vadovas apie DI pokalbių roboto atsakymų kokybės matavimą naudojant „Golden Set“ ir RAG testus aprašo atitikimą šaltiniams ir jų sutikrinimą. Ši kokybės patikra papildo saugumo kontrolę, tačiau jos nepakeičia.

Įvesties ir išvesties filtrai yra tik vienas sluoksnis, o ne visas sprendimas

Specializuotos apsaugos paslaugos gali atpažinti tiesioginius ir netiesioginius atakos bandymus. Pavyzdžiui, „Microsoft Prompt Shields“ atskiria atakas vartotojų įvestyse nuo paslėptų instrukcijų dokumentuose. „Google“ savo saugumo gairėse taip pat rekomenduoja apsaugos priemones nuo „prompt injection“, siauriau apibrėžtas užduotis, vartotojų identifikatorius, kiekio ribojimus ir žmogaus priežiūrą esant didesnei rizikai.

Tokie filtrai teikia tikimybiškus signalus. Todėl numatykite pakopinį elgesį: blokuoti, atsakyti saugiai, pereiti prie griežtai apriboto režimo arba perduoti žmogui. Registruokite sprendimo klasę ir techninę versiją, tačiau venkite nereikalingo viso teksto išsaugojimo. Asmens duomenims papildomai taikomos sritys, aprašytos straipsnyje apie DI pokalbių robotus ir BDAR. Šis straipsnis nėra teisinė konsultacija.

Patikrinkite modelio išvestis prieš tolesnį apdorojimą

Saugi įvestis negarantuoja saugios išvesties. OWASP nurodo netinkamą išvesties apdorojimą kaip atskirą riziką: modelio tekstas vėliau gali patekti į HTML, skriptus, duomenų bazių užklausas ar failų kelius. Todėl su kiekviena modelio išvestimi iš pradžių elkitės kaip su nepatikima.

Automatiniams procesams reikalaukite griežtai struktūrizuoto formato ir tikrinkite jį pagal schemą. Naudokite leidžiamų funkcijų pavadinimų ir tikslinių sistemų sąrašus (angl. allowlists). Užkoduokite matomą tekstą atitinkamam išvesties kontekstui. Atmeskite netikėtus laukus, išorines URL nuorodas ir parametrus, viršijančius leidžiamas reikšmes. Jautrūs duomenys prieš rodymą ar perdavimą turėtų dar kartą pereiti specialią taisyklių patikrą.

Išbandykite „prompt injection“ naudodami saugumo testų rinkinį

Papildykite gamybinį „Golden Set“ priešpriešiniais (angl. adversarial) testais. Testai turi patikrinti faktinę gamybinę sistemą, įskaitant informacijos paiešką, įrankius ir teisių logiką, o ne tik bazinį modelį. Naudingą rinkinį sudaro:

• tiesioginiai bandymai pakeisti taisykles arba gauti vidines instrukcijas;
• daugiakalbiai, užkoduoti ir per kelias žinutes išskirstyti variantai;
• nekenksmingi profesiniai klausimai, kuriuose yra panašių raktažodžių ir kurie neturi būti klaidingai užblokuoti;
• manipuliuotos ištraukos bandomajame žinių šaltinyje;
• neleistini funkcijų pavadinimai, papildomi parametrai ir svetimi tiksliniai adresai;
• bandymai gauti konfidencialius duomenis arba ankstesnių seansų turinį;
• HTML, „Markdown“ ir nuorodų išvesčių testai;
• atšaukimo, perdavimo žmogui ir patvirtinimo keliai atliekant rizikingus veiksmus.

Matuokite ne tik tai, ar filtras suveikė. Patikrinkite galutinį rezultatą: ar buvo užkirstas kelias neleistinam veiksmui? Ar konfidencialūs duomenys liko apsaugoti? Ar teisėta užklausa veikė toliau? Ar įtartinas atvejis buvo aiškiai užregistruotas žurnale?

Praktinis įgyvendinimo planas svetainių komandoms

1. Aprepti apimtį: dokumentuoti duomenų šaltinius, įrankius, rašymo teises ir išorinius tikslus.
2. Atskirti pasitikėjimo zonas: techniškai paženklinti sistemines taisykles, vartotojo įvestis, RAG turinį ir veiksmų išvestis.
3. Sumažinti teises: pašalinti nenaudojamas prieigas ir išskaidyti rašymo veiksmus į mažas funkcijas.
4. Papildyti tikrinimą: įdiegti įvesties ribas, struktūrizuotas išvestis, leidžiamų sąrašus ir kontekstui būdingą kodavimą.
5. Nustatyti patvirtinimą: apsaugoti rizikingus veiksmus ir jautrių duomenų srautus pasitelkiant žmogaus įtraukimą („Human-in-the-Loop“).
6. Vykdyti testų rinkinį: prieš kiekvieną svarbų leidimą patikrinti tiesioginius, netiesioginius ir teisėtus kontrolinius atvejus.
7. Stebėti veiklą: reguliariai peržiūrėti filtrų įvykius, atmestus veiksmus, neįprastus šaltinių pakeitimus ir klaidingus pavojaus signalus.

Kontrolinis sąrašas: Apsauga nuo „prompt injection“

• Sisteminėje užklausoje („system prompt“) nėra slaptų duomenų ir ji nepakeičia autorizacijos.
• Vartotojų tekstai ir išoriniai šaltiniai pagal nutylėjimą laikomi nepatikimais.
• RAG šaltiniai turi patvirtinimą, kilmę, versiją ir atsakingus savininkus.
• Įrankiai laikosi mažiausių privilegijų principo ir priima tik patikrintus parametrus.
• Rizikingiems veiksmams reikalingas atsekamas patvirtinimas.
• Modelio išvestys patikrinamos prieš pateikiant į HTML, API, CRM ar kitas tikslines sistemas.
• Saugumo filtrai vertinami pagal klaidingai teigiamus („False Positives“) ir klaidingai neigiamus („False Negatives“) rezultatus.
• Tiesioginių ir netiesioginių atakų testai atliekami reguliariai ir po pakeitimų.

Išvada

„Prompt injection“ nėra vien tik užklausų inžinerijos („prompt engineering“) problema. Svetainės pokalbių robotams patikima apsauga sukuriama tik tada, kai programa įvestis, šaltinius, išvestis ir veiksmus traktuoja kaip atskiras pasitikėjimo zonas. Filtrai gali atpažinti atakas, tačiau mažiausių privilegijų principas, deterministinis tikrinimas ir žmogaus patvirtinimas apriboja galimą jų poveikį.

Pradėkite nuo savo pokalbių roboto funkcijų ir duomenų žemėlapio. Pašalinkite nereikalingas teises, izoliuokite RAG turinį ir išbandykite visą kelią iki išorinio veiksmo. Taip pokalbių robotas išliks naudingas, o laisvas modelio tekstas nespręs dėl teisių ar verslui kritinių pakeitimų.

Šaltiniai

• 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