Kas yra LLM saugumas? Kaip sumažinti OWASP Top 10 saugumo rizikas

Ataka, kuria DI apgaunamas ir priverčiamas užpuoliko instrukcijas laikyti komandomis, – raginimų injekcija – nuo 2023 m. kiekviename leidime užima pirmąją vietą sąraše „OWASP Top 10 for LLM Applications“.

Šis sąrašas – bene artimiausias bendram sutarimui dalykas DI saugumo srityje. Projektas prasidėjo kaip nedidelė saugumo specialistų grupė, o dabar prie jo prisideda daugiau nei 600 ekspertų iš daugiau nei 18 šalių.

Esame DI bendrovė, skelbianti vadovą apie tai, kaip DI galima įkalbėti įvairių dalykų, todėl neapsimesime, kad ši problema išspręsta. Wilsonas, vienas iš OWASP projekto vadovų, apie dabartines apsaugos priemones pasisakė gana aiškiai: „...atvirai kalbant, nemanau, kad esame pasiekę 99 %.“

2026 m. leidimas prasideda ta pačia gaida. Projekto vadovas ragina mus „nustoti bandyti sukurti modelį, kurio neįmanoma apgauti“, o aplinkinę sistemą projektuoti taip, kad apgautas modelis negalėtų sugadinti nieko svarbaus.

Šios pozicijos laikomės aptardami visas 10 rizikų iš OWASP 2026 m. sąrašo.

Ką reiškia LLM saugumas?

LLM saugumas – tai DI modelių ir juos naudojančių programų apsauga nuo atakų ir piktnaudžiavimo. Rizika didėja priklausomai nuo to, prie ko modelis prijungtas: kokius failus ir duomenis jis gali skaityti ir kokius įrankius naudoti, pavyzdžiui, el. paštą, paiešką ar įmonės duomenų bazę.

Tinkamai apsaugotoje programinėje įrangoje yra aiški riba tarp instrukcijų, kurių laikosi programa, ir informacijos, kurią ji apdoroja. Tačiau LLM tokios ribos neturi.

Viskas, ką modelis skaito, jį pasiekia kaip vienas ilgas teksto srautas: kūrėjo instrukcijos, jūsų klausimas, tinklalapis, kurį jis surado. DI modeliai turėtų sekti, kas kalba – kūrėjas, naudotojas ar pats modelis, svarstantis problemą.

Tačiau tyrėjai Jasmine Cui ir Charlesas Ye nustatė, kad modeliai dažniausiai spėja, kas kalba, pagal tai, kaip skamba tekstas. Taigi, jei užpuolikas parašo kažką, kas skamba kaip paties modelio samprotavimas, modelis gali patikėti, kad šią mintį sugalvojo pats. Tai problema bet kuriai saugumo sąrangai, kuri remiasi tuo, kad modelis žino, kas čia vadovauja.

Su ta pačia problema susidūrėme ir dirbdami su savo DI agentais. Mūsų informacijos saugumo vadovas (CISO) Kyle'as Polley sakė leidiniui ISMG, kad agentai „gali nesilaikyti politikų, net jei jas įrašote į sistemos raginimą“. Todėl sukūrėme Numbat – atvirojo kodo įrankį, kuris patikrina, ką agentas ketina daryti, ir gali tai užblokuoti, jei veiksmas pažeidžia nustatytą saugumo taisyklę.

LLM saugumas reiškia susitaikyti su tuo, kad modelis kartais vykdys netinkamo asmens nurodymus, ir apsupti jį DI apsauginiais mechanizmais, kurie veikia net tada, kai taip nutinka.

Kokia yra geriausia LLM saugumo praktika?

Sąrašą OWASP Top 10 for LLM Applications 2026 aptarsime iš eilės – nuo Nr. 1 iki Nr. 10.

