Prompt Injection kod chatbotova na web stranicama: Zaštita za RAG, alate i podatke

Chatbot na web stranici ne obrađuje samo bezazlena pitanja. Posjetitelji mogu pokušati prepisati njegova pravila, otkriti interne upute ili pokrenuti nedopuštene radnje. Još je teže prepoznati naredbe koje se ne nalaze izravno u chatu, već su skrivene na prikupljenoj web stranici, u prenesenom dokumentu ili u povezanom sustavu treće strane.

Tko želi ograničiti prompt injection kod chatbotova na web stranicama, ne smije se oslanjati samo na posebno strogo formuliran system prompt. Potrebna je višeslojna arhitektura: ulazi i izvori tretiraju se kao nepouzdani, ovlasti se tehnički ograničavaju, izlazi se provjeravaju prije daljnje obrade, a rizične radnje potvrđuje deterministički kod ili čovjek.

Što znači prompt injection kod chatbotova na web stranicama

OWASP opisuje prompt injection kao unos koji nenamjerno mijenja ponašanje ili izlaz jezičnog modela. Izravni prompt injection dolazi izravno od korisnika, na primjer kao zahtjev za ignoriranjem prethodnih pravila. Neizravni prompt injection nalazi se, s druge strane, u vanjskom sadržaju koji sustav kasnije dohvaća: web stranicama, dokumentima znanja, e-porukama, podacima o proizvodima ili datotekama.

Ova je razlika važna za vlasnike web stranica. Čisti FAQ chatbot ima manju površinu napada od sustava koji kontinuirano prikuplja web stranice, pretražuje interne dokumente, čita CRM podatke ili može izvršavati funkcije. Retrieval-Augmented Generation, skraćeno RAG, doduše poboljšava stručnu osnovu odgovora, ali ne uklanja rizik od injectiona. Čak i dobro održavana baza izvora može sadržavati manipulirane ili pogrešno shvaćene upute.

Procjena rizika prema funkcijama umjesto prema nazivu modela

Ključno pitanje ne glasi samo: „Koji model upotrebljavamo?“, nego: „Kakav učinak može imati manipulirani odgovor?“ Izradite jednostavnu kartu funkcija i podataka za chatbot:

• Koje javne i interne izvore smije čitati?
• Koji su osobni, povjerljivi ili poslovno kritični podaci dostupni?
• Može li samo stvarati tekst ili i otvarati tikete, voditi prilike (leads), slati e-poruke, zakazivati sastanke ili stvarati narudžbe?
• Koje radnje mijenjaju vanjske sustave?
• Koje se odluke preuzimaju automatski, a da ih čovjek ne provjeri?

Što su veća prava čitanja, prava pisanja i stupanj automatizacije, to su važnije tehničke granice izvan samog modela. Postojeći pregled čestih pogrešaka kod AI chatbotova pomaže pri općem inventaru. Za prompt injection morate dodatno dokumentirati tokove podataka, granice povjerenja i prava na radnje.

Jasno odvajanje četiriju zona povjerenja

Praktični sigurnosni model razlikuje četiri zone, čak i ako se tehnički obrađuju unutar iste aplikacije.

Zona 1: Sustavna pravila i smjernice

Ovdje se nalaze uloga, dopuštena svrha, granice odgovora i pravila eskalacije. Ova pravila daju modelu usmjerenje, ali nisu pouzdana kontrola pristupa. OWASP izričito upozorava da se system prompt ne tretira kao tajna ili sigurnosni mehanizam. Pristupni podaci, ključevi za povezivanje i osjetljive interne informacije tu ne pripadaju.

Zona 2: Unosi posjetitelja

Svaka poruka u chatu smatra se nepouzdanom. Ograničite duljinu, vrste datoteka i dopuštene funkcije; normalizirajte unose za tehničku obradu i jasno ih u promptu označite kao korisničke podatke. Filtar može prepoznati poznate obrasce napada, ali ne smije paušalno blokirati legitimna pitanja. Posjetitelj koji u sigurnosnoj dokumentaciji pita za „ignore previous instructions“ možda ima opravdan upit.

Zona 3: Dohvaćeni izvori i RAG kontekst

I prikupljeni sadržaji, PDF-ovi i rezultati vanjskih usluga ostaju podaci, a ne upute. Vidljivo odvojite njihov sadržaj od upravljačkog konteksta, spremite podrijetlo i vrijeme dohvaćanja te dopustite samo odobrene izvore. Članak o održavanju baze znanja AI chatbotova ažurnom pokazuje kako inventar izvora, učestalost prikupljanja (crawl) i QA djeluju zajedno.

