Prompt injection pri spletnih klepetalnikih: Zaščita za RAG, orodja in podatke

Spletni klepetalnik ne obdeluje le neškodljivih vprašanj. Obiskovalci lahko poskušajo prepisati njegova pravila, razkriti notranja navodila ali sprožiti nedovoljena dejanja. Še težje je prepoznati ukaze, ki niso zapisani neposredno v klepetu, temveč so skriti na preiskani spletni strani, v naloženem dokumentu ali povezanem sistemu tretje osebe.

Kdor želi omejiti prompt injection pri spletnih klepetalnikih, se ne sme zanašati le na posebej strogo oblikovan sistemski poziv. Potrebna je večplastna arhitektura: vnosi in viri se obravnavajo kot nezaupanja vredni, dovoljenja so tehnično omejena, izhodi se pred nadaljnjo obdelavo preverijo, tvegana dejanja pa potrdi deterministična koda ali človek.

Kaj pomeni prompt injection pri spletnem klepetalniku

OWASP opisuje prompt injection kot vnos, ki nepredvideno spremeni vedenje ali izhod jezikovnega modela. Neposredni prompt injection prihaja neposredno od uporabnika, na primer kot zahteva po prezrtju prejšnjih pravil. Posredni prompt injection pa se skriva v zunanjih vsebina, ki jih sistem pridobi pozneje: na spletnih straneh, v dokumentih znanja, e-pošti, podatkih o izdelkih ali datotekah.

Ta razlika je pomembna za upravljavce spletnih mest. Klepetalnik, namenjen zgolj pogostim vprašanjem (FAQ), ima manjšo napadalno površino kot sistem, ki tekoče indeksira spletne strani, išče po internih dokumentih, bere podatke iz CRM ali lahko izvaja funkcije. Retrieval-Augmented Generation (RAG) sicer izboljšuje strokovno podlago odgovorov, vendar ne odpravlja tveganja injection. Tudi dobro vzdrževan nabor virov lahko vsebuje manipulirana ali napačno razumljena navodila.

Ocenjevanje tveganja po funkcijah namesto po imenu modela

Ključno vprašanje ni le: »Kateri model uporabljamo?«, temvech: »Kakšen učinek lahko ima manipuliran odgovor?« Ustvarite preprosto karto funkcij in podatkov za klepetalnik:

• Katere javne in interne vire sme brati?
• Kateri osebni, zaupni ali poslovno kritični podatki so dosegljivi?
• Ali lahko ustvarja le besedilo ali lahko ustvarja tudi zahtevke, kontakte, e-pošto, termine ali naročila?
• Katera dejanja spreminjajo zunanje sisteme?
• Katere odločitve se sprejmejo samodejno, brez preverjanja s strani človeka?

Večje kot so pravice do branja, pravice do pisanja in stopnja avtomatizacije, pomembnejše so tehnične meje zunaj modela. Obstoječi pregled pogostih napak pri AI klepetalnikih pomaga pri splošnem popisu. Za prompt injection morate dodatno dokumentirati podatkovne tokove, meje zaupanja in pravice do izvajanja dejanj.

Jasno ločevanje štirih območij zaupanja

Praktični varnostni model razlikuje štiri območja, tudi če se tehnično obdelujejo v isti aplikaciji.

Območje 1: Sistemska pravila in smernice

Tukaj so opredeljeni vloga, dovoljeni namen, meje odgovarjanja in pravila za eskalacijo. Ta pravila dajejo modelu usmeritev, vendar niso zanesljiv nadzor dostopa. OWASP izrecno opozarja pred obravnavo sistemskih pozivov (system prompts) kot skrivnosti ali varnostnega mehanizma. Dostopni podatki, povezovalni ključi in občutljive interne informacije tja ne sodijo.

Območje 2: Vnosi obiskovalcev

Vsako sporočilo v klepetu je nezanesljivo. Omejite dolžino, vrste datotek in dovoljene funkcije; normalizirajte vnose za tehnično obdelavo in jih v pozivu jasno označite kot uporabniške podatke. Filter lahko prepozna znane vzorce napadov, vendar ne sme pavšalno blokirati legitimnih vprašanj. Obiskovalec, ki v varnostni dokumentaciji sprašuje po »ignore previous instructions«, ima morda upravičen interes.

Območje 3: Pridobljeni viri in kontekst RAG