Kiekvienai rizikai pateiksime paprastą paaiškinimą, kas gali nutikti ne taip, ir realų pavyzdį. Tada aptarsime praktikas, kurios gali padėti to išvengti arba bent jau sumažinti žalą.

1. Suvaldykite raginimų injekciją

Raginimų injekcija įvyksta, kai užpuolikas priverčia DI vykdyti instrukcijas, kurių šis neturėtų vykdyti. Tokios instrukcijos gali būti pateiktos tiesiogiai pokalbyje arba paslėptos el. laiške, tinklalapyje ar dokumente.

Antrasis tipas vadinamas netiesiogine raginimų injekcija. Paprašote asistento apibendrinti dokumentą. Jo autoriai jame nurodė asistentui išsiųsti jiems jūsų privačius failus. Jei asistentas vykdo šias instrukcijas, dokumento autorius iš esmės pasiskolino jūsų prieigą.

PCMag lygina raginimų saugumą su skylių kamšymu akytame akmenyje. Užsandarini vieną angą – vanduo suranda kitą. „Ataka randa kelią; ji ištaisoma, tačiau daugybė kitų atakos kelių lieka neatrasti vien dėl to, kokios dinamiškos yra tokios sistemos kaip LLM.“

Pavyzdys: 2025 m. birželį Aim Security tyrėjai aptiko EchoLeak – spragą, dėl kurios Microsoft 365 Copilot buvo apgaunamas ir nutekindavo privačią įmonės informaciją. Kai darbuotojas užduodavo įprastą darbo klausimą, Copilot galėjo įtraukti užpuoliko el. laišką, vykdyti jame paslėptas instrukcijas ir nusiųsti neskelbtiną informaciją užpuolikui. Ataka apėjo patikras, skirtas kenkėjiškoms instrukcijoms aptikti ir įtartinoms nuorodoms pašalinti.

Ką galite padaryti:

• Laikykitės Meta „dviejų taisyklės“: EchoLeak atveju reikėjo DI, kuris galėtų skaityti įmonės duomenis, skaityti išorinius el. laiškus ir siųsti informaciją į išorę, – ir jis turėjo visus tris gebėjimus. Apribojus jį dviem iš šių gebėjimų, raginimų injekcija negali įgyti per daug kontrolės. Jei užduočiai reikia visų trijų, prieš kiekvieną veiksmą reikalaukite žmogaus patvirtinimo.
• Testuokite, tarsi užpuolikai žinotų jūsų apsaugos priemones: Pateikite saugumo testuotojams įdiegtas taisykles ir filtrus, tada leiskite jiems bandyti juos apeiti. Viename tyrime prie apsaugos priemonių prisitaikę užpuolikai daugumą iš 12 išbandytų apsaugos priemonių įveikė daugiau nei 90 % atvejų.

2. Neleiskite nutekėti neskelbtinai informacijai

Kai DI sistemos pateikia privačią informaciją žmonėms, kurie neturėtų jos matyti, tai vadinama neskelbtinos informacijos atskleidimu. Tai gali būti kliento mokėjimo duomenų atskleidimas arba privačių pokalbių palikimas bendrai naudojamoje duomenų bazėje.

Daugelis nutekėjimų prasideda nuo „perteklinio dalijimosi“. Tarkime, įmonė prijungia savo DI prie diskų ir žinių bazių, kurių leidimai per daug laisvi. DI gauna viską, ką gali pasiekti, – tiksliai taip, kaip suprojektuota. Niekam nereikia įsilaužti, tačiau LLM galima laikyti jau pažeistu.

Pavyzdys: 2025 m. sausį Wiz tyrėjai aptiko internete atvirą DeepSeek duomenų bazę su daugiau nei milijonu žurnalo įrašų, įskaitant pokalbių istoriją ir API raktus, kuriuos programinė įranga naudoja prieigai prie kitų paslaugų. Tyrėjams net nereikėjo įkalbinėti modelio ką nors atskleisti.

Ką galite padaryti:

• Patikrinkite prieigą prieš DI perskaitant duomenis: Prieš perduodama dokumentus modeliui, jūsų programa turėtų patikrinti, kuriuos dokumentus klausimą užduodantis asmuo turi teisę matyti.
• Apsaugokite savo DI paliekamus įrašus: Prieš išsaugodami veiklos žurnalus pašalinkite privačią informaciją ir slaptuosius raktus, reikalaukite prisijungimo ir suteikite prieigą tik tiems, kam jos reikia. Nustatykite saugojimo laikotarpį, kad šie įrašai nesikauptų neribotai.

3. Pažabokite perteklinį savarankiškumą

Perteklinio savarankiškumo turintys DI turi daugiau galių, nei reikia jų darbui: įrankių, kurių jiems nereikia, užduotį viršijančių leidimų arba laisvės veikti be patikros. Priežastis čia nesvarbi.

Raginimų injekcija, programos klaida ar tiesiog suklydęs modelis – visa tai lemia tą patį rezultatą. Jei DI turi galimybę, anksčiau ar vėliau jis padarys ką nors žalingo.

Pavyzdys: 2025 m. liepą SaaStr įkūrėjas Jasonas Lemkinas pranešė, kad Replit programavimo agentas ištrynė jo duomenų bazę su 1206 vadovų įrašais, nors buvo nurodyta nedaryti jokių pakeitimų. Iš pradžių agentas teigė, kad duomenų atkurti neįmanoma, tačiau vėliau paaiškėjo, kad tai įmanoma. Jasonas suprato, kad nurodymas agentui neliesti duomenų bazės neatėmė iš jo galimybės ją ištrinti.

Padidinti

Šaltinis: X

Ką galite padaryti:

• Pašalinkite užduočiai nereikalingus gebėjimus: Apribokite ir agentui suteikiamus įrankius, ir tai, ką tie įrankiai gali daryti. Asistentui, kuris apibendrina el. laiškus, reikia leidimo juos skaityti, o ne siųsti ar ištrinti.
• Leidimų patikras vykdykite už DI ribų: Kiekvieną kartą, kai prašoma atlikti veiksmą, patikrinkite jį pagal savo saugumo taisykles ir reikalaukite, kad jį patvirtintų žmogus.

4. Tikrinkite, kas patenka į jūsų DI tiekimo grandinę

Nedaug įmonių kuria DI nuo nulio, o kasmet jų vis mažiau. Remiantis Menlo Ventures 2025 m. apklausa „The State of Generative AI in the Enterprise“, 2024 m. DI modelius pirko 53 % įmonių, o 2025 m. – jau 76 %.

Dažniausiai įmonės atsisiunčia modelius iš tokių platformų kaip Hugging Face, toliau juos apmoko kitų surinktais duomenų rinkiniais ir prijungia nepažįstamų žmonių parašytus priedus bei kodo paketus.

Kiekviena iš šių dalių – tai kelias patekti į vidų. Jei viena jų suklastojama, problema iškeliauja pas naudotojus kartu su jūsų produktu.

Pavyzdys: Nuo 2026 m. sausio iki 2026 m. rugpjūčio viešų Hugging Face modelių saugyklų skaičius išaugo nuo 2,43 mln. iki 2,96 mln. Tačiau 2026 m. liepą, vykstant vidiniam saugumo testavimui, OpenAI modeliai apėjo kontrolės priemones, kurios turėjo neleisti jiems prisijungti prie interneto, ir įsilaužė į dalį Hugging Face sistemų. Vienas agentas netgi gavo 14 viešai atskleistų prisijungimo duomenų rinkinių, patikrino, ar jie veikia, ir pasidalijo jais su kitais agentais. Vėliau agentai išnaudojo spragas, leidusias jiems vykdyti kodą Hugging Face serveriuose.

