LLM integracijų saugumas: kodėl vien apsaugos barjerų nepakanka

Pokalbių robotas, kuris tik performuluoja tekstą, – valdoma rizika. Vos tas pats robotas prijungiamas prie žinių bazės ir gauna teisę sukurti užklausą ar iškviesti API, jis nebėra pokalbių robotas, o naujas atakos paviršius su prieiga prie įmonės sistemų. Per pastaruosius dvejus metus šis šuolis įvyko beveik kiekvienoje organizacijoje, ir paprastai greičiau, nei jį spėjo pavyti LLM integracijų įsilaužimų testavimas.

Šiame straipsnyje surinktos atakos, kurios LLM integracijose pasitaiko praktikoje, priežastys, kodėl įprastos saugumo priemonės jų nepagauna, taip pat tai, ką AI ir LLM integracijų saugumo testavime tikriname ir ką organizacijai verta pasiruošti iš anksto.

Kodėl LLM aplikacijos testavimas – atskira disciplina

Įprastoje aplikacijoje riba aiški: kodas – nurodymas, įvestis – duomenys. SQL injekcija veikia kaip tik todėl, kad vienoje vietoje ši riba netyčia dingo, o parengtomis užklausomis (prepared statements) ją galima struktūriškai atkurti.

Kalbos modelyje tokios ribos iš principo nėra. Sisteminė instrukcija, naudotojo klausimas, iš indekso ištraukti dokumentai ir įrankių atsakymai patenka į vieną konteksto langą kaip vienas teksto srautas. Modelis juos sveria statistiškai, bet nė vienos taisyklės priverstinai neįgyvendina. Parengtos užklausos atitikmens čia nėra.

Iš to kyla vienas sakinys, apibendrinantis visą discipliną: kiekvienas į kontekstą patekęs tekstas – tai potenciali instrukcija. Įkeltas PDF, apdorotas laiškas, komentaras užklausoje, parsisiųstas tinklalapis, įrašas vektorinėje duomenų bazėje.

Atakos, kurios kartojasi praktikoje

Prompt injection

Tiesioginis variantas pažįstamas: naudotojas rašo „nepaisyk visų ankstesnių nurodymų“ ir tikrina formuluotę po formuluotės, kol viena praeina. Palyginimas su SQL injekcija naudingas, bet neišsamus. Duomenų bazė turi gramatiką ir interpretatorių; kalbos modelis gauna tekstą vienu srautu, ir jame nėra loginės sąlygos, ties kuria jis galėtų sustoti.

Pavojingesnis – netiesioginis variantas (indirect prompt injection). Nurodymas glūdi ne naudotojo įvestyje, o turinyje, kurį sistema pasiima pati: įkeltame gyvenimo apraše, gaunamo laiško paraše, prekės aprašyme, tinklalapyje, kurį parsisiunčia agentas. Naudotojas nieko kenkėjiško neįvedė. Jis užduoda nekaltą klausimą, o modelis įvykdo trečiosios šalies nurodymą.

Kad tai ne teorija, rodo dokumentuotas atvejis. Profesorius Markas Riedlas (Mark Riedl) savo profilio puslapyje baltomis raidėmis baltame fone įrašė nurodymą paieškos modeliui teigti, kad jis esąs kelionių laiku ekspertas. Bing modelis atsakyme apie jį būtent tai ir pareiškė. Užpuolikui pakanka nurodymą paruošti iš anksto: HTML komentare, paveikslėlio metaduomenyse, alternatyviajame tekste ar kitame lauke, į kurį paprastai niekas nežiūri. Šios kategorijos detalės surinktos viki puslapyje apie prompt injection, o būdas, kuriuo pokalbio turinys išnešamas į svetimą domeną paveikslėlio adreso pavidalu, aprašytas puslapyje Markdown Exfiltration Channels.

Jailbreak ir apsaugos barjerų apėjimas

