Kas ir LLM drošība? Kā mazināt OWASP Top 10 drošības riskus

Uzvednes injekcija — uzbrukums, kas apmāna MI, liekot tam uzbrucēja instrukcijas uztvert kā komandas, — kopš 2023. gada katrā izdevumā ir ieņēmusi 1. vietu sarakstā OWASP Top 10 LLM lietojumprogrammām.

MI drošības jomā šis saraksts ir tas, kas vistuvāk līdzinās vienprātībai. Projekts sākās kā neliela drošības profesionāļu grupa, bet tagad tajā piedalās vairāk nekā 600 ekspertu no vairāk nekā 18 valstīm.

Mēs esam MI uzņēmums, kas publicē ceļvedi par to, kā MI var pierunāt uz visādām lietām, tāpēc neizliksimies, ka šī problēma ir atrisināta. Wilson, kurš ir viens no OWASP projekta vadītājiem, izteicās visai skaidri par pašreizējiem aizsardzības līdzekļiem: „...atklāti sakot, es nedomāju, ka esam sasnieguši 99 %.”

2026. gada izdevums sākas tādā pašā garā. Projekta vadītājs mudina mūs „pārstāt mēģināt izveidot modeli, ko nevar apmānīt”, un tā vietā veidot apkārtējo sistēmu tā, lai apmānīts modelis nevarētu sabojāt neko svarīgu.

Šo pieeju mēs piemērojam visiem 10 riskiem OWASP 2026. gada sarakstā.

Ko nozīmē LLM drošība?

LLM drošība nozīmē MI modeļu un tos izmantojošo lietojumprogrammu aizsardzību pret uzbrukumiem un ļaunprātīgu izmantošanu. Risks pieaug līdz ar to, kam modelis ir pieslēgts: failiem un datiem, ko tas var lasīt, un rīkiem, ko tas var izmantot, piemēram, e-pastam, meklēšanai vai uzņēmuma datubāzei.

Pienācīgi aizsargātā programmatūrā ir stingra robeža starp instrukcijām, ko programma izpilda, un informāciju, ko tā apstrādā. Taču LLM šādas robežas nav.

Viss, ko modelis lasa, nonāk pie tā kā viena gara teksta plūsma: izstrādātāja instrukcijas, jūsu jautājums, tīmekļa lapa, ko tas atrada. MI modeļiem būtu jāseko līdzi tam, kurš runā, — vai tas ir izstrādātājs, lietotājs vai pats modelis, kas domā par problēmu.

Taču pētnieki Jasmine Cui un Charles Ye atklāja, ka modeļi pārsvarā nosaka, kurš runā, pēc tā, kā teksts izklausās. Tātad, ja uzbrucējs uzraksta kaut ko, kas izklausās pēc paša modeļa spriedumiem, modelis var noticēt, ka šī ideja radusies tam pašam. Tā ir problēma jebkurai drošības sistēmai, kas paļaujas uz to, ka modelis zina, kurš ir noteicējs.

Ar to pašu problēmu esam saskārušies arī darbā ar saviem MI aģentiem. Mūsu informācijas drošības direktors (CISO) Kyle Polley pastāstīja izdevumam ISMG, ka aģenti „var neievērot politikas, pat ja tās pievienojat sistēmas uzvednei”. Tāpēc mēs izveidojām Numbat — atvērtā pirmkoda rīku, kas pārbauda, ko aģents grasās darīt, un var darbību bloķēt, ja tā pārkāpj konfigurētu drošības noteikumu.

LLM drošība nozīmē pieņemt, ka modelis dažkārt izpildīs nepareizās personas rīkojumus, un veidot ap to MI aizsargmehānismus, kas noturas arī tad, kad tā notiek.

Kāda ir LLM drošības labākā prakse?

Mēs secīgi aplūkosim 2026. gada OWASP Top 10 LLM lietojumprogrammām — no Nr. 1 līdz Nr. 10.