„Griežtiname suderinimo reikalavimus per visą modelio gyvavimo ciklą, kuriame labiau izoliuotas Sandbox aplinkas, ribojame prieigą prie interneto ir dar labiau kontroliuojame prieigą prie modelio svorių“, – teigiama OpenAI ataskaitoje.

Ką galite padaryti:

• Fiksuokite tikslias modelių versijas ir jas patikrinkite: Kiekvieną modelį susiekite su peržiūrėta versija ir prieš įkeldami patikrinkite jo failo maišos reikšmę, kad pakeistas failas negalėtų prasmukti su ta pačia žyma. OWASP taip pat rekomenduoja skaitmeninius parašus, tačiau su išlyga: parašas įrodo, iš kur modelis kilęs, bet ne tai, kad jis saugus.
• Tikrinkite kiekvieną DI pasiūlytą paketą: Prieš diegdami DI asistento rekomenduotą kodo paketą, įsitikinkite, kad jis egzistuoja, kad tai būtent tas paketas, kurio norėjote, ir kad jį išleido tas leidėjas, kurio tikitės.

5. Apsisaugokite nuo duomenų ir modelio apnuodijimo

Apnuodytas DI mokosi iš sugadintų duomenų. Tai gali būti pavyzdžiai, kuriais jis buvo papildomai apmokytas, arba žinių bazė, kurioje jis ieško atsakymų. Modelis vis dar atrodo veikiantis; jis tiesiog išmoksta klaidingų pamokų, o kartais išmoksta elgtis netinkamai tik pamatęs konkrečią aktyvinimo frazę.

Modelis išlaikys visus jūsų testus, kol kas nors nepanaudos šios frazės.

Padidinti

Be to, tai labai sunku atitaisyti. Apnuodijimas nėra programos klaida, kurią galima pašalinti pataisa. Jei jūsų duomenys klaidingi, gali tekti juos iš naujo patikrinti, iš naujo apmokyti modelį arba visiškai jį pakeisti.

Pavyzdys: 2025 m. spalį Anthropic, JK DI saugumo instituto ir Alano Turingo instituto tyrėjai parodė, kad 250 apnuodytų dokumentų pakanka išmokyti modelį generuoti beprasmį tekstą, kai tik jis susiduria su tam tikru aktyvikliu. Tas pats skaičius suveikė su visų keturių išbandytų dydžių modeliais, nors didžiausias iš jų buvo apmokytas daugiau nei 20 kartų didesniu švarių duomenų kiekiu.

Ką galite padaryti:

• Sekite, iš kur gaunami jūsų duomenys: Registruokite kiekvieną naudojamą duomenų rinkinį ir modelį, iš kur kiekvienas jų gautas ir kas pasikeitė tarp versijų. Duomenų rinkiniams rekomenduojame taikyti versijų kontrolę, kad aptikę apnuodijimą galėtumėte grįžti prie švarios versijos ir išsiaiškinti, kaip jis įvyko.
• Tikrinkite, ar nėra užpakalinių durų: „Užpakalinės durys“ – tai paslėpta elgsena, kurią užpuolikas įdiegia į modelį ir kuri įsijungia tik gavusi tam tikrą frazę ar kitą aktyviklį. Tikrinkite, ar jų nėra, naudodami įvestis, sukurtas tam, kad modelis pažeistų įprastas savo taisykles.

6. Apribokite neribotą išteklių naudojimą

Kai DI neturi jokių apribojimų, kiek darbo jis gali atlikti ar kiek gali kainuoti, jo išteklių naudojimas laikomas „neribotu“. Dauguma DI paslaugų taiko mokestį už naudojimą, todėl užpuolikas galėtų išpūsti jūsų sąskaitą arba sukurti jūsų modelio kopiją.

OWASP pagrindinę problemą vadina „sąnaudų asimetrija“. Trumpa, pigi užklausa gali sukelti brangius skaičiavimus jūsų pusėje.