Jailbreak – tai kraštutinis prompt injection atvejis: paruošta įvestis apeina ne vieną taisyklę, o visas iš karto. Modelis nustoja filtruoti turinį, išeina iš jam nustatytų ribojimų ir parašo net tai, kas jam tiesiogiai uždrausta.

Kokie trapūs tie ribojimai, parodė 2025 metų patikrinimas. Saugumo tyrėjai DeepSeek R1 modeliui išbandė 50 skirtingų jailbreak užklausų, ir pavyko visos 50, tai yra buvo pažeista 100 proc. saugumo taisyklių. Greitai išleidžiamuose atvirojo kodo modeliuose įdiegti ribojimai dažnai tėra fasadas, o ne apsauga, ir tai verta žinoti jau renkantis modelį.

Duomenų nutekėjimas iš RAG šaltinių

Dažniausias realus radinys įmonių sprendimuose kartu yra ir pats neįspūdingiausias: prieigos teisės pritaikomos po paieškos, o ne prieš ją. Vektoriniame indekse sudėti visų padalinių dokumentai, o filtruojama tik rezultatų sąraše arba nefiltruojama išvis. RAG (retrieval-augmented generation) sprendime būtent paieška nulemia, kas pateks į kontekstą, todėl prieigos logika turi veikti ten pat.

Darbuotojas neprašo dokumento, prie kurio prieigos neturi. Jis paklausia: „Apibendrink, kokios atlyginimų ribos taikomos padalinių vadovams.“ Ir gauna atsakymą. Nė viename prieigos žurnale pažeidimas nematomas, nes formaliai jo ir nebuvo.

Toje pačioje kategorijoje – sisteminės instrukcijos nutekėjimas. Ankstyvoji Bing Chat versija, žinoma Sydney vardu, savo slaptą sisteminę instrukciją kartu su vidinėmis taisyklėmis atidavė po vieno nurodymo atskleisti ankstesnių instrukcijų turinį. Pavyzdys parodė, kad ir Microsoft masto tiekėjui vidines instrukcijas galima ištraukti vienu triuku. Jei sisteminėje instrukcijoje įrašyti API raktai ar galiniai taškai, kartu su ja nuteka ir jie; plačiau apie tai viki puslapiuose System Prompt Extraction ir Cross-Session Context Bleed.

Antras sluoksnis – mokymo duomenys ir įmonės kontekstas. Jei modelis papildomai apmokytas vidiniais dokumentais, užpuolikas klausimų virtine gali bandyti atkurti jų fragmentus; tai vadinama inference attack arba model inversion. Galiausiai išorėje gali atsidurti pirminio kodo fragmentas, API raktas ar asmens duomenys, kurie niekada neturėjo palikti organizacijos sistemų. OWASP Top 10 for LLM Applications sąraše ši kategorija įvardyta atskirai kaip Sensitive Information Disclosure.

Per plačios DI agento teisės

Ekonomiškai sunkiausia kategorija. Asistentas, tvarkantis sąskaitas, gauna rašymo teises apskaitos sistemoje. Klientų aptarnavimo agentas gauna teisę atkurti slaptažodžius. Kol modelis gauna tik tuos nurodymus, kuriuos numatė kūrėjas, viskas veikia. Vos kas nors per svetimą turinį įrašo ten savo nurodymą, sistema įvykdo jo sumanymą su organizacijos teisėmis.

Šiai kategorijai priklauso ir SSRF. Jei asistentui leidžiama iškviesti vidinį API, pavyzdžiui, fone išsiųsti pakvietimą naujam naudotojui, tai gerai suformuluotas nurodymas pasuka jį prieš kitus, jautresnius galinius taškus: liepia keisti roles arba trinti paskyras. Tokiu atveju agentas išeina iš savo vaidmens ir padaro tai, ko jam niekas neleido.

Patikrinimo klausimas niekada nėra „ar modelį galima paveikti“, nes paveikti galima visada. Klausimas kitas: kas blogiausia, ką sėkmingas paveikimas gali paleisti? Apie tai – viki puslapiai Excessive Agency ir Approval Gate Bypass.