Katram riskam sniegsim vienkāršu skaidrojumu par to, kas var noiet greizi, un reālu piemēru. Pēc tam aplūkosim praksi, kas var palīdzēt to novērst vai vismaz ierobežot kaitējumu.

1. Ierobežojiet uzvednes injekcijas ietekmi

Uzvednes injekcija notiek, kad uzbrucējs panāk, ka MI izpilda instrukcijas, kuras tam nevajadzētu izpildīt. Šīs instrukcijas var tikt sniegtas tieši tērzēšanā vai paslēptas e-pastā, tīmekļa lapā vai dokumentā.

Otro veidu sauc par netiešo uzvednes injekciju. Jūs palūdzat savam asistentam apkopot dokumentu. Dokumenta autori tajā ir likuši asistentam nosūtīt viņiem jūsu privātos failus. Ja asistents izpilda šīs instrukcijas, dokumenta autors faktiski ir aizņēmies jūsu piekļuvi.

PCMag salīdzina uzvedņu drošību ar caurumu aizlāpīšanu porainā akmenī. Jūs aizlāpāt vienu atveri, un ūdens atrod citu. „Uzbrukums atrod ceļu cauri; to novērš, taču neskaitāmi citi uzbrukuma ceļi vēl gaida atklāšanu vienkārši tāpēc, ka tādas sistēmas kā LLM ir tik dinamiskas.”

Piemērs: 2025. gada jūnijā Aim Security pētnieki atklāja EchoLeak — ievainojamību, kas apmānīja Microsoft 365 Copilot, liekot tam nopludināt privātu uzņēmuma informāciju. Kad darbinieks uzdeva ikdienišķu darba jautājumu, Copilot varēja ielādēt šo e-pastu, izpildīt tajā paslēptās instrukcijas un nosūtīt sensitīvu informāciju uzbrucējam. Uzbrukums apgāja pārbaudes, kuru uzdevums bija atklāt ļaunprātīgas instrukcijas un noņemt aizdomīgas saites.

Ko varat darīt:

• Ievērojiet Meta „divu principu”: EchoLeak uzbrukumam bija vajadzīgs MI, kas spēj lasīt uzņēmuma datus, lasīt ārējus e-pastus un sūtīt informāciju ārpus uzņēmuma, — un tam bija visas trīs spējas. Ja to ierobežo līdz divām no šīm spējām, uzvednes injekcija nevar iegūt pārāk lielu kontroli. Ja uzdevumam vajadzīgas visas trīs, pirms katras darbības pieprasiet cilvēka apstiprinājumu.
• Testējiet pret uzbrucējiem, kuri zina jūsu aizsardzības līdzekļus: Nododiet saviem drošības testētājiem ieviestos noteikumus un filtrus un ļaujiet viņiem tos apiet. Vienā pētījumā uzbrucēji, kuri pielāgojās aizsardzības līdzekļiem, guva panākumus vairāk nekā 90 % gadījumu pret lielāko daļu no 12 pārbaudītajiem aizsardzības līdzekļiem.

2. Novērsiet sensitīvas informācijas noplūdi

Kad MI sistēmas sniedz privātu informāciju cilvēkiem, kuriem to nevajadzētu redzēt, to sauc par sensitīvas informācijas atklāšanu. Tas var nozīmēt klienta maksājumu datu atklāšanu vai privātu sarunu atstāšanu koplietotā datubāzē.

Daudzas noplūdes sākas ar „pārmērīgu koplietošanu”. Pieņemsim, ka uzņēmums savieno savu MI ar diskiem un zināšanu bāzēm, kuru atļaujas ir pārāk vaļīgas. MI izgūst visu, kam var piekļūt, tieši tā, kā paredzēts. Nevienam nav jāielaužas, taču uzskatiet, ka LLM jau ir uzlauzts.

Piemērs: 2025. gada janvārī Wiz pētnieki atklāja internetā atvērtu DeepSeek datubāzi ar vairāk nekā miljonu žurnāla ierakstu, tostarp tērzēšanas vēsturi un API atslēgām, ko programmatūra izmanto, lai piekļūtu citiem pakalpojumiem. Pētniekiem nemaz nevajadzēja pierunāt modeli kaut ko atklāt.