Zona 4: Alati, radnje i izlazi

Pozivi funkcija ne smiju se izvršiti samo zato što model generira odgovarajući tekst. Deterministički kontroler provjerava naziv funkcije, parametre, ovlasti, kontekst sesije i dopuštene ciljne sustave. Izlazi modela koji se kasnije upotrebljavaju kao HTML, Markdown, SQL, putanja datoteke ili API parametar trebaju validaciju i kodiranje prilagođeno tom kontekstu.

Načelo najmanjih privilegija (Least Privilege) ograničava utjecaj

Prema trenutnom stanju tehnologije, prompt injection ne može se pouzdano isključiti samo jednom mjerom. Stoga aplikacija mora biti napravljena tako da uspješan pokušaj manipulacije ima što manji učinak. OWASP i Microsoft za to preporučuju načelo najmanjih privilegija (Least Privilege).

• Upotrebljavajte odvojene tehničke identitete za čitanje i pisanje.
• Dajte pristup samo onim podacima koji su potrebni za konkretnu svrhu chatbots.
• Ograničite funkcije na male, jasno definirane sheme parametara.
• Koristite kratkotrajne ovlasti ako ih određena radnja uopće zahtijeva.
• Zahtijevajte izričitu potvrdu za rizične ili nepovratne korake.
• Nikada ne prepuštajte autorizaciju slobodnom tekstu modela.

Podršci namijenjen chatbot može, primjerice, pripremiti nacrt tiketa, ali ne bi smio automatski određivati proizvoljne primatelje, prioritete ili interna prava pristupa. Chatbot za prikupljanje kontakata može preuzeti strukturirane kontaktne podatke bez dobivanja prava čitanja cjelokupnog CRM-a.

Provjera i izolacija RAG izvora

Neizravni prompt injection pretvara cjevovod izvora u dio sigurnosne arhitekture. Manipulirana stranica može vizualno izgledati bezazleno, a ipak sadržavati tekst koji model interpretira kao uputu. Kod višemodelnih (multimodalnih) sustava i slike ili drugi formati datoteka mogu igrati ulogu.

Stoga uvedite ulazni proces za izvore s pravilima odobravanja: dopuštene domene i područja dokumenata, sljedivi vlasnici, verzijanje, provjera zlonamjernog softvera i datoteka te pregled novih ili neobično izmijenjenih sadržaja. Izričito označite dohvaćene ulomke u kontekstu modela kao untrusted content. Rezultat pretrage smije pružati informacije, ali ne smije mijenjati pravila sustava ili ovlasti alata.

Osim toga, provjerite je li odgovor uistinu potkrijepljen izvorima. Vodič za mjerenje kvalitete odgovora AI chatbotova pomoću Golden Seta i RAG testova opisuje utemeljenost (groundedness) i usporedbu s izvorima. Ova provjera kvalitete dopunjuje sigurnosne kontrole, ali ih ne zamjenjuje.

Ulazni i izlazni filtri samo su jedan sloj, ne i cijelo rješenje

Specijalizirane zaštitne usluge mogu prepoznati izravne i neizravne pokušaje napada. Microsoft Prompt Shields, primjerice, razlikuje napade u korisničkim unosima od skrivenih uputa u dokumentima. Google u svojim sigurnosnim smjernicama također preporučuje mjere zaštite od prompt injectiona, uže definirane zadatke, identifikatore korisnika, ograničenja količine i ljudski nadzor pri većem riziku.

Takvi filtri pružaju probabilističke signale. Stoga planirajte stupnjevito ponašanje: blokirati, odgovoriti na siguran način, prijeći na strogo ograničeni način rada ili prenijeti na čovjeka. Bilježite klasu odluke i tehničku verziju, ali izbjegavajte nepotrebno pohranjivanje punog teksta. Za osobne podatke dodatno vrijede područja provjere opisana u članku o AI chatbotovima i GDPR-u. Ovaj članak ne predstavlja pravno savjetovanje.

Validacija izlaza modela prije daljnje obrade

Siguran unos ne jamči siguran izlaz. OWASP navodi nedovoljno rukovanje izlazom kao zaseban rizik: tekst modela kasnije može završiti u HTML-u, skriptama, upitima bazi podataka ili putanjama datoteka. Stoga i svaki izlaz modela najprije tretirajte kao nepouzdan.