Nesaugus modelio atsakymo apdorojimas

Modelio atsakymas praktikoje laikomas patikimu rezultatu ir tada rodomas sąsajoje, įterpiamas į duomenų bazės užklausą arba vykdomas kaip kodas. Taip grįžta klasikinė injekcija, tik modelis čia – tarpinė stotis: jei modelį galima priversti išvesti <script> žymą ar ; DROP TABLE, lieka vienintelis klausimas – ką su tuo padarys kita sistema. Tas pats galioja kodui, kurį modelis parašo programuotojui ir kurį kas nors paleidžia neperžiūrėjęs. Detalės viki puslapiuose Improper Output Handling ir Insecure AI-Generated Code.

Indekso užnuodijimas ir manipuliuoti atsakymai

Jei sistema turinį indeksuoja automatiškai, pavyzdžiui, bendrinamus aplankus, gaunamus laiškus ar viešus puslapius, užpuolikas gali įdėti turinį, kuris indekse pasilieka ir tolesnėse užklausose iškyla kaip kontekstas. Ataka įvykdoma vieną kartą, o veikia pakartotinai. Šią kategoriją aprašo viki puslapis RAG Index Poisoning.

Iš to kyla subtilesnė manipuliacija, rinkoje vadinama LLM-SEO. Internetinė parduotuvė savo puslapyje paslepia sakinį, kad DI parengtoje prekių apžvalgoje reikia pabrėžti būtent šios parduotuvės prekę; modelis paslėptą nurodymą perima, o klientas gauna iškreiptą palyginimą. Sunkesnis atvejis – kai įmonės pokalbių robotas priverčiamas parašyti žalingą ar įžeidų atsakymą: organizacija rizikuoja reputacija, o greta stovi ir teisiniai klausimai, pavyzdžiui, jei tas pats asistentas pataria, kaip padaryti tai, kas draudžiama.

Neribojamas suvartojimas

Mažiau apie konfidencialumą ir daugiau apie sąskaitą. Užklausos, verčiančios modelį generuoti kuo ilgesnius atsakymus, rekursiškai kviesti įrankius ar kartoti paiešką, didina suvartojimą, o joks įspėjimas taip ir nesuveikia. Rinkoje tai vadinama denial of wallet; mechanizmą aprašo viki puslapis Denial-of-Wallet Loops.

Kodėl įprastų saugumo priemonių nepakanka

Skirtumas nuo įprastos programinės įrangos – principinis. Klasikinei programai logika nustatyta iš anksto: jei X, tai Y. Modelio elgesys susideda iš išmoktų sąsajų ir konkrečios užklausos, todėl, jei į kontekstą patenka kenkėjiškas nurodymas, aplikacijoje nėra sąlygos, kuri jį sustabdytų. Apsaugos būdų, veikiančių visomis aplinkybėmis, kol kas nežinoma. Ir daugiasluoksnė sisteminė instrukcija, ir detalus taisyklių sąrašas lūžta ties viena sėkminga komanda, kaip parodė Sydney atvejis.

Kokia paplitusi ši problema, rodo ir rinkos duomenys. Pagal Kroll apibendrinimą 92 proc. DI sistemų įsilaužimų testų atskleidė, kad tikrintas modelis yra pažeidžiamas kuria nors prompt injection forma, o 80 proc. rastų klaidų įvertintos kaip vidutinio sunkumo ar sunkesnės. Vadinasi, praktiškai kiekviename tikrintame sprendime buvo spraga, pro kurią modelio taisykles pavyko sulaužyti.

Mintis ne ta, kad išvardytos priemonės nereikalingos. Mintis ta, kad jos visos veikia teksto lygmenyje, o teksto lygmenyje šios ribos įgyvendinti neįmanoma. Įgyvendinti ją galima vienu lygmeniu žemiau: teisėse, su kuriomis paleidžiamas įrankis.