Tudi indeksirane vsebine, datoteke PDF in rezultati zunanjih storitev ostajajo podatki, ne navodila. Njihovo vsebino vidno ločite od nadzornega konteksta, shranite izvor in čas pridobitve ter dovolite le odobrene vire. Prispevek o posodabljanju baze znanja AI klepetalnika prikazuje, kako medsebojno delujejo popis virov, pogostost indeksiranja in zagotavljanje kakovosti.

Območje 4: Orodja, dejanja in izhodi

Klici funkcij se ne smejo izvesti zgolj zato, ker je model ustvaril ustrezno besedilo. Deterministični krmilnik preveri ime funkcije, parametre, pooblastila, kontekst seje in dovoljene ciljne sisteme. Izhodi modela, ki se pozneje uporabijo kot HTML, Markdown, SQL, pot do datoteke ali parametri API, potrebujejo ustrezno validacijo in kodiranje za ta kontekst.

Načelo najmanjših pravic omejuje posledice

Glede na trenutno stanje napadov prompt injection ni mogoče zanesljivo preprečiti z enim samim ukrepom. Zato mora biti aplikacija zgrajena tako, da ima uspešen poskus manipulacije čim manjši učinek. OWASP in Microsoft za to priporočata načelo najmanjših pravic (Least Privilege).

• Uporabite ločene tehnične identitete za branje in pisanje.
• Dodelite dostop le do tistih podatkov, ki so nujni za konkreten namen klepetalnika.
• Omejite funkcije na majhne, jasno definirane sheme parametrov.
• Uporabite kratkotrajna pooblastila, če dejanje sploh potrebuje pooblastilo.
• Zahtevajte izrecno potrditev za tvegane ali nepopravljive korake.
• Nikoli ne prepustite avtorizacije prosto oblikovanemu besedilu modela.

Podporni klepetalnik lahko na primer pripravi osnutek zahtevka, vendar ne bi smel samodejno določati poljubnih prejemnikov, prioritet ali internih pravic dostopa. Klepetalnik za zbiranje kontaktov lahko sprejme strukturirane kontaktne podatke, ne da bi s tem pridobil pravice branja celotnega sistema CRM.

Preverjanje in izolacija virov RAG

Posredni prompt injection spremeni cevovod virov v del varnostne arhitekture. Manipulirana stran je lahko na videz neškodljiva, pa vendar vsebuje besedilo, ki ga model razlaga kot navodilo. Pri multimodalnih sistemih lahko vlogo igrajo tudi slike ali drugi formati datotek.

Zato uvedite vstopno točko za vire s pravili odobritve: dovoljene domene in območja dokumentov, sledljivi lastniki, različice, preverjanje zlonamerne kode in datotek ter pregled novih ali nenavadno spremenjenih vsebin. Izseke, pridobljene v kontekstu modela, izrecno označite kot nezanesljivo vsebino (untrusted content). Zadetek iz iskanja lahko ponudi informacije, ne sme pa spreminjati sistemskih pravil ali pravic orodij.

Poleg tega preverite, ali je odgovor res podprt z viri. Vodnik o merjenju kakovosti odgovorov AI klepetalnikov z naborom Golden Set in testi RAG opisuje utemeljenost (groundedness) in primerjavo virov. Ta preverjanje kakovosti dopolnjuje varnostne nadzore, vendar jih ne nadomešča.

Vhodni in izhodni filtri so le en sloj, ne celotna rešitev

Specializirane zaščitne storitve lahko prepoznajo poskuse neposrednih in posrednih napadov. Microsoft Prompt Shields na primer razlikuje napade v vnosi uporabnikov od skritih navodil v dokumentih. Google v svojih varnostnih smernicah prav tako priporoča zaščitne ukrepe pred prompt injection, ožje opredeljene naloge, identifikatorje uporabnikov, omejitve količine in človeški nadzor pri višjem tveganju.

Takšni filtri zagotavljajo verjetnostne signale. Zato načrtujte stopnjevano vedenje: blokiranje, varen odgovor, preklop na strogo omejen način ali predaja človeku. Beležite razred odločitve in tehnično različico, vendar se izogibajte nepotrebnemu shranjevanju celotnega besedila. Pri osebnih podatkih veljajo tudi področja preverjanja, opisana v prispevku o AI klepetalnikih in Splošni uredbi o varstvu podatkov (GDPR). Ta članek ne predstavlja pravnega svetovanja.

Validacija izhodov modela pred nadaljnjo obdelavo

Varen vnos ne zagotavlja varnega izhoda. OWASP navaja neustrezno ravnanje z izhodi kot samostojno tveganje: besedilo modela lahko pozneje konča v HTML, skriptih, poizvedbah SQL ali poteh datotek. Zato tudi vsak izhod modela najprej obravnavajte kot nezanesljiv.