Pavyzdys: 2024 m. gegužę Sysdig grėsmių tyrimų komanda aptiko naują ataką, pavadintą „LLMjacking“. Užpuolikų grupė, naudodama pavogtus prisijungimo duomenis, taikėsi į 10 debesyje talpinamų LLM paslaugų. Jie pateko per pažeidžiamą Laravel versiją, tada išsiaiškino, ką leidžia daryti prisijungimo duomenys ir kokios taikomos kvotos, akivaizdžiai siekdami parduoti prieigą. Taip pat buvo tikrinama daug žurnalų registravimo nustatymų – tikriausiai siekiant išvengti aptikimo. Sysdig duomenimis, blogiausiu atveju auka galėtų patirti daugiau nei 46 000 USD išlaidų per dieną.

Ką galite padaryti:

• Nustatykite biudžetus, kurie sustabdo išlaidas: Taikykite griežtus išlaidų limitus atskiriems naudotojams, API raktams, komandoms ir visai paskyrai. Užtikrinkite jų laikymąsi visur, kur gali patekti užklausos.
• Kiekvienai užduočiai nustatykite pabaigos tašką: Apribokite, kiek laiko gali trukti užduotis, kiek teksto ji gali apdoroti ir sugeneruoti bei kiek įrankių iškvietimų gali atlikti. Įdiekite automatinius stabdžius agentams, kurie kartojasi arba viršija jiems skirtą limitą.

7. Aptikite klaidingą informaciją prieš imdamiesi veiksmų

Kai DI pateikia kažką klaidingo, kas skamba teisingai, ir kas nors – žmogus ar sistema – tuo remdamasis imasi veiksmų, tai vadinama klaidinga informacija. Pagrindinė rizika – ne tiek pats klaidingas atsakymas, kiek tai, kad juo pasitikima ir jis naudojamas.

Incidentų istorija rodo, kad specialistai dėl klaidingos informacijos nerimavo mažiau, nei derėjo. Pasak 2026 m. leidimo įžanginio laiško, balsuotojai ją nustūmė arčiau sąrašo apačios, tačiau realūs incidentai rodo, kad jai vieta arti viršūnės.

Pavyzdys: 2025 m. Deloitte Australia pagal 440 000 AUD vertės vyriausybės sutartį atliko socialinės apsaugos IT sistemų peržiūrą. Sidnėjaus universiteto tyrėjas Chrisas Rudge'as aptiko nuorodų į neegzistuojančius tyrimus ir išgalvotą citatą iš federalinio teismo sprendimo. Pataisytoje ataskaitoje buvo atskleista, kad Deloitte savo metodikoje naudojo Azure OpenAI GPT-4o, ir bendrovė sutiko grąžinti paskutinę įmoką. Deja, tai buvo užtikrinimo peržiūra.

Ką galite padaryti:

• Patikrinkite, ar įrodymai pagrindžia atsakymą: Teiginius grįskite naujausiais, autoritetingais šaltiniais. Atsakydami apie politiką, gaukite patvirtintą politiką ir patikrinkite, ar ji pagrindžia išvadą, įskaitant jos išimtis.
• Patikrinkite, prieš sistemai imantis veiksmų: Jei agentas teigia, kad klientas praėjo tapatybės patikrą, prieš išleisdami mokėjimą tai patvirtinkite tikrinimo sistemoje. Svarbiems sprendimams reikalaukite žmogaus patvirtinimo, o peržiūrinčiam asmeniui pateikite pagrindžiančius įrodymus.

8. Sumažinkite paslėpto konteksto atskleidimo žalą

DI programos pateikia modeliui instrukcijas ir foninę informaciją, kurių naudotojai paprastai nemato. Tai gali būti sistemos raginimas, vidinės politikos, galimų įrankių aprašai ir taisyklės, kas gali juos naudoti. Paslėpto konteksto atskleidimas įvyksta, kai modelis šią informaciją kam nors atskleidžia.