Ką tikriname LLM integracijos įsilaužimų teste

Aprėpties eiliškumą imame iš OWASP Top 10 for LLM Applications, o faktinę apimtį nulemia konkreti architektūra: iš kur modelis gauna tekstą, ką jis gali pasiekti ir kas su atsakymu daroma toliau. Atskiros kategorijos kartu su techniniu aprašymu ir sprendimu surinktos LLM viki puslapiuose.

Eiga tokia pati kaip įprasto įsilaužimų testo: suderinama apimtis ir taisyklės, surenkama informacija, atliekami testai su įrodymais, gilinamasi į radinius, sudaroma ataskaita ir atliekamas pakartotinis patikrinimas. Uždaros pokalbių sąsajos arba RAG sprendimo patikrinimas paprastai trunka nuo penkių iki dešimties darbo dienų. Agentiniai sprendimai su keliais įrankiais ir delegavimu kitiems agentams užtrunka ilgiau, nes kiekvieno įrankio teisės tikrinamos atskirai. Ataskaitoje radiniai surikiuoti pagal riziką: ką pavyko pasiekti, kaip tai pakartoti ir kokiais pakeitimais tai pašalinti.

Ką apie tai sako Lietuvos teisė

Lietuvos kibernetinio saugumo reguliavimas dirbtinio intelekto atskirai neišskiria, tačiau saugumo reikalavimai taikomi visiems informacinės sistemos komponentams. Pradėti verta nuo to, ko teisės aktuose nėra: atskiros pareigos testuoti DI ar LLM sprendimus nenustatyta, o įsilaužimų testavimas Lietuvoje apskritai nėra privalomas – testuotojams nenustatyta nei licencijavimo, nei registro tvarkos.

NIS2 direktyva Lietuvoje perkelta ne atskiru teisės aktu, o Kibernetinio saugumo įstatymą išdėstant nauja redakcija – įstatymu Nr. XIV-2902, kuris įsigaliojo 2024 m. spalio 18 d. Iš šio reguliavimo kibernetinio saugumo subjektams kyla trys greta stovinčios pareigos, ir nė viena iš jų nėra įsilaužimų testas:

• Kibernetinio saugumo reikalavimų aprašo (Vyriausybės nutarimas Nr. 945) 45.8 papunktis – ne rečiau kaip kas 6 mėnesius atliekamas viso masto spragų skenavimas;
• 48.1 papunktis – kasmetinis atitikties vertinimas, kurį subjektas atlieka pats sau;
• 48.3 papunktis kartu su Kibernetinio saugumo įstatymo 14 straipsnio 8 dalimi – ne rečiau kaip kas 3 metus atliekamas kibernetinio saugumo auditas.

Terminai skaičiuojami kiekvienam subjektui atskirai: 12 mėnesių organizaciniams ir 24 mėnesiai Apraše išvardytiems techniniams reikalavimams nuo tos dienos, kurią tas subjektas užregistruojamas Kibernetinio saugumo informacinėje sistemoje (KSIS). Vienos visai rinkai bendros datos nėra. Kurios pareigos kam taikomos, atsekėme straipsnyje apie tai, ar įsilaužimų testavimas privalomas.

Praktinė išvada LLM integracijoms paprasta. Jei modelis pasiekia sistemos, kuriai šie reikalavimai taikomi, duomenis, integracija nėra išimtis: ji yra toks pat tikrinamas paviršius kaip API vartai ar vidinis serveris. Pusmetinis spragų skenavimas įrankiais aptinka pasenusius komponentus, bet neatsako į klausimą, ar per įkeltą dokumentą galima perimti agento veiksmus; skirtumą tarp šių dviejų dalykų aprašėme straipsnyje apie tai, kuo skiriasi pažeidžiamumų skenavimas ir įsilaužimų testavimas.