Ko varat darīt:

• Pārbaudiet piekļuvi, pirms MI nolasa datus: Jūsu lietojumprogrammai jāpārbauda, kurus dokumentus jautājuma uzdevējam ir atļauts redzēt, pirms tie tiek nodoti modelim.
• Aizsargājiet ierakstus, ko atstāj jūsu MI: Pirms darbību žurnālu saglabāšanas izņemiet no tiem privātu informāciju un slepenās atslēgas, pieprasiet pieteikšanos un ierobežojiet piekļuvi tikai tiem, kam tā nepieciešama. Nosakiet glabāšanas periodu, lai šie ieraksti neuzkrātos bezgalīgi.

3. Ierobežojiet pārmērīgu rīcībspēju

MI ar pārmērīgu rīcībspēju ir vairāk pilnvaru, nekā prasa tā darbs: rīki, kas tam nav vajadzīgi, atļaujas, kas pārsniedz tā uzdevumu, vai brīvība rīkoties bez pārbaudes. Cēlonim šeit nav nozīmes.

Injicēta uzvedne, programmas kļūda vai modelis, kas vienkārši kļūdās, — tas viss noved pie viena un tā paša rezultāta. Ja MI ir šāda spēja, tas agri vai vēlu izdarīs kaut ko postošu.

Piemērs: 2025. gada jūlijā SaaStr dibinātājs Jason Lemkin ziņoja, ka Replit kodēšanas aģents izdzēsa viņa datubāzi ar 1206 vadītāju ierakstiem, lai gan bija norādīts neveikt izmaiņas. Sākotnēji aģents apgalvoja, ka datus nav iespējams atjaunot, taču vēlāk izrādījās, ka atkopšana tomēr ir iespējama. Jason secināja, ka norāde atstāt datubāzi neskartu nebija atņēmusi aģentam spēju to izdzēst.

Izvērst

Avots: X

Ko varat darīt:

• Noņemiet spējas, kas uzdevumam nav vajadzīgas: Ierobežojiet gan rīkus, ko aģents saņem, gan to, ko šie rīki var darīt. Asistentam, kas apkopo e-pastus, vajadzīga atļauja tos lasīt, nevis sūtīt vai dzēst.
• Veiciet atļauju pārbaudes ārpus MI: Ikreiz, kad tiek pieprasīta darbība, pārbaudiet to atbilstoši saviem drošības noteikumiem un pieprasiet, lai to apstiprina cilvēks.

4. Pārbaudiet, kas nonāk jūsu MI piegādes ķēdē

Tikai retais uzņēmums veido MI no nulles, un ar katru gadu tādu kļūst arvien mazāk. Saskaņā ar Menlo Ventures 2025. gada aptauju „The State of Generative AI in the Enterprise” 2024. gadā MI modeļus iegādājās 53 % uzņēmumu, bet 2025. gadā šis rādītājs pieauga līdz 76 %.

Visbiežāk uzņēmumi lejupielādē modeļus no tādām platformām kā Hugging Face, papildus apmāca tos ar citu cilvēku savāktām datu kopām un pievieno svešinieku rakstītus papildinājumus un koda pakotnes.

Katra no šīm daļām ir iespējams ielaušanās ceļš. Ja ar kādu no tām ir manipulēts, problēma nonāk jūsu produktā.

Piemērs: No 2026. gada janvāra līdz 2026. gada augustam Hugging Face publisko modeļu repozitoriju skaits pieauga no 2,43 miljoniem līdz 2,96 miljoniem. Tomēr 2026. gada jūlijā OpenAI modeļi iekšējās drošības testēšanas laikā apgāja kontroles, kuru mērķis bija liegt tiem piekļuvi internetam, un ielauzās atsevišķās Hugging Face sistēmu daļās. Viens aģents pat ieguva 14 publiski atklātu piekļuves akreditācijas datu, pārbaudīja, vai tie darbojas, un kopīgoja tos ar citiem aģentiem. Pēc tam aģenti izmantoja ievainojamības, kas ļāva tiem palaist kodu Hugging Face serveros.

