Prompt injection jeb ļaunprātīga uzvednes injekcija rodas, kad MI sistēma ārēju tekstu, dokumentu, e-pastu, tīmekļa lapu vai citu saturu kļūdaini uztver kā instrukciju un sāk rīkoties pretēji lietotāja vai uzņēmuma noteiktajam mērķim. Uzbrukums var mainīt atbildi, izvilināt sensitīvu informāciju, ietekmēt lēmumu vai pamudināt MI aģentu izmantot tam pieejamos rīkus neatļautā veidā.
Risku nevar atrisināt ar vienu “stingrāku” sistēmas promptu. Aizsardzība jāveido vairākos slāņos: neuzticams saturs jānodala no instrukcijām, modelim jāpiešķir minimālas tiesības, rīku izsaukumi jāpārbauda ar deterministisku kodu, sensitīvām darbībām jāprasa cilvēka apstiprinājums, bet sistēmas uzvedība regulāri jātestē un jāuzrauga.
Kas ir prompt injection
Lielais valodas modelis vienā kontekstā saņem dažādas izcelsmes informāciju: sistēmas noteikumus, lietotāja pieprasījumu, sarunas vēsturi, meklēšanas rezultātus, RAG sistēmā atrastus dokumentus un rīku atbildes. Cilvēkam ir saprotams, ka e-pasta teksts ir dati, nevis pavēle e-pasta lasītājam. Modelim šī robeža nav tik droša, jo gan noteikumi, gan saturs bieži ir izteikti dabiskā valodā.
OWASP LLM01:2025 definē prompt injection kā ievadi, kas neparedzēti maina modeļa uzvedību vai rezultātu. Tā var būt redzama vai paslēpta saturā, kuru modelis spēj apstrādāt. RAG un modeļa papildu apmācība var uzlabot atbilžu precizitāti, taču pati par sevi šo ievainojamību nenovērš.
Prompt injection nav tas pats, kas SQL injection vai komandu injekcija. Tradicionālā injekcijā ļaunprātīga virkne tiek interpretēta kā datubāzes vai operētājsistēmas komanda. Prompt injection vispirms ietekmē modeļa lēmumu. Bīstamās sekas parādās tad, ja lietotne uzticas šim lēmumam un bez pietiekamas pārbaudes nodod to tālāk datubāzei, API, e-pastam, failu sistēmai vai citam rīkam.
Tieša un netieša uzvednes injekcija
| Veids | Kā uzbrukuma saturs nonāk sistēmā | Tipisks piemērs |
|---|---|---|
| Tieša prompt injection | Uzbrucējs pats raksta MI saskarnē vai API ievadē | Klients mēģina panākt, lai atbalsta asistents ignorē noteikumus un atklāj citu klientu datus |
| Netieša prompt injection | MI nolasa uzbrucēja kontrolētu ārēju saturu | Aģents apstrādā e-pastu, PDF, tīmekļa lapu vai RAG dokumentu ar paslēptu ļaunprātīgu instrukciju |
| Vairākmodāla injekcija | Instrukcija ir attēlā, dokumenta slānī vai citā datu formā | Modelis analizē attēlu, kurā cilvēkam grūti pamanāms saturs mēģina mainīt uzdevumu |
Tiešo uzbrukumu parasti ir vieglāk sasaistīt ar konkrētu lietotāju un pieprasījumu. Netiešais uzbrukums ir sarežģītāks, jo ļaunprātīgo ievadi sistēmā var ienest pilnīgi godprātīgs darbinieks. Viņš lūdz apkopot piegādātāja dokumentu vai izlasīt ienākušo e-pastu, nezinot, ka tajā atrodas instrukcija MI aģentam.
Jailbreak ir radniecīgs jēdziens, taču tas biežāk nozīmē mēģinājumu apiet paša modeļa drošības ierobežojumus. Uzņēmuma prompt injection riska analīzē svarīgāks jautājums ir plašāks: vai neuzticama ievade spēj mainīt lietotnes paredzēto darba gaitu, piekļūt datiem vai izraisīt darbību citā sistēmā.
Kā uzbrukums pārvēršas biznesa incidentā
Veiksmīgam uzbrukumam parasti vajag nevis vienu kļūdu, bet vāju kontroles ķēdi.
Neuzticams saturs nonāk MI kontekstā. Avots var būt lietotājs, publiska tīmekļa lapa, e-pasts, augšupielādēts fails, klienta komentārs vai RAG zināšanu bāze.
Modelis saturu interpretē kā instrukciju. Ļaunprātīgais teksts konkurē ar sistēmas noteikumiem un lietotāja īsto uzdevumu.
Modelim ir pieejami vērtīgi dati vai rīki. Tas var lasīt CRM, meklēt dokumentus, izveidot maksājumu, nosūtīt e-pastu vai mainīt ierakstu.
Lietotne uzticas modeļa rezultātam. Rīka izsaukums, saite, SQL fragments vai ziņojuma adresāts netiek pārbaudīts neatkarīgi no modeļa.
Darbība notiek bez skaidra apstiprinājuma vai kontroles. Sekas kļūst ārējas: dati tiek nopludināti, ieraksts mainīts, ziņojums nosūtīts vai lēmums sagrozīts.
Tāpēc prompt injection riska smagumu nosaka četru faktoru kombinācija: neuzticamas ievades apjoms, pieejamo datu jutīgums, aģentam piešķirtās darbību tiesības un neatkarīgu pārbaužu trūkums. Čatbots, kas atbild tikai no publiskas informācijas un neko nevar mainīt, ir citā riska klasē nekā aģents ar piekļuvi e-pastam, dokumentiem un maksājumu sistēmai.
Kur uzņēmuma sistēmās risks ir visaugstākais
RAG asistenti un iekšējās zināšanu bāzes
RAG jeb retrieval-augmented generation pirms atbildes atrod atbilstošus dokumentu fragmentus un pievieno tos modeļa kontekstam. Ja zināšanu bāzē var nonākt ārēju personu faili, nekontrolēti komentāri vai nepārbaudīti importi, uzbrucējs var ievietot instrukciju avotā, kas vēlāk tiek atrasts šķietami nesaistītā vaicājumā.
Dokumenta atrašana nepadara to uzticamu. Sistēmai jāglabā avota identitāte, piekļuves līmenis un uzticamības statuss, bet atbildes izveidē jāievēro tādas pašas lietotāja tiesības kā oriģinālajā datu avotā.
E-pasta, dokumentu un pārlūkošanas aģenti
Šie aģenti pēc būtības lasa saturu, ko var kontrolēt trešā puse. Ļaunprātīga instrukcija var būt e-pasta pamattekstā, pielikumā, dokumenta metadatos vai tīmekļa lapā. Ja tas pats aģents drīkst arī sameklēt citus failus un nosūtīt ziņojumus, netieša prompt injection iegūst ceļu no neuzticamas ievades līdz sensitīvai darbībai.
Klientu atbalsts un pašapkalpošanās
Publiski pieejamu asistentu var sistemātiski testēt ikviens. Risks palielinās, ja asistents redz klientu profilus, pasūtījumus vai atlaides un var mainīt konta stāvokli. Autorizāciju nedrīkst deleģēt modelim: katram datu pieprasījumam un darbībai servera pusē jāpārbauda faktiskā lietotāja identitāte un tiesības.
Automatizēta dokumentu vērtēšana
MI var klasificēt CV, rēķinus, līgumus, iepirkumu piedāvājumus vai klientu iesniegumus. Dokumentā ievietota instrukcija var mēģināt ietekmēt vērtējumu, prioritāti vai kopsavilkumu. Šādā procesā dokumenta saturs ir pierādījumu materiāls, nevis uzticams uzdevuma formulējums.
Kāpēc ar sistēmas promptu un filtru nepietiek
Sistēmas prompts ir noderīgs uzvedības noteikšanai, bet tas nav drošības robeža. Uzbrucējs var mainīt formulējumu, sadalīt instrukciju vairākās daļās, izmantot citu valodu vai paslēpt to saturā. Vienkāršs aizliegto frāžu saraksts atrod zināmus paraugus, nevis uzbrukuma nodomu.
Arī atsevišķs “drošības modelis” vai klasifikators var kļūdīties. Tas var samazināt uzbrukumu skaitu, taču nedrīkst kļūt par vienīgo aizsardzību pirms sensitīvas darbības. Drošai arhitektūrai jāpieņem, ka daļa ļaunprātīgu ievadu sasniegs galveno modeli un daļa kaitīgu rezultātu izies cauri filtram.
Sistēmas promptā nedrīkst glabāt API atslēgas, paroles vai citus noslēpumus. Instrukcijas var palīdzēt modelim ievērot darba kārtību, taču to konfidencialitāte nav pielīdzināma drošai noslēpumu glabātuvei. Piekļuves dati jāuztur tam paredzētā sistēmā, un konkrētu rīku drīkst izsaukt tikai servera kods pēc tiesību pārbaudes. Pat ja uzbrucējs uzzina sistēmas instrukciju struktūru, tas nedrīkst dot viņam papildu piekļuvi.
To apstiprina aktuālie pētījumi par aģentu pārņemšanu. NIST 2026. gada lielapjoma red-teaming analīzē apraksta vairāk nekā 250 000 uzbrukuma mēģinājumu pret 13 progresīviem modeļiem; visiem mērķa modeļiem tika atrasts vismaz viens veiksmīgs uzbrukums. Secinājums uzņēmumam nav “MI nevar izmantot”, bet gan “modeļa noturību nedrīkst pielīdzināt sistēmas drošībai”.
Aizsardzība jāveido ap visu sistēmu
1. Izveidojiet draudu modeli
Uzskaitiet, kādi avoti var ievadīt saturu, kādus datus modelis redz, kādus rīkus tas drīkst izsaukt un kāda ir sliktākā iespējamā kļūda. Atsevišķi atzīmējiet publisku, partneru, darbinieku un sistēmu ģenerētu saturu. “Iekšējs dokuments” automātiski nenozīmē “droša instrukcija”.
2. Nodaliet instrukcijas no datiem
Ārējo saturu marķējiet kā neuzticamu un ievietojiet skaidri norobežotā datu laukā, nevis salīmējiet vienā teksta virknē ar sistēmas noteikumiem. Modelim norādiet, ka dokumentā atrodamās pavēles nav jāizpilda. Šī kontrole samazina risku, bet neaizstāj piekļuves un rīku ierobežojumus.
3. Ievērojiet minimālo tiesību principu
Aģentam jāsaņem tikai konkrētajam uzdevumam vajadzīgie dati un funkcijas. Ja vajag apkopot e-pastu, tam nav nepieciešamas tiesības nosūtīt vēstules vai atvērt finanšu mapi. Izmantojiet atsevišķus, īslaicīgus un šauri ierobežotus piekļuves marķierus, nevis darbinieka pilno sesiju.
Vēl drošāk ir nodalīt lasīšanas un rakstīšanas aģentus. Pirmais sagatavo strukturētu priekšlikumu, bet otrais saņem tikai pārbaudītu komandu ar konkrētiem parametriem.
4. Pārbaudiet rīku izsaukumus ārpus modeļa
Valodas modelis var ierosināt darbību, bet autorizāciju veic parasts lietotnes kods. Serveris pārbauda lietotāju, atļauto funkciju, datu objektu, adresātu, summu, domēnu un citus biznesa noteikumus. Brīva teksta vietā izmantojiet stingru shēmu ar atļautām vērtībām, garuma ierobežojumiem un drošām noklusējuma izvēlēm.
MI ģenerētu SQL, komandu, HTML, URL vai koda fragmentu nedrīkst automātiski izpildīt bez kontekstam atbilstošas validācijas un izolācijas. Modeļa atbilde ir neuzticama ievade nākamajai sistēmas daļai.
5. Sensitīvām darbībām prasiet cilvēka apstiprinājumu
Apstiprinājumam jāparāda konkrētā darbība, adresāts, izmantotie dati un neatgriezeniskās sekas. Poga “Turpināt” bez detaļām rada tikai drošības ilūziju. Maksājums, datu dzēšana, piekļuves maiņa, ārēja ziņojuma nosūtīšana un konfidenciāla faila kopīgošana ir tipiski soļi, kurus nevajadzētu veikt autonomi.
6. Ierobežojiet izpildes vidi un datu iznešanu
Koda izpildi un failu apstrādi ievietojiet izolētā vidē ar resursu, tīkla un failu sistēmas ierobežojumiem. Atļaujiet savienojumus tikai ar vajadzīgajiem domēniem un nepieļaujiet patvaļīgu ārēju URL izsaukšanu. Pat ja uzbrukums ietekmē modeli, ierobežota vide samazina iespēju sasniegt sensitīvus resursus vai iznest datus.
7. Validējiet arī gala atbildi
Pirms rezultāts nonāk pie lietotāja vai citas sistēmas, pārbaudiet datu noplūdes pazīmes, neatļautas saites, neatbilstošu formātu, personu datus un novirzes no uzdevuma. Strukturētiem procesiem salīdziniet atbildi ar avotiem un biznesa noteikumiem. Klasifikatora spriedumam vai kopsavilkumam jābūt izsekojamam līdz izmantotajiem dokumentiem.
Žurnāli, uzraudzība un incidentu vadība
Bez žurnāliem uzņēmums var redzēt nepareizu rezultātu, bet nespēt noskaidrot, kāds saturs, modelis, rīks un piekļuve to izraisīja. Reģistrējiet pieprasījuma identifikatoru, ievades avotus, atrastos dokumentus, politikas lēmumus, rīku izsaukumus, apstiprinājumus, kļūdas un rezultāta statusu. Sensitīvos datus žurnālos maskē un piekļuvi tiem ierobežo.
Brīdinājumus var veidot par neparastiem rīku izsaukumiem, atkārtoti bloķētiem pieprasījumiem, piekļuvi negaidītām datu kategorijām, jauniem ārējiem domēniem un strauju modeļa uzvedības maiņu. Jābūt iespējai ātri atslēgt konkrētu rīku, atsaukt aģenta pilnvaras, izolēt dokumentu avotu un saglabāt pierādījumus izmeklēšanai.
Incidenta plānā definējiet, kurš pieņem lēmumu apturēt MI funkciju, kurš izvērtē iespējamo datu noplūdi, kā tiek informēti atbildīgie un kā pēc labojuma tiek veikta atkārtota drošības pārbaude.
Red-teaming un regresijas testi
Prompt injection aizsardzība nav vienreizējs audits. Mainās modeļi, sistēmas prompti, RAG dokumenti, integrācijas un uzbrucēju paņēmieni. Pirms palaišanas un pēc būtiskām izmaiņām jāizpilda uzbrukumu scenāriji, kas atspoguļo tieši uzņēmuma datu avotus un rīkus.
Testu komplektā iekļaujiet tiešu noteikumu apiešanu, instrukcijas ārējos dokumentos, vairākās daļās sadalītu ievadi, citas valodas, bojātus rīku parametrus, neatļautu datu pieprasījumu un mēģinājumu izraisīt ārēju darbību bez apstiprinājuma. Rezultātu vērtē ne tikai pēc modeļa teksta. Jāpārbauda, vai sistēma bloķēja rīku, neizpauda datus, saglabāja žurnālu un korekti informēja lietotāju.
Saglabājiet neveiksmīgos un veiksmīgi bloķētos scenārijus kā regresijas testus. Ja tiek mainīts modelis vai prompts, iepriekšējās aizsardzības īpašības nedrīkst pazust nepamanītas.
Ko prasīt MI risinājuma piegādātājam
Uzņēmumam vajadzīga ne tikai informācija par modeļa precizitāti. Piegādātājam jāspēj izskaidrot:
kā tiek nodalīts lietotāja, sistēmas un ārējo avotu saturs;
kādas tiesības ir aģenta kontam un vai tās iespējams ierobežot pa funkcijām;
kuras darbības vienmēr prasa apstiprinājumu;
kā tiek validēti rīku parametri un modeļa rezultāti;
kādi žurnāli, brīdinājumi un ārkārtas atslēgšanas mehānismi ir pieejami;
kā tiek veikti prompt injection testi un drošības atjauninājumi;
kā organizācija var izmeklēt incidentu un eksportēt nepieciešamos pierādījumus.
Atbilde “mūsu modelim ir drošības filtri” nav pietiekama, ja sistēmai ir piekļuve konfidenciāliem datiem vai iespēja veikt darbības.
Praktiska ieviešanas secība uzņēmumam
Sāciet ar vienu skaidri norobežotu procesu un lasīšanas režīmu. Inventarizējiet datu avotus, atzīmējiet neuzticamo saturu un izveidojiet tiesību matricu. Tad ieviesiet servera puses politikas, strukturētu rīku izsaukumu validāciju, žurnālus un uzbrukumu testus. Rakstīšanas vai ārējās saziņas funkcijas pievienojiet tikai tad, kad ir apstiprinājumi, izolācija un incidenta apturēšanas mehānisms.
Vienkāršs lēmuma filtrs ir šāds: ja uzņēmums nevar droši ierobežot sliktāko darbību, ko kompromitēts aģents varētu veikt, šai darbībai pagaidām jāpaliek cilvēka kontrolē.
Secinājums
Prompt injection izmanto MI sistēmas grūtības vienmēr droši atšķirt instrukciju no datiem. Uzbrukums kļūst bīstams tad, kad modelis saņem plašu kontekstu, sensitīvus datus un iespēju rīkoties, bet apkārtējā lietotne tā rezultātam uzticas bez neatkarīgas pārbaudes.
Drošības mērķis nav apsolīt, ka modelis nekad netiks maldināts. Mērķis ir panākt, lai maldināts modelis nevarētu pārkāpt piekļuves robežas, izpildīt neatļautu darbību vai nepamanīti iznest datus. Tieši tāpēc droša biznesa procesu automatizācija sākas ar tiesībām, datu plūsmām, validāciju un kontroles punktiem, nevis tikai ar MI modeļa izvēli.