Jei modelis gali pasiekti asmens duomenis, klausimas persikelia į duomenų apsaugos pusę. BDAR 32 straipsnis reikalauja procedūros, kuria reguliariai tikrinamas ir vertinamas techninių bei organizacinių priemonių veiksmingumas, tačiau nenurodo, koks būtent patikrinimas turi būti atliekamas. Nutekėjimas per asistentą savo ruožtu – asmens duomenų saugumo pažeidimas su iš to kylančiais pranešimo terminais. Priežiūros institucija Lietuvoje – Valstybinė duomenų apsaugos inspekcija.

Yra ir viena nuostata, kuri patį testavimo darbą paliečia tiesiogiai. Kibernetinio saugumo įstatymo 25 straipsnis nustato sąlygas, kuriomis pažeidžiamumų galima ieškoti be išankstinio sistemos valdytojo sutikimo: apie radinį pranešama Nacionaliniam kibernetinio saugumo centrui per 24 valandas, patvirtinus pažeidžiamumą veikla nutraukiama, slaptažodžiai nespėliojami, o viešinimas atidedamas. Tarp tų pačių sąlygų aiškiai įrašytas draudimas manipuliuoti darbuotojais. Todėl LLM integracijos testuojamos tik pagal rašytinį užsakovo leidimą ir iš anksto sutartą apimtį.

Vieną dalyką verta pasakyti iš karto. HAXORIS – Slovakijoje registruota įmonė. Kibernetinio saugumo įstatymo 14 straipsnio 8 dalyje numatyto kibernetinio saugumo audito neatliekame – jį atlieka nepriklausomi sertifikuoti auditoriai – ir atitikties nesertifikuojame. Dirbame techninėje pusėje: testuojame sistemas ir parengiame ataskaitą, kurią auditorius gali įvertinti. Kaip ši procedūra vyksta ir kas ją gali atlikti, aprašyta straipsnyje apie kibernetinio saugumo auditą.

Ką pasiruošti prieš testą

Pasirengimas nulemia, kaip giliai teste apskritai galima nueiti. Praktikoje pravers penki dalykai.

• Prieiga bent prie dviejų naudotojų su skirtingomis teisėmis. Tai ne patogumo klausimas, o sąlyga, be kurios autorizacijos klaidų apskritai neįmanoma įrodyti. Be antro naudotojo nepatikrinta lieka dažniausiai pasitaikanti sunkių radinių grupė.


• Prijungtų įrankių ir duomenų šaltinių sąrašas kartu su teisėmis, su kuriomis jie veikia. Būtent šis sąrašas nulemia, kiek darbo pareikalaus agentinė dalis.


• Sisteminė instrukcija, jei ją įmanoma perduoti. Jei perduoti negalima, paprastai perskaitome ją patys, ir tada tai tampa pirmuoju radiniu.


• Testavimo aplinka su realistiškais, bet ne tikrais duomenimis. Modelio elgesys priklauso nuo turinio, todėl tuščia aplinka duoda tuščius rezultatus.


• Raštu suderinta apimtis ir veiksmų laikas. Didesnės apkrovos testus suderiname iš anksto, kad jie nesutaptų su gamybinės aplinkos piko valandomis.

Ką verta įdiegti nepriklausomai nuo testo

• Teisės įrankio lygmeniu, o ne pasitikėjimas tekstu. Įrankis dirba su klausiančiojo, o ne su aplikacijos teisėmis. Visa kita – apsauga netinkamame lygmenyje. Jei agentas dirba su duomenų baze, skaitymo teisės suteikiamos konkretiems duomenims, o ne visumai.


• Autorizacija prieš paiešką. Vektorinis indeksas gali grąžinti tik tai, ką klausiantysis ir taip gali matyti. Filtravimas po paieškos nėra prieigos kontrolė.


• Patvirtinimas visam tam, kas negrįžtama. Mokėjimai, trynimas, išsiunčiamos žinutės, teisių keitimas: patvirtina žmogus, o patvirtinimo lange matyti, kas būtent įvyks.