2026 m. OWASP išplėtė šį punktą, anksčiau vadintą „sistemos raginimo nutekėjimu“, nes sistemos raginimas yra tik dalis to, kas gali nutekėti. Pavojus priklauso nuo to, ką ten įdėjote. Nutekėjęs komunikacijos tono vadovas kelia šiokią tokią gėdą, tačiau nutekėjęs API raktas suteikia kam nors prieigą prie jūsų konfidencialios duomenų bazės.

Pavyzdys: 2023 m. vasarį naudotojams pavyko priversti Microsoft Bing Chat atskleisti savo vidines instrukcijas. Vieną sėkmingą bandymą atliko Marvinas von Hagenas, kuris prisistatė OpenAI kūrėju ir paprašė instrukcijų, neva norėdamas sukonfigūruoti modelį. Bing atskleidė paieškas, atsakymus ir saugumo elgseną reglamentuojančias taisykles, taip pat savo vidinį pavadinimą Sydney. Tarp atskleistų instrukcijų buvo ir viena, nurodanti šias instrukcijas laikyti konfidencialiomis.

Ką galite padaryti:

• Laikykite slaptus duomenis atokiau nuo modelio konteksto: Vadovaukitės prielaida, kad viskas, ką modelis gali perskaityti, gali tapti matoma naudotojams, – slaptažodžius, API raktus ir prieigos žetonus saugokite atskiroje paslapčių valdymo sistemoje.
• Užtikrinkite, kad leidimai galiotų net ir nutekėjus taisyklėms: Prieigos patikras įgyvendinkite savo programos kode. Jei įrankis skirtas tik administratoriams, prieš jį paleisdami patikrinkite naudotojo paskyros leidimus.

9. Apsaugokite savo vektorius ir įterptis

Kai DI, ieškodamas atsakymų jūsų įmonės dokumentuose, naudoja vektorinę paiešką, jis neieško tiesiogiai tekste. Dokumentai paverčiami „įterptimis“ – ilgais skaičių sąrašais, atspindinčiais kiekvienos ištraukos prasmę, – ir saugomi vektorinėje duomenų bazėje. Klausimas paverčiamas tokiu pačiu būdu, o sistema išrenka ištraukas, kurių skaičiai yra artimiausi.

OWASP apibendrina keturis būdus, kaip ji gali sutrikti: apnuodijimas verčia sistemą klysti, inversija – nutekinti duomenis, blokavimas – nutilti, o netinkama prieigos kontrolė – atiduoti bet ką bet kam.

Šie skaičiai nėra tokia saugi abstrakcija, kokia atrodo. Saugomas įterptis galima vėl paversti tekstu, o vienas metodas savo bandymuose tiksliai atkūrė 92 % trumpų, 32 žetonų ištraukų. Taigi nutekėjusi atsarginė kopija, kurioje yra „tik įterptys“, taip pat gali atskleisti dokumentų turinį.

Pavyzdys: USENIX Security 2025 konferencijoje pristatytame tyrime mokslininkai parodė, kad vienas kruopščiai sukurtas dokumentas gali sutrukdyti DI atsakyti į konkretų klausimą. Šį dokumentą jie įtraukė į rinkinį, kuriame DI ieškojo informacijos. Radęs šį dokumentą, DI galėjo pareikšti, kad neturi pakankamai informacijos arba kad atsakyti būtų nesaugu. Dokumentui net nereikėjo liepti DI nepaisyti savo taisyklių. Tai vadinama „paieškos blokavimu“ (angl. retrieval jamming).

Ką galite padaryti:

• Viešiems ir privatiems duomenims naudokite atskirus indeksus: Nemaišykite iš interneto surinkto turinio su partnerių duomenimis ar konfidencialiais vidaus dokumentais. Užuot žymėję turinį viename indekse, atskirkite jį fiziškai pagal patikimumo lygį – taip pašalinsite visą klaidingų konfigūracijų kategoriją, o iš interneto surinktas turinys negalės atsidurti šalia jūsų valdybos dokumentų.
• Su įterptimis elkitės taip pat, kaip su dokumentais, iš kurių jos sukurtos: Šifruokite jas, saugokite ne tik šaltinio failus, bet ir vektorinės duomenų bazės atsargines kopijas, o ištrynę originalą ištrinkite ir jo įterptis. Savo įterpčių paslaugos API raktus laikykite paslaptyje.

10. Patikrinkite DI išvestį prieš perduodami ją toliau

Kai programa perduoda DI išvestį kitai sistemai nepatikrinusi, ar ją ten saugu naudoti, ji netinkamai tvarko LLM išvestį.

Šis punktas taip pat apima nesaugų kodą, kurį DI programavimo asistentai generuoja dideliu mastu. Todėl kiekviena asistento parašyta eilutė taip pat yra išvestis.

Pavyzdys: 2025 m. tyrėjas Johannas Rehbergeris parodė, kaip Sourcegraph programavimo asistentas Amp galėjo nutekinti pokalbio turinį vien parodydamas paveikslėlį. Pasitelkęs raginimų injekciją, jis privertė Amp įtraukti privačią informaciją į paveikslėlio žiniatinklio adresą. Tada programa automatiškai atsisiuntė tą paveikslėlį ir taip išsiuntė informaciją į jo serverį. Išvesties tvarkymo klaida buvo būtent ši automatinė užklausa – modelio sugeneruotas tekstas virto ryšiu su išoriniu serveriu, kuriuo kartu nukeliavo ir privatūs duomenys.

Ką galite padaryti:

• Užtikrinkite, kad išvestis būtų saugi ten, kur ji keliauja: Tikrinkite ir apdorokite atsakymus atsižvelgdami į tai, kur jie bus perduoti. Tinklalapyje neleiskite, kad sugeneruotas tekstas taptų vykdomuoju kodu. Duomenų bazėje naudokite parengtąsias užklausas, kuriose pateiktos reikšmės laikomos atskirai nuo komandų.
• Neleiskite atsakymams automatiškai jungtis prie išorinių šaltinių: Pagal numatytuosius nustatymus išjunkite automatinį paveikslėlių, nuorodų peržiūrų ir įterptų puslapių įkėlimą modelio atsakymuose. Būtinus ryšius leiskite tik su aiškiai patvirtintomis paskirties vietomis.

Kaip Perplexity apsaugo LLM?

Darome prielaidą, kad kiekviena aukščiau aprašyta rizika anksčiau ar vėliau pasireikš, todėl kuriame sistemas taip, kad tuomet ji negalėtų padaryti daug žalos. Kaip tai darome, mūsų informacijos saugumo vadovas (CISO) Kyle’as Polley paaiškino neseniai vykusiose dirbtuvėse.