Za automatizirane procese zatražite strogo strukturirani format i validirajte ga u odnosu na shemu. Upotrebljavajte popise dopuštenih vrijednosti (white lists) za nazive funkcija i ciljne sustave. Kodirajte vidljivi tekst za odgovarajući izlazni kontekst. Odbacite neočekivana polja, vanjske URL-ove i parametre izvan dopuštenih vrijednosti. Osjetljivi podaci trebali bi prije prikaza ili prijenosa proći još jednu posebnu provjeru usklađenosti s pravilima.

Testiranje prompt injectiona pomoću sigurnosnog skupa testova

Dopunite stručni Golden Set napadačkim (adversarijalnim) testnim slučajevima. Testovi moraju provjeravati stvarni produkcijski sustav uključujući dohvaćanje (retrieval), alate i logiku ovlasti, a ne samo osnovni model. Koristan skup sadrži:

• izravne pokušaje zamjene pravila ili dohvaćanja internih uputa;
• višejezične, kodirane i kroz više poruka raspoređene varijante;
• bezazlena stručna pitanja koja sadrže slične ključne riječi i ne smiju se pogrešno blokirati;
• manipulirane ulomke u testnom izvoru znanja;
• nedopuštene nazive funkcija, dodatne parametre i vanjske ciljne adrese;
• pokušaje ispisa povjerljivih podataka ili sadržaja prethodnih sesija;
• testove za HTML, Markdown i izlaze poveznica;
• puteve prekida, predaje čovjeku (handoff) i potvrde kod rizičnih radnji.

Nemojte mjeriti samo aktivira li se filtar. Provjerite konačni rezultat: Je li nedopuštena radnja spriječena? Jesu li povjerljivi podaci ostali zaštićeni? Je li legitiman upit i dalje funkcionirao? Je li sumnjivi slučaj sljedivo zabilježen u dnevniku?

Praktični plan uvođenja za timove web stranica

1. Utvrđivanje opsega: Dokumentirajte izvore podataka, alate, prava pisanja i vanjske ciljeve.
2. Odvajanje zona povjerenja: Tehnički označite sustavna pravila, korisničke unose, RAG sadržaje i izlaze radnji.
3. Smanjivanje prava: Uklonite neiskorištene pristupe i raščlanite radnje pisanja na male funkcije.
4. Dodavanje validacije: Uvedite ograničenja unosa, strukturirane izlaze, popise dopuštenih vrijednosti i kodiranje specifično za kontekst.
5. Definiranje potvrde: Osigurajte rizične radnje i osjetljive tokove podataka uz ljudski nadzor (Human-in-the-Loop).
6. Izvršavanje skupa testova: Provjerite izravne, neizravne i legitimne kontrolne slučajeve prije svakog relevantnog izdanja.
7. Praćenje rada: Redovito pregledavajte događaje filtara, odbijene radnje, neobične promjene izvora i lažne alarme.

Kontrolni popis: Zaštita od prompt injectiona

• System prompt ne sadrži tajne i ne zamjenjuje autorizaciju.
• Korisnički tekstovi i vanjski izvori zadano se smatraju nepouzdanima.
• RAG izvori imaju odobrenje, podrijetlo, verziju i odgovorne vlasnike.
• Alati slijede načelo najmanjih privilegija i prihvaćaju samo validirane parametre.
• Rizične radnje zahtijevaju sljedivu potvrdu.
• Izlazi modela provjeravaju se prije prosljeđivanja u HTML, API, CRM ili druge ciljne sustave.
• Sigurnosni filtri procjenjuju se s obzirom na lažno pozitivne i lažno negativne rezultate.
• Testovi izravnih i neizravnih napada izvode se redovito i nakon promjena.

Zaključak

Prompt injection nije čisto problem inženjerstva promptova (prompt engineering). Za chatbotove na web stranicama pouzdana zaštita nastaje tek kada aplikacija tretira unose, izvore, izlaze i radnje kao odvojene zone povjerenja. Filtri mogu prepoznati napade, no načelo najmanjih privilegija, deterministička validacija i ljudska potvrda ograničavaju njihov mogući utjecaj.

Započnite s kartom funkcija i podataka svojeg chatbots. Uklonite nepotrebna prava, izolirajte RAG sadržaje i testirajte cijeli put do vanjske radnje. Tako chatbot ostaje koristan bez toga da slobodni tekst modela odlučuje o ovlastima ili poslovno kritičnim promjenama.

Izvori

• 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