„Mēs nosakām stingrākas saskaņotības prasības visā modeļa dzīves ciklā un veidojam izolētākas smilšu kastes, ierobežojam piekļuvi internetam un vēl stingrāk kontrolējam piekļuvi modeļu svariem,” teikts OpenAI ziņojumā.

Ko varat darīt:

• Piesaistiet modeļus konkrētai versijai un pārbaudiet tos: Piesaistiet katru modeli pārskatītai versijai un pirms ielādes pārbaudiet tā faila nospiedumu, lai ar to pašu nosaukumu nevarētu iezagties apmainīts fails. OWASP iesaka arī digitālos parakstus, taču ar atrunu — paraksts pierāda, no kurienes modelis nācis, nevis to, ka tas ir drošs.
• Pārbaudiet katru pakotni, ko iesaka jūsu MI: Pirms instalējat koda pakotni, ko ieteicis MI asistents, pārliecinieties, ka tā eksistē, ka tā ir tieši tā pakotne, kuru domājāt, un ka to ir publicējis gaidītais izdevējs.

5. Aizsargājieties pret datu un modeļu saindēšanu

Saindēts MI mācās no bojātiem datiem. Tie var būt piemēri, ar kuriem modelis tika precīzi pielāgots, vai zināšanu bāze, kurā tas meklē atbildes. Šķiet, ka modelis joprojām darbojas; tas vienkārši iemācās nepareizas lietas, un dažkārt tas iemācās uzvesties nepareizi tikai tad, kad ierauga noteiktu aktivizējošu frāzi.

Šī frāze izturēs katru jūsu testu, līdz kāds to izmantos.

Izvērst

Turklāt to ir patiešām grūti novērst. Saindēšana nav kļūda, ko var izlabot ar ielāpu. Ja jūsu dati ir nepareizi, iespējams, tie būs jāpārbauda no jauna, modelis jāapmāca atkārtoti vai pat pilnībā jāaizstāj.

Piemērs: 2025. gada oktobrī Anthropic, Apvienotās Karalistes MI drošības institūta un Alana Tjūringa institūta pētnieki parādīja, ka 250 saindēti dokumenti var iemācīt modelim ģenerēt bezjēdzīgu tekstu ikreiz, kad tas saskaras ar noteiktu aktivizētāju. Tikpat daudz dokumentu iedarbojās uz visiem četriem pārbaudītajiem modeļu izmēriem, lai gan lielākais tika apmācīts ar vairāk nekā 20 reizes lielāku tīro datu apjomu.

Ko varat darīt:

• Sekojiet līdzi datu izcelsmei: Uzskaitiet katru izmantoto datu kopu un modeli, to izcelsmi un to, kas mainījies starp versijām. Mēs iesakām datu kopām izmantot versiju kontroli, lai saindēšanas gadījumā jūs varētu atgriezties pie tīras versijas un noskaidrot, kā saindētie dati tur nokļuva.
• Pārbaudiet, vai nav sētas durvju: „Sētas durvis” ir slēpta uzvedība, ko uzbrucējs iestrādā modelī un kas gaida noteiktu frāzi vai citu aktivizētāju, lai ieslēgtos. Meklējiet tās ar ievaddatiem, kas izstrādāti tā, lai modelis pārkāptu savus ierastos noteikumus.

6. Uzlieciet griestus neierobežotam patēriņam

Ja MI nav nekādu ierobežojumu tam, cik daudz darba tas var veikt vai cik daudz tas var izmaksāt, tā patēriņu uzskata par „neierobežotu”. Lielākā daļa MI pakalpojumu iekasē maksu par katru lietošanas reizi, tāpēc uzbrucējs varētu krietni palielināt jūsu rēķinu vai izveidot jūsu modeļa kopiju.