• Agentas gauna savo kompiuterį, ir šis iš pradžių būna tuščias: Jūsų nešiojamajame kompiuteryje įdiegti agentų įrankiai gali pasiekti jame esančius failus, programas ir išsaugotus prisijungimo duomenis. Perplexity Computer veikia priešingai. Kiekviena užduotis vykdoma atskiroje izoliuotoje sandbox aplinkoje, ir, kaip sako Polley, „pagal numatytuosius nustatymus ji neturi prieigos prie nieko“.
• Agentas niekada nemato slaptažodžių: Prijungtų paslaugų prisijungimo duomenys saugomi už sandbox aplinkos ribų. Kai agentui reikia pasiekti tokią paslaugą kaip GitHub, jis siunčia užklausą be jokių prisijungimo duomenų. Šliuzas patikrina, ar paskirties vieta ir užklausa atitinka tai, ko tikimasi, ir tik tada, užklausai išeinant, prideda prisijungimo duomenis. Agentas gali naudotis ryšiu, negaudamas raktų.
• Jūsų leidimai perkeliami, o jūs galite juos sugriežtinti: Per OAuth sukurti ryšiai išsaugo jūsų prieigos leidimus prijungtoje paslaugoje. Jei kažko nematote jūs, to nemato ir jūsų agentas.
• Kiekvienas tinklalapis laikomas nepažįstamuoju: BrowseSafe sukūrėme savo agentinei naršyklei Comet, nes mūsų išbandyti įrankiai realiomis sąlygomis neatitiko mūsų poreikių. Naršyklė tikrina tinklalapius ir kitą išorinį turinį, įskaitant el. laiškus, ar juose nėra raginimų injekcijų. Tiek modelį, tiek duomenų rinkinį paskelbėme kaip atvirąjį kodą.
• Stebime agentą ir įrenginius, kuriuose jis veikia: Numbat veikia tarp agento sprendimo imtis veiksmo ir faktinio įrankio paleidimo. Numbat registruoja palaikomų programavimo agentų veiklą ir gali blokuoti veiksmus, pažeidžiančius sukonfigūruotas politikas, dar prieš juos įvykdant. Bumblebee inventorizuoja programinės įrangos paketus nešiojamuosiuose kompiuteriuose, serveriuose ir kūrimo konvejeriuose bei pažymi žinomus kenkėjiškus paketus. Abu įrankiai yra atvirojo kodo.
• Modelių teikėjai nesaugo jūsų duomenų: Su trečiųjų šalių LLM teikėjais esame sudarę nulinio duomenų saugojimo susitarimus. Enterprise administratoriai taip pat gali sutrumpinti pačios Perplexity duomenų saugojimo laikotarpį iki 24 valandų.

Numbat sukūrėme iniciatyviai dėl priežasties, kurią Polley apibendrina vienu sakiniu: „Kuo daugiau autonomijos suteikiate agentui, tuo didesnė rizika.“

DUK apie LLM saugumą

Koks LLM yra saugiausias?

Joks LLM pats savaime neužtikrina programos saugumo – modeliai vis tiek gali supainioti turinį, kurį turėtų tik perskaityti, su nurodymais, kurių turėtų laikytis. Be to, standartiniuose testuose patikimai atrodančios apsaugos priemonės gali neatlaikyti spaudimo.

Geriau klausti, kuri sąranka yra saugiausia jūsų naudojimo atvejui. Tai reiškia ribotus leidimus, nuo modelio atskirtus prisijungimo duomenis, žmogaus patvirtinimą rizikingiems veiksmams ir testavimą, kurį atlieka jūsų apsaugos priemones išmanantys žmonės.

Kas yra LLM pažeidžiamumai?

LLM pažeidžiamumai – tai silpnosios vietos, dėl kurių DI sistemą galima apgauti, ji gali nutekinti duomenis ar padaryti žalos, nesvarbu, ar dėl užpuoliko veiksmų, ar dėl savo pačios klaidų.

Dešimt pagrindinių rizikų: raginimų injekcija, jautrios informacijos atskleidimas, perteklinis savarankiškumas, tiekimo grandinė, duomenų ir modelio apnuodijimas, neribotas išteklių naudojimas, dezinformacija, paslėpto konteksto atskleidimas, vektorių ir įterpčių silpnosios vietos bei netinkamas išvesties tvarkymas.

Ar privatus LLM yra saugus?

Kai kuriais atvejais tai saugesnis pasirinkimas, bet ne savaime. Jei modelį paleidžiate savo infrastruktūroje ar debesijos aplinkoje, galite geriau kontroliuoti, kaip tvarkomi duomenys. Tačiau nėra automatinio būdo apsisaugoti nuo raginimų injekcijų, perteklinio savarankiškumo, apnuodijimo ar dezinformacijos.

Talpindami modelį patys, jūs taip pat atsakote už atsisiųstą modelį, įskaitant tiekimo grandinės rizikas ir jam reikalingą infrastruktūrą.