Sigurnost LLM i RAG aplikacija: što tvrtka mora znati

Sve više tvrtki ugrađuje velike jezične modele u svoje proizvode i interne alate. Najčešći oblik je RAG aplikacija, gdje model odgovara na pitanja koristeći dokumente i bazu znanja tvrtke, ali sve su brojnije i aplikacije koje model spajaju na alate, baze podataka i vanjske usluge. Takve aplikacije donose stvarnu vrijednost, no donose i napadnu površinu koja se ne ponaša kao klasični softver. Ulaz je prirodni jezik, izlaz je nedeterminističan, a model ne razlikuje uputu razvojnog tima od upute koju je upisao korisnik ili koju je pokupio iz nekog dokumenta. Stari obrasci obrane, koji se oslanjaju na predvidljiv ulaz i strogu shemu, ovdje ne pokrivaju nove rizike.

Za reguliranu hrvatsku tvrtku to nije akademsko pitanje. Ako LLM aplikacija ima pristup osobnim podacima, model ih može otkriti u odgovoru, što je obrada osobnih podataka u smislu GDPR-a i predmet nadzora AZOP-a. Ako aplikacija pokreće radnje u drugim sustavima, pogrešan ili zlonamjerno usmjeren izlaz postaje stvarni incident. Financijske institucije pod DORA-om (Uredba (EU) 2022/2554) i subjekti pod Zakonom o kibernetičkoj sigurnosti, kojim je u Hrvatskoj prenesena direktiva NIS2, takvu aplikaciju moraju tretirati kao dio svoje ICT okoline s pripadajućim upravljanjem rizikom. Ovaj tekst objašnjava glavne klase rizika LLM aplikacija, arhitekturu obrane i način na koji se takve aplikacije testiraju.

Ovo je dio našeg pregleda sigurnosti AI sustava. Procjenu i jačanje LLM aplikacija pružamo kroz sigurnost umjetne inteligencije. Povezani su i tekstovi o prompt injectionu, OWASP Top 10 za LLM aplikacije i sigurnosti AI agenata.

Zašto LLM aplikacija nije običan softver

Klasična aplikacija ima definiran ulaz i izlaz. Polje za broj prima broj, a obrazac odbija ono što ne pristaje shemi. LLM aplikacija prima slobodan tekst i generira slobodan tekst, pa napadač uputama u prirodnom jeziku može pokušati promijeniti ponašanje sustava. Granica između podataka i naredbi, koju u klasičnom softveru pažljivo čuvamo, ovdje praktički ne postoji jer model sve vidi kao jedan niz teksta.

Druga razlika je odsutnost ugrađenog pojma povjerljivosti. Model nema mehanizam koji bi rekao da neki podatak smije vidjeti, ali ne smije izgovoriti. Ako mu je podatak u kontekstu ili dohvatljiv kroz alat, može ga otkriti u odgovoru. Treća razlika je nedeterminizam. Isti ulaz ne daje uvijek isti izlaz, pa se obrana ne može svesti na popis zabranjenih unosa. Zaključak je jednostavan: sigurnost mora biti u tome što model smije dohvatiti i pokrenuti, a ne u tome kako ga molimo da se ponaša.

Glavne klase rizika

OWASP održava zaseban popis najvažnijih rizika LLM aplikacija, koji je dobra zajednička referenca za procjenu i testiranje.¹ Rizici se grubo dijele u šest klasa koje se u praksi često preklapaju.

Prompt injection ima dva oblika. Izravni dolazi od korisnika koji u svom unosu pokuša poništiti pravila. Neizravni je opasniji jer dolazi iz sadržaja koji model čita, primjerice iz dokumenta u bazi znanja, web stranice ili e-pošte, pa korisnik ni ne mora biti napadač. Nesigurno rukovanje izlazom je klasična ranjivost u novom ruhu: ako tekst modela ide ravno u SQL upit ili u HTML stranicu bez provjere, dobivate iste posljedice kao kod OWASP Top 10 ranjivosti web aplikacija.

Poseban rizik RAG sustava i pristupa podacima

RAG sustav odgovara koristeći dokumente koje mu tvrtka da, pa nosi dvije specifične opasnosti. Prva je kontrola pristupa. Ako sloj koji dohvaća dokumente ne provjerava tko ih smije vidjeti, korisnik može pitanjem doći do podataka za koje nema ovlasti, jer model rado spaja sve čemu ima pristup. Prava koja vrijede za korisnika u izvornom sustavu moraju vrijediti i za dohvat koji radi model u njegovo ime.

Druga opasnost je trovanje baze znanja. Ako u indeks uđe dokument sa skrivenim uputama, te upute mogu utjecati na buduće odgovore svih korisnika, čak i onih koji taj dokument nikad nisu otvorili. To je neizravni prompt injection na razini podataka. Zbog toga izvore koji pune bazu znanja treba tretirati kao dio napadne površine, a ne kao pouzdan unutarnji sadržaj. Više o mehanici napada pisali smo u tekstu o prompt injectionu.

Arhitektura obrane

Sigurnost LLM aplikacije gradi se u arhitekturi, ne u tekstu sistemskog prompta. Cilj nije da model nikad ne pogriješi, nego da pogreška ili zlonamjeran unos ne mogu doseći podatke i radnje izvan zadatka. Sljedeći koraci čine okosnicu obrane koju primjenjujemo u procjenama.