OWASP pamatproblēmu dēvē par „izmaksu asimetriju”. Īss, lēts pieprasījums var izraisīt dārgus aprēķinus jūsu pusē.

Piemērs: 2024. gada maijā Sysdig draudu izpētes komanda atklāja jaunu uzbrukuma veidu, ko nosauca par „LLMjacking”. Uzbrucēju grupa, izmantojot zagtus akreditācijas datus, vērsās pret 10 mākonī mitinātiem LLM pakalpojumiem. Viņi iekļuva caur ievainojamu Laravel versiju, pēc tam noskaidroja, ko ar akreditācijas datiem var darīt un kādas ir kvotas, acīmredzot ar mērķi pārdot piekļuvi. Tika vaicāti arī daudzi žurnālēšanas iestatījumi, iespējams, lai izvairītos no atklāšanas. Pēc Sysdig aplēsēm, sliktākajā gadījumā tas upurim varētu izmaksāt vairāk nekā 46 000 ASV dolāru dienā.

Ko varat darīt:

• Nosakiet budžetus, kas aptur tēriņus: Ieviesiet stingrus tēriņu limitus atsevišķiem lietotājiem, API atslēgām, komandām un kontam kopumā. Piemērojiet tos visur, kur var ienākt pieprasījumi.
• Nosakiet katram uzdevumam apstāšanās punktu: Ierobežojiet, cik ilgi uzdevums var darboties, cik daudz teksta tas var apstrādāt un ģenerēt un cik rīku izsaukumu tas var veikt. Pievienojiet automātisku apturēšanu aģentiem, kas atkārtojas vai pārsniedz atvēlēto apjomu.

7. Atklājiet nepatiesu informāciju, pirms rīkojaties

Ja MI rada kaut ko nepatiesu, kas izklausās pareizi, un kāds — vai kaut kas — uz tā pamata rīkojas, to sauc par nepatiesu informāciju. Galvenais risks nav tik daudz pati nepareizā atbilde, cik tas, ka nepareizajai atbildei uzticas un to izmanto.

Incidentu vēsture liecina, ka praktiķi nav bijuši tik norūpējušies par nepatiesu informāciju, cik vajadzētu. Saskaņā ar 2026. gada izdevuma ievadvēstuli balsotāji to ierindoja saraksta lejasdaļā, taču, spriežot pēc reāliem incidentiem, tā ir tuvu augšgalam.

Piemērs: 2025. gadā Deloitte Australia saskaņā ar valdības līgumu 440 000 Austrālijas dolāru vērtībā sagatavoja labklājības IT sistēmu pārskatu. Sidnejas Universitātes pētnieks Chris Rudge atklāja atsauces uz neeksistējošiem pētījumiem un izdomātu citātu no federālās tiesas sprieduma. Pārskatītajā ziņojumā tika atklāts, ka Deloitte savā metodoloģijā izmantojis Azure OpenAI GPT-4o, un uzņēmums piekrita atmaksāt pēdējo maksājumu. Diemžēl tas bija tieši apliecinājuma pārskats.

Ko varat darīt:

• Pārbaudiet, vai pierādījumi apstiprina atbildi: Pamatojiet apgalvojumus ar aktuāliem, autoritatīviem avotiem. Ja atbilde attiecas uz politiku, izgūstiet apstiprināto politiku un pārbaudiet, vai tā pamato secinājumu, ņemot vērā arī tās izņēmumus.
• Pārbaudiet, pirms sistēma rīkojas: Ja aģents apgalvo, ka klients ir izturējis identitātes pārbaudi, pirms maksājuma izpildes apstipriniet to verifikācijas sistēmā. Būtiskiem lēmumiem pieprasiet cilvēka apstiprinājumu un nodrošiniet, lai pārskatītājam būtu pieejami pamatojošie pierādījumi.

8. Ierobežojiet slēptā konteksta atklāšanas radīto kaitējumu