Za samodejne procese zahtevajte strogo strukturiran format in ga validirajte glede na shemo. Uporabite bele sezname (whitelists) za imena funkcij in ciljne sisteme. Kodirajte vidno besedilo za posamezni izhodni kontekst. Zavrzite nepričakovana polja, zunanje URL-je in parametre zunaj dovoljenih vrednosti. Občutljivi podatki morajo pred prikazom ali prenosom ponovno skozi lastno preverjanje smernic.

Preverjanje prompt injection s varnostnim testnim nizom

Strokovni nabor Golden Set dopolnite z napadalnimi (adversarial) testnimi primeri. Testi morajo preverjati dejanski produkcijski sistem, vključno s pridobivanjem podatkov, orodji in logiko pooblastil, ne le osnovnega modela. Koristen niz vsebuje:

• neposredne poskuse zamenjave pravil ali poizvedovanja po internih navodilih;
• večjezične, kodirane in čez več sporočil porazdeljene različice;
• neškodljiva strokovna vprašanja, ki vsebujejo podobne ključne besede in ne smejo biti lažno blokirana;
• manipulirane izseke v testnem viru znanja;
• nedovoljena imena funkcij, dodatne parametre in tuje ciljne naslove;
• poskuse izpisa zaupnih podatkov ali vsebine prejšnjih sej;
• teste za izhode HTML, Markdown in povezav;
• poti prekinitve, predaje (handoff) in potrditve pri tveganih dejanjih.

Ne merite le, ali se filter sproži. Preverite končni rezultat: Ali je bilo nedovoljeno dejanje preprečeno? Ali so zaupni podatki ostali zaščiteni? Ali je legitimna poizvedba še naprej delovala? Ali je bil sumljiv primer sledljivo zabeležen?

Praktični načrt uvedbe za spletne ekipe

1. Zajem obsega: dokumentirajte podatkovne vire, orodja, pravice pisanja in zunanje cilje.
2. Ločitev območij zaupanja: tehnično označite sistemska pravila, vnose uporabnikov, vsebine RAG in izhode dejanj.
3. Zmanjšanje pravic: odstranite neuporabljene dostope in razdelite dejanja pisanja na majhne funkcije.
4. Dodajanje validacije: uvedite meje vnosov, strukturirane izhode, bele sezname in kodiranje, prilagojeno kontekstu.
5. Določitev potrditev: zavarujte tvegana dejanja in občutljive podatkovne tokove s pristopom človek v zanki (Human-in-the-Loop).
6. Izvajanje testnega niza: pred vsako pomembno izdajo preverite neposredne, posredne in legitimne kontrolne primere.
7. Spremljanje delovanja: redno pregledujte dogodke filtrov, zavrnjena dejanja, nenavadne spremembe virov in lažne alarme.

Kontrolni seznam: Zaščita pred prompt injection

• Sistemski poziv ne vsebuje skrivnosti in ne nadomešča avtorizacije.
• Uporabniška besedila in zunanji viri privzeto veljajo za nezanesljive.
• Viri RAG imajo odobritev, izvor, različico in odgovorne lastnike.
• Orodja sledijo načelu najmanjših pravic (Least Privilege) in sprejemajo le validirane parametre.
• Tvegana dejanja zahtevajo sledljivo potrditev.
• Izhodi modela se preverijo pred posredovanjem v HTML, API, CRM ali druge ciljne sisteme.
• Varnostni filtri se ocenjujejo glede na lažno pozitivne (false positives) in lažno negativne (false negatives) izide.
• Testi neposrednih in posrednih napadov potekajo redno in po vsaki spremembi.

Zaključek

Prompt injection ni le problem inženiringa pozivov (prompt engineering). Za spletne klepetalnike nastane vzdržljiva zaščita šele, ko aplikacija obravnava vnose, vire, izhode in dejanja kot ločena območja zaupanja. Filtri lahko prepoznajo napade, vendar načelo najmanjših pravic, deterministična validacija in potrditev s strani človeka omejujejo njihov možni učinek.

Začnite s karto funkcij in podatkov vašega klepetalnika. Odstranite nepotrebne pravice, izolirajte vsebine RAG in testirajte celotno pot do zunanjega dejanja. Tako ostane klepetalnik koristen, ne da bi prosto besedilo modela odločalo o pravicah ali poslovno kritičnih spremembah.

Viri

• 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