1. 01
   Validirajte i normalizirajte ulaz

   Ograničite duljinu i format unosa te jasno odvojite korisnički sadržaj od sistemskih uputa u strukturi zahtjeva, koliko to model dopušta.
2. 02
   Ograničite i provjerite izlaz

   Tretirajte izlaz modela kao nepouzdan unos. Escapirajte ga, validirajte prema shemi i nikad ga ne prosljeđujte ravno u SQL, HTML ili shell.
3. 03
   Primijenite najmanje ovlasti za dohvat

   Dohvat dokumenata i pozivanje alata smiju koristiti samo prava korisnika koji postavlja pitanje, nikad širi servisni račun.
4. 04
   Odvojite povjerljivi kontekst

   Ne stavljajte tajne, ključeve ni tuđe osobne podatke u kontekst modela ako zadatak to ne traži, jer sve u kontekstu može iscuriti.
5. 05
   Nadzirite i bilježite

   Bilježite upite, dohvaćene dokumente, pozive alata i odgovore te pratite sumnjive obrasce i pokušaje zaobilaženja.

Posebnu pažnju traže dodaci i alati. Svaki alat koji model smije pozvati širi je napadnu površinu, pa alat treba imati uske ovlasti, validirati svoje parametre i, kod osjetljivih radnji poput slanja podataka ili plaćanja, tražiti ljudsku potvrdu. Kad aplikacija prelazi iz odgovaranja u djelovanje, ulazi u domenu sigurnosti AI agenata, gdje su ovlasti i granice još važnije.

LLM aplikacija mora i klasično biti osigurana

Uz nove rizike, LLM aplikacija ostaje obična web aplikacija s pozadinom i API-jem, pa vrijede sve klasične kontrole. Treba snažnu autentifikaciju, po mogućnosti uz dvofaktorsku autentifikaciju, jasnu kontrolu pristupa po ulogama i zaštitu API-ja kojim aplikacija komunicira. Ograničavanje brzine zahtjeva sprječava zlouporabu i kontrolira trošak, jer je svaki poziv modela i financijska stavka.

Bez tih temelja napredne AI kontrole nemaju smisla. Nema koristi od pažljivog odvajanja konteksta ako napadač može doći do tuđeg računa zbog slabe autentifikacije, niti od provjere izlaza ako je API otvoren bez kontrole pristupa. LLM sloj se dodaje na zdravu aplikaciju, ne umjesto nje.

Sistemski prompt je smjernica ponašanja, a ne sigurnosna kontrola; prava obrana je u ovlastima i provjeri izlaza.

Kako se LLM aplikacija testira

Testiranje LLM aplikacije spaja klasičan i nov pristup. Klasično penetracijsko testiranje pokriva autentifikaciju, kontrolu pristupa, API i pozadinu, jer su to i dalje najčešća vrata za napadača. Na to se nadovezuje testiranje specifično za AI, gdje se ciljaju upravo nove klase rizika: pokušaji izravnog i neizravnog prompt injectiona, provjera curi li osjetljiv sadržaj, ispitivanje poštuje li dohvat prava korisnika i mogu li se alati zloupotrijebiti.

Najzreliji oblik je crveni tim za AI, gdje tim simulira stvarnog protivnika koji kombinira ove tehnike kroz više koraka, primjerice tako da kroz zatrovan dokument preusmjeri model pa onda iskoristi alat. Cilj nije skupiti popis pojedinačnih grešaka, nego pokazati može li napadač doseći stvarnu štetu. Za usporedbu pristupa korisni su tekstovi o vrstama penetracijskog testiranja i red teamingu. Po našem iskustvu opseg testiranja jako ovisi o tome ima li aplikacija pristup alatima i osjetljivim podacima, a stvarna procjena ovisi o opsegu sustava.

Veza s OWASP Top 10 za LLM

OWASP Top 10 za LLM aplikacije daje zajednički jezik za sve navedeno. Kategorije poput prompt injectiona, nesigurnog rukovanja izlazom, curenja osjetljivih podataka i prekomjerne agentnosti izravno odgovaraju klasama rizika iz ovog teksta.¹ Korištenje tog popisa kao polazne liste osigurava da procjena pokriva poznate slabosti, a ne samo one kojih se tim slučajno sjetio.

Popis se uklapa u širi okvir upravljanja rizikom. NIST-ov okvir za upravljanje rizicima umjetne inteligencije pomaže ugraditi AI rizike u postojeći sustav upravljanja, umjesto da se tretiraju kao izolirano tehničko pitanje.² Detaljan pregled svake kategorije dajemo u tekstu o OWASP Top 10 za LLM aplikacije, a o riziku neodobrenih alata u tekstu o shadow AI-ju.

Kako Raptoric pomaže

Procjenjujemo i testiramo LLM i RAG aplikacije te pomažemo postaviti arhitekturu u kojoj model ne može više nego što smije. Spajamo klasično penetracijsko testiranje s testiranjem specifičnim za AI i crvenim timom, kroz sigurnost umjetne inteligencije. Dogovorite uvodni razgovor.