• Sluoksniuota užklausa ir įvesties izoliavimas. Sisteminiai nurodymai, kūrėjo nurodymai ir naudotojo įvestis gyvena atskirai. Neapdorota naudotojo įvestis niekada neatsiduria prieš sisteminę instrukciją. Sluoksniavimas visko neišsprendžia, bet tai pirmoji gynybos linija; pravartu apriboti ir įvesties ilgį bei formatą.


• Modelio atsakymas – tai nepatikimi duomenys. Taip su juo ir elgiamasi visur, kur jis rodomas, vykdomas ar įterpiamas į užklausą. Sugeneruotas kodas pirmiausia praleidžiamas per statinę analizę ir paleidžiamas tik izoliuotoje aplinkoje; užklausoje ieškoma netikėtos komandos, nes SELECT negali staiga tapti DELETE.


• Užrašoma tai, ką modelis pasiūlė, o ne vien tai, kad jis atsakė. Be šio pėdsako incidento atkurti neįmanoma, o kaip tik įrašai leidžia laiku pastebėti pasikartojančius injekcijos bandymus.


• Jokių paslapčių sisteminėje instrukcijoje. Tai ne saugykla, o kontekstas.


• Mokymai ir aiškios taisyklės komandai. LLM rizikas supranta ne tik saugumo specialistai, bet ir kūrėjai bei produkto savininkai. Nustatoma, kokius duomenis modeliui leidžiama perduoti ir kaip jo atsakymas naudojamas toliau; kritiniams sprendimams prašoma žmogaus patvirtinimo.

Saugumas nėra vienkartinė būsena. Modelį ir aplinką aplink jį verta patikrinti pakartotinai po kiekvieno esminio pokyčio: pakeitus ar atnaujinus modelį, prijungus naują duomenų šaltinį, pridėjus įrankį ar pakeitus teises. OWASP rekomenduoja, kad toks testavimas būtų nuoseklus ir sektų kiekvieną reikšmingą modelio pakeitimą.

Apibendrinimas

DI diegimas atveria galimybių ir kartu įneša pažeidžiamumų klasę, kokios įprastose aplikacijose nepažinojome. Ataka ateina kaip nekaltas tekstas ir praeina pro visas ugniasienes, todėl saugumas planuojamas projekto pradžioje, o ne priklijuojamas pabaigoje. Nė viena atskira taisyklė ir nė vienas atskiras filtras neapsaugo nuo visko; suveikia sluoksniai, o svarbiausią iš jų sudaro teisės, su kuriomis veikia įrankis. Pasirengimas ir patikrinimas kainuoja daug kartų mažiau nei incidento padarinių šalinimas.

HAXORIS šioje srityje dirba techninėje pusėje. Atliekame AI ir LLM integracijų saugumo testavimą, aplink modelį esančios web aplikacijos įsilaužimų testavimą pagal OWASP WSTG gaires, o pasirengimą Kibernetinio saugumo įstatymo ir NIS2 reikalavimams vertiname atskirai, kaip aprašyta NIS2 įsilaužimų testų puslapyje. Jei DI funkcijos jau veikia gamybinėje aplinkoje arba artėja jų paleidimas, užsisakykite nemokamą konsultaciją – apimtį suderinsime kartu su jūsų komanda.

LLM integracijų testavimas – dažniausiai užduodami klausimai

Šaltiniai: straipsnio rekomendacijos ir pavyzdžiai remiasi viešai prieinamais šaltiniais, tarp jų OWASP Top 10 for LLM Applications sąrašu, saugumo įmonių analizėmis ir žiniasklaidoje dokumentuotais incidentais. Iš visų jų kyla ta pati išvada: DI saugumas nėra teorinis klausimas, o kasdienis darbas, kuriame pasirengimas, patikrinimas ir specialistų įtraukimas kartu išlaiko riziką apibrėžtose ribose.

Susijusios Haxoris paslaugos: AI ir LLM integracijų įsilaužimų testavimas