MI lietojumprogrammas sniedz modelim instrukcijas un fona informāciju, ko lietotāji parasti neredz. Tā var ietvert sistēmas uzvedni, iekšējās politikas, pieejamo rīku aprakstus un noteikumus par to, kas tos drīkst izmantot. Slēptā konteksta atklāšana notiek, kad modelis šo informāciju kādam atklāj.

OWASP 2026. gadā paplašināja šo ierakstu, kas iepriekš saucās „sistēmas uzvednes noplūde”, jo sistēmas uzvedne ir tikai daļa no tā, kas var nonākt ārpusē. Bīstamība ir atkarīga no tā, ko tur esat ievietojuši. Nopludināts komunikācijas toņa ceļvedis ir nedaudz apkaunojošs, bet nopludināta API atslēga kādam dod piekļuvi jūsu konfidenciālajai datubāzei.

Piemērs: 2023. gada februārī lietotāji panāca, ka Microsoft Bing Chat atklāj savas iekšējās instrukcijas. Vienu veiksmīgu mēģinājumu veica Marvin von Hagen, kurš uzdevās par OpenAI izstrādātāju un lūdza instrukcijas, lai varētu konfigurēt modeli. Bing atklāja noteikumus, kas reglamentē tā meklēšanu, atbildes un drošības uzvedību, kā arī savu iekšējo nosaukumu Sydney. Starp atklātajām instrukcijām bija arī norāde šīs instrukcijas paturēt konfidenciālas.

Ko varat darīt:

• Neglabājiet slepenos datus modeļa kontekstā: Pieņemiet, ka viss, ko modelis var nolasīt, var kļūt redzams lietotājiem, tāpēc glabājiet paroles, API atslēgas un piekļuves pilnvaras atsevišķā slepeno datu pārvaldības sistēmā.
• Nodrošiniet, lai atļaujas darbotos arī tad, ja noteikumi noplūst: Ieviesiet piekļuves pārbaudes savas lietojumprogrammas kodā. Ja rīks ir pieejams tikai administratoriem, pirms tā palaišanas pārbaudiet lietotāja konta atļaujas.

9. Aizsargājiet vektorus un iegulumus

Kad MI izmanto vektoru meklēšanu, lai atrastu atbildes jūsu uzņēmuma dokumentos, tas nemeklē tieši tekstā. Dokumenti tiek pārvērsti „iegulumos” (embeddings) — garos skaitļu sarakstos, kas atspoguļo katra fragmenta nozīmi, — un saglabāti vektoru datubāzē. Jautājums tiek pārvērsts tādā pašā veidā, un sistēma atlasa fragmentus, kuru skaitļi ir vistuvākie.

OWASP apkopo četrus veidus, kā šāda sistēma var nedarboties: saindēšana liek tai kļūdīties, inversija — nopludināt datus, bloķēšana — apklust, bet nepilnīga piekļuves kontrole — atdot jebko jebkuram.

Skaitļi nav tik droša abstrakcija, kā šķiet. Saglabātos iegulumus var pārvērst atpakaļ tekstā, un viena metode savos testos precīzi atjaunoja 92 % īsu, 32 marķierus garu fragmentu. Tāpēc arī nopludināta rezerves kopija, kurā ir „tikai iegulumi”, var atklāt dokumentu saturu.

Piemērs: Pētījumā, kas tika prezentēts konferencē USENIX Security 2025, pētnieki parādīja, ka viens rūpīgi sagatavots dokuments var liegt MI atbildēt uz konkrētu jautājumu. Viņi to pievienoja kolekcijai, kurā MI veica meklēšanu. Kad MI šo dokumentu atrada, tas varēja paziņot, ka tam nav pietiekami daudz informācijas vai ka atbildēt būtu nedroši. Dokumentam nemaz nevajadzēja likt MI ignorēt savus noteikumus. To sauc par „izguves bloķēšanu”.

Ko varat darīt:

• Uzturiet atsevišķus indeksus publiskiem un privātiem datiem: Nejauciet no tīmekļa iegūtu saturu ar partneru datiem vai konfidenciāliem iekšējiem dokumentiem. Nodaliet datus fiziski pēc uzticamības līmeņa, nevis marķējiet saturu vienā indeksā, jo tas novērš veselu nepareizas konfigurācijas kļūdu kategoriju un no interneta iegūts saturs nevar nonākt blakus jūsu valdes dokumentiem.
• Izturieties pret iegulumiem tāpat kā pret dokumentiem, no kuriem tie radušies: Šifrējiet tos, aizsargājiet vektoru datubāzes rezerves kopijas tāpat kā avota failus un dzēsiet iegulumus, kad dzēšat oriģinālu. Jūsu iegulumu pakalpojuma API atslēgas jāglabā slepenībā.

10. Pārbaudiet MI izvadi, pirms to nododat tālāk

Ikreiz, kad lietojumprogramma nodod MI izvadi citai sistēmai, nepārbaudot, vai to tur ir droši izmantot, notiek nepareiza LLM izvades apstrāde.

Šis punkts aptver arī nedrošo kodu, ko MI programmēšanas asistenti ģenerē lielā apjomā. Tāpēc arī katra rinda, ko uzraksta asistents, ir izvade.

Piemērs: 2025. gadā pētnieks Johans Rēbergers (Johann Rehberger) parādīja, kā Sourcegraph programmēšanas asistents Amp varēja nopludināt tērzēšanas saturu, vienkārši parādot attēlu. Viņš izmantoja uzvednes injekciju, lai liktu Amp iekļaut privātu informāciju attēla tīmekļa adresē. Pēc tam lietojumprogramma automātiski ielādēja šo attēlu, nosūtot informāciju uz viņa serveri. Izvades apstrādes kļūme bija tieši šis automātiskais pieprasījums — modeļa ģenerētais teksts kļuva par savienojumu ar ārēju serveri, nesot līdzi privātus datus.

Ko varat darīt:

• Padariet izvadi drošu tās galamērķim: Pārbaudiet un apstrādājiet atbildes atkarībā no tā, kur tās nonāks. Tīmekļa lapā neļaujiet ģenerētajam tekstam kļūt par izpildāmu kodu. Datubāzē izmantojiet sagatavotus vaicājumus, kas nodala ievadītās vērtības no komandām.
• Neļaujiet atbildēm automātiski veidot ārējus savienojumus: Pēc noklusējuma atspējojiet attēlu, saišu priekšskatījumu un iegulto lapu automātisku ielādi modeļa atbildēs. Nepieciešamos savienojumus atļaujiet tikai ar skaidri apstiprinātiem galamērķiem.

Kā Perplexity nodrošina LLM drošību?

Mēs pieņemam, ka katrs iepriekš minētais risks agri vai vēlu īstenosies, un veidojam sistēmas tā, lai tad tas nevarētu nodarīt lielu kaitējumu. Mūsu informācijas drošības vadītājs (CISO) Kails Pollijs to izskaidroja nesenā darbnīcā.

• Aģents saņem savu datoru, un sākumā tas ir tukšs: Jūsu klēpjdatorā instalētie aģentu rīki var iegūt piekļuvi tā failiem, lietotnēm un saglabātajiem akreditācijas datiem. Perplexity Computer darbojas tieši pretēji. Katrs uzdevums tiek izpildīts savā izolētā smilšu kastē, un, kā saka Pollijs, „pēc noklusējuma tam nav piekļuves nekam”.
• Aģents nekad neredz paroles: Pievienoto pakalpojumu akreditācijas dati tiek glabāti ārpus smilšu kastes. Kad aģentam jāpiekļūst tādam pakalpojumam kā GitHub, tas nosūta pieprasījumu bez akreditācijas datiem. Vārteja pārbauda, vai galamērķis un pieprasījums atbilst gaidītajam, un pēc tam izejošajam pieprasījumam pievieno akreditācijas datus. Aģents var izmantot savienojumu, nesaņemot atslēgas.
• Jūsu atļaujas tiek pārņemtas, un jūs varat tās vēl vairāk ierobežot: Ar OAuth izveidotie savienojumi saglabā jūsu piekļuves atļaujas pievienotajā pakalpojumā. Ja jūs kaut ko nevarat redzēt, to nevar redzēt arī jūsu aģents.
• Katra tīmekļa lapa tiek uzskatīta par svešinieku: Mēs izveidojām BrowseSafe mūsu aģentiskajam pārlūkam Comet, jo mūsu testētie rīki reālā lietojumā neatbilda mūsu vajadzībām. Pārlūks skenē tīmekļa lapas un citu ārēju saturu, tostarp e-pasta ziņojumus, meklējot uzvednes injekcijas. Mēs publiskojām gan modeli, gan datu kopu kā atvērtā pirmkoda resursus.
• Mēs uzraugām aģentu un iekārtas, kurās tas darbojas: Numbat darbojas starp brīdi, kad aģents nolemj rīkoties, un brīdi, kad rīks faktiski tiek palaists. Numbat reģistrē darbības atbalstītajos programmēšanas aģentos un var bloķēt darbības, kas pārkāpj konfigurētās politikas, pirms tās tiek izpildītas. Bumblebee inventarizē programmatūras pakotnes klēpjdatoros, serveros un būvēšanas konveijeros un atzīmē zināmās ļaunprātīgās pakotnes. Abi ir atvērtā pirmkoda rīki.
• Modeļu nodrošinātāji neglabā jūsu datus: Ar mūsu trešo pušu LLM nodrošinātājiem mums ir noslēgtas vienošanās par datu nesaglabāšanu (zero data retention). Enterprise administratori var arī saīsināt Perplexity pašas datu glabāšanas periodu līdz pat 24 stundām.

Mēs izveidojām Numbat proaktīvi, un iemeslu Pollijs formulē vienā teikumā: „Jo vairāk autonomijas jūs dodat aģentam, jo lielāks ir risks.”

Bieži uzdotie jautājumi par LLM drošību

Kurš LLM ir visdrošākais?

Neviens LLM pats par sevi nepadara lietojumprogrammu drošu — modeļi joprojām var sajaukt saturu, kas tiem jālasa, ar norādījumiem, kas tiem jāizpilda. Arī aizsardzības mehānismi, kas standarta testos šķiet spēcīgi, spiediena apstākļos var neizturēt.

Labāk ir jautāt, kura konfigurācija ir visdrošākā jūsu lietošanas gadījumā. Tas nozīmē ierobežotas atļaujas, no modeļa nošķirtus akreditācijas datus, cilvēka apstiprinājumu riskantām darbībām un testēšanu, ko veic cilvēki, kuri pārzina jūsu aizsardzības mehānismus.

Kas ir LLM ievainojamības?

LLM ievainojamības ir vājās vietas, kuru dēļ MI sistēmu var piemānīt, tā var nopludināt datus vai nodarīt kaitējumu — vai nu uzbrucēja darbību, vai pašas sistēmas kļūdu dēļ.

Desmit galvenie riski ir uzvednes injekcija, sensitīvas informācijas izpaušana, pārmērīga rīcībspēja, piegādes ķēde, datu un modeļa saindēšana, neierobežots resursu patēriņš, dezinformācija, slēptā konteksta atklāšana, vektoru un iegulumu vājās vietas un nepareiza izvades apstrāde.

Vai privāts LLM ir drošs?

Dažos aspektos tā ir drošāka iespēja, taču ne pēc noklusējuma. Ja modeli darbināt savā infrastruktūrā vai mākoņvidē, jums ir lielāka kontrole pār datu apstrādi. Tomēr nav automātiska veida, kā novērst uzvednes injekcijas, pārmērīgu rīcībspēju, saindēšanu vai dezinformāciju.

Izvēloties pašmitināšanu, jūs esat atbildīgs arī par lejupielādēto modeli, tostarp par piegādes ķēdes riskiem un tam nepieciešamo infrastruktūru.