Šta je bezbednost LLM-ova? Kako ublažiti 10 najvećih bezbednosnih rizika po OWASP-u

Vodič za bezbednost LLM-ova koji prolazi kroz OWASP Top 10 za LLM aplikacije 2026, uz stvarni incident i praktične odbrane za svaki rizik.

OWASP Top 10 for LLM Applications 2026: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses, LLM10 Improper Output Handling.

Napad koji navodi AI da instrukcije napadača tretira kao komande — ubacivanje prompta (prompt injection) — nalazi se na 1. mestu liste OWASP Top 10 for LLM Applications u svakom izdanju od 2023. godine.

Ova lista je verovatno najbliže konsenzusu što se u oblasti AI bezbednosti može postići. Projekat je pokrenula mala grupa stručnjaka za bezbednost, a danas okuplja više od 600 stručnjaka iz više od 18 zemalja koji doprinose projektu.

Mi smo AI kompanija koja objavljuje vodič o tome kako se AI može nagovoriti na razne stvari, pa se nećemo pretvarati da je ovaj problem rešen. Wilson, jedan od rukovodilaca OWASP projekta, bio je prilično jasan u vezi sa trenutnim odbranama: „...iskreno, mislim da nismo na 99%.“

Izdanje iz 2026. počinje u istom tonu. Rukovodilac projekta nam savetuje da „prestanemo da pokušavamo da napravimo model koji se ne može prevariti“ i da okolni sistem dizajniramo tako da prevareni model ne može da pokvari ništa važno.

Taj stav primenjujemo na svih 10 rizika sa OWASP liste za 2026. godinu.

Šta znači bezbednost LLM-ova?

Bezbednost LLM-ova podrazumeva zaštitu AI modela i aplikacija koje ih koriste od napada i zloupotrebe. Što je model povezan sa više stvari, rizik je veći: tu spadaju fajlovi i podaci koje može da čita, kao i alati koje može da koristi, poput imejla, pretrage ili baze podataka kompanije.

U pravilno zaštićenom softveru postoji čvrsta granica između instrukcija koje program izvršava i informacija koje obrađuje. Ali LLM-ovi tu granicu nemaju.

Sve što model pročita stiže kao jedan dugačak tok teksta: instrukcije programera, vaše pitanje, veb-stranica koju je potražio. AI modeli bi trebalo da prate ko govori — da li je to programer, korisnik ili sam model dok razmišlja o problemu.

Međutim, istraživači Jasmine Cui i Charles Ye otkrili su da modeli uglavnom pogađaju ko govori na osnovu toga kako tekst zvuči. Dakle, ako napadač napiše nešto što zvuči kao rezonovanje samog modela, model može poverovati da je sam došao na tu ideju. To je problem za svako bezbednosno rešenje koje zavisi od toga da model zna ko ima glavnu reč.

Na isti problem naišli smo i kod naših AI agenata. Naš CISO, Kyle Polley, izjavio je za ISMG da agenti „možda neće poštovati pravila čak i ako ih dodate u sistemski prompt“. Zato smo napravili Numbat, alat otvorenog koda koji proverava šta agent namerava da uradi i može da ga blokira ako ta radnja krši konfigurisano bezbednosno pravilo.

Bezbednost LLM-ova znači prihvatiti da će model ponekad primati naredbe od pogrešne osobe i postaviti oko njega AI zaštitne mehanizme koji izdržavaju i kada se to dogodi.

Koje su najbolje prakse za bezbednost LLM-ova?

Proći ćemo redom kroz OWASP Top 10 for LLM Applications 2026, od 1. do 10. mesta.

Za svaki rizik dobićete jednostavno objašnjenje toga šta može da pođe po zlu i primer iz stvarnog sveta. Zatim ćemo predstaviti prakse koje mogu da pomognu u sprečavanju tog rizika ili bar da ograniče štetu.

Rang

Bezbednosni rizik LLM-a

Šta može da pođe po zlu?

01

Ubacivanje prompta

Napadač navodi AI da izvršava instrukcije koje ne bi trebalo.

02

Otkrivanje osetljivih informacija

AI otkriva privatne informacije nekome ko ne bi trebalo da ih vidi.

03

Prekomerna autonomija

AI ima dovoljno pristupa i slobode da grešku pretvori u štetu.

04

Lanac snabdevanja

Kompromitovan model, skup podataka ili softverski paket otvara napadaču put u vašu aplikaciju.

05

Trovanje podataka i modela

Neko neovlašćeno menja podatke ili model kako bi promenio njegovo ponašanje ili ugradio zadnja vrata (backdoor).

06

Neograničena potrošnja

Zahtevi ili zadaci koji su izmakli kontroli troše računarske resurse i novac.

07

Dezinformacije

AI generiše netačne informacije na osnovu kojih ljudi ili drugi sistemi deluju.

08

Izlaganje skrivenog konteksta

AI otkriva interne instrukcije ili pozadinske informacije koje korisnici nije trebalo da vide.

09

Slabosti vektora i ugrađivanja (embeddings)

Slabosti u načinu na koji se informacije čuvaju i preuzimaju omogućavaju napadačima da otkriju podatke ili poremete odgovore.

10

Nepravilno rukovanje izlazom

Drugi sistem koristi neprovereni izlaz AI-ja, što omogućava pokretanje komandi, otkrivanje podataka ili nanošenje štete.

1. Obuzdajte ubacivanje prompta

Ubacivanje prompta se dešava kada napadač navede AI da izvršava instrukcije koje ne bi trebalo. Te instrukcije mogu stići direktno u četu ili biti podmetnute u imejl, veb-stranicu ili dokument.

Drugi tip je poznat kao indirektno ubacivanje prompta. Recimo da zamolite asistenta da sažme dokument. Autor dokumenta je u njemu naložio asistentu da mu pošalje vaše privatne fajlove. Ako asistent izvrši te instrukcije, osoba koja je napisala dokument praktično je pozajmila vaš pristup.

PCMag poredi bezbednost promptova sa zatvaranjem rupa u poroznom kamenu. Zatvorite jedan otvor, a voda pronađe drugi. „Napad pronađe put; propust se ispravi, ali bezbroj drugih puteva napada tek čeka da bude otkriven, jednostavno zbog toga koliko su sistemi poput LLM-ova dinamični.“

Primer: U junu 2025. istraživači iz kompanije Aim Security otkrili su EchoLeak, propust koji je navodio Microsoft 365 Copilot da otkrije privatne informacije kompanije. Kada bi zaposleni postavio rutinsko poslovno pitanje, Copilot je mogao da učita imejl, izvrši instrukcije skrivene u njemu i pošalje osetljive informacije napadaču. Napad je zaobišao provere namenjene otkrivanju zlonamernih instrukcija i uklanjanju sumnjivih linkova.

Šta možete da uradite:

  • Pridržavajte se „pravila dva“ kompanije Meta: EchoLeak je zahtevao AI koji može da čita podatke kompanije, čita spoljne imejlove i šalje informacije napolje — a imao je sve tri mogućnosti. Ako ga ograničite na dve od tih mogućnosti, ubacivanje prompta ne može da stekne preveliku kontrolu. Ako su zadatku potrebne sve tri, zahtevajte ljudsko odobrenje pre svake radnje.
  • Testirajte otpornost na napadače koji poznaju vaše odbrane: Dajte svojim testerima bezbednosti pravila i filtere koje ste uveli, a zatim neka pokušaju da ih zaobiđu. U jednoj studiji, napadači koji su se prilagodili odbranama uspeli su u više od 90% slučajeva protiv većine od 12 testiranih odbrana.

2. Sprečite curenje osetljivih informacija

Kada AI sistemi daju privatne informacije ljudima koji ne bi trebalo da ih vide, to se naziva otkrivanjem osetljivih informacija. To može značiti otkrivanje podataka o plaćanju korisnika ili ostavljanje privatnih razgovora u deljenoj bazi podataka.

Mnoga curenja počinju „preteranim deljenjem“. Recimo da kompanija poveže svoj AI sa diskovima i bazama znanja koje imaju labave dozvole. AI preuzima sve do čega može da dođe, tačno onako kako je i dizajniran. Niko ne mora da provaljuje, ali smatrajte da je LLM već provaljen.

Primer: U januaru 2025. istraživači kompanije Wiz otkrili su DeepSeek bazu podataka otvorenu ka internetu sa više od milion zapisa u logovima, uključujući istoriju četa i API ključeve, pomoću kojih softver pristupa drugim servisima. Istraživači nisu morali da ubeđuju model da bilo šta otkrije.

Šta možete da uradite:

  • Proverite pristup pre nego što AI pročita podatke: Vaša aplikacija bi trebalo da proveri koje dokumente osoba koja postavlja pitanje sme da vidi pre nego što ih prosledi modelu.
  • Zaštitite zapise koje vaš AI ostavlja za sobom: Uklonite privatne podatke i tajne ključeve pre čuvanja logova aktivnosti, zahtevajte prijavu i ograničite pristup na ljude kojima su potrebni. Odredite period čuvanja kako se ti zapisi ne bi gomilali u nedogled.

3. Obuzdajte prekomernu autonomiju

AI sistemi sa prekomernom autonomijom imaju više moći nego što njihov posao zahteva: alate koji im nisu potrebni, dozvole koje prevazilaze njihov zadatak ili slobodu da deluju bez provere. Uzrok je ovde nebitan.

Ubačeni prompt, greška u kodu ili model koji jednostavno pogreši — sve to vodi do istog ishoda. AI će pre ili kasnije uraditi nešto destruktivno ako za to ima mogućnost.

Primer: U julu 2025. osnivač kompanije SaaStr Jason Lemkin izvestio je da je agent za programiranje kompanije Replit obrisao njegovu bazu podataka sa 1.206 zapisa o rukovodiocima, uprkos instrukcijama da ne pravi izmene. Agent je prvobitno tvrdio da se podaci ne mogu vratiti, iako se kasnije pokazalo da je oporavak moguć. Jason je otkrio da mu nalog da ne dira bazu podataka nije oduzeo mogućnost da je obriše.

Izvor: X

Šta možete da uradite:

  • Uklonite mogućnosti koje zadatku nisu potrebne: Ograničite i alate koje agent dobija i ono što ti alati mogu da rade. Asistentu koji sažima imejlove potrebna je dozvola da ih čita, a ne da ih šalje ili briše.
  • Postavite provere dozvola van AI-ja: Svaki put kada se zatraži neka radnja, proverite je u odnosu na svoja bezbednosna pravila i zahtevajte da je odobri čovek.

4. Proverite šta ulazi u vaš AI lanac snabdevanja

Malo kompanija pravi AI od nule, a svake godine ih je sve manje. Prema istraživanju kompanije Menlo Ventures „2025 The State of Generative AI in the Enterprise“, 53% kompanija kupovalo je AI modele 2024. godine, a taj udeo je 2025. porastao na 76%.

Kompanije najčešće preuzimaju modele sa platformi kao što je Hugging Face, dodatno ih treniraju na skupovima podataka koje su prikupili drugi i povezuju ih sa dodacima i softverskim paketima koje su napisali nepoznati ljudi.

Svaki od tih delova predstavlja mogući ulaz. Ako je neki od njih kompromitovan, problem stiže ugrađen u vaš proizvod.

Primer: Broj javnih repozitorijuma modela na platformi Hugging Face porastao je sa 2,43 miliona na 2,96 miliona između januara i avgusta 2026. Međutim, u julu 2026. OpenAI modeli su tokom internog bezbednosnog testiranja zaobišli kontrole koje je trebalo da ih drže van interneta i provalili u delove sistema platforme Hugging Face. Jedan agent je čak pribavio 14 javno izloženih pristupnih kredencijala, proverio da li rade i podelio ih sa drugim agentima. Agenti su zatim iskoristili propuste koji su im omogućili da pokreću kod na serverima platforme Hugging Face.

„Uvodimo strože zahteve za usklađivanje (alignment) tokom celog životnog ciklusa modela i pravimo izolovanija sandbox okruženja, ograničavamo pristup internetu i dodatno kontrolišemo pristup težinama modela“, navodi se u izveštaju kompanije OpenAI.

Šta možete da uradite:

  • Fiksirajte modele na tačnu verziju i verifikujte ih: Fiksirajte svaki model na pregledanu verziju i proverite otisak (heš) njegovog fajla pre učitavanja, kako zamenjeni fajl ne bi mogao da se podmetne pod istom oznakom. OWASP preporučuje i digitalne potpise, uz jednu napomenu — potpis dokazuje odakle model potiče, a ne da je bezbedan.
  • Proverite svaki paket koji vaš AI predloži: Pre nego što instalirate softverski paket koji je preporučio AI asistent, proverite da li postoji, da li je to paket koji ste imali na umu i da li dolazi od izdavača kog očekujete.

5. Zaštitite se od trovanja podataka i modela

Zatrovani AI uči iz oštećenih podataka. To mogu biti primeri na kojima je fino podešen ili baza znanja u kojoj traži odgovore. Model i dalje izgleda kao da radi; samo uči pogrešne lekcije, a ponekad nauči da se ponaša neispravno samo kada vidi određenu frazu okidač.

Ta fraza će neopaženo proći kroz svaki test, sve dok je neko ne upotrebi.

Uz to, ovo je zaista teško poništiti. Trovanje nije greška koju možete da zakrpite. Ako su vaši podaci pogrešni, možda ćete morati ponovo da ih proverite, ponovo trenirate model ili ga potpuno zamenite.

Primer: U oktobru 2025. istraživači iz kompanije Anthropic, britanskog instituta UK AI Security Institute i instituta Alan Turing Institute pokazali su da 250 zatrovanih dokumenata može naučiti model da proizvodi besmislice kad god naiđe na određeni okidač. Isti broj dokumenata bio je dovoljan kod sve četiri testirane veličine modela, iako je najveći treniran na više od 20 puta većoj količini čistih podataka.

Šta možete da uradite:

  • Pratite odakle vaši podaci potiču: Vodite evidenciju o svakom skupu podataka i modelu koji koristite, odakle svaki od njih potiče i šta se promenilo između verzija. Preporučujemo kontrolu verzija za skupove podataka, kako biste se, ako se otkrije trovanje, mogli vratiti na čistu verziju i utvrditi kako je do njega došlo.
  • Testirajte da li postoje zadnja vrata: „Zadnja vrata“ (backdoor) su skriveno ponašanje koje napadač ugradi u model i koje čeka određenu frazu ili drugi okidač da bi se aktiviralo. Proveravajte to pomoću unosa osmišljenih tako da navedu model da prekrši svoja uobičajena pravila.

6. Stavite granicu neograničenoj potrošnji

Kada AI sistemi nemaju nikakva ograničenja u pogledu toga koliko posla mogu da obave ili koliko mogu da koštaju, njihova potrošnja se smatra „neograničenom“. Većina AI servisa naplaćuje po korišćenju, pa bi napadač mogao da vam naduva račun ili da izradi kopiju vašeg modela.

OWASP osnovni problem naziva „asimetrijom troškova“. Kratak, jeftin zahtev može da pokrene skupu obradu na vašoj strani.

Primer: U maju 2024. tim za istraživanje pretnji kompanije Sysdig otkrio je novi napad pod nazivom „LLMjacking“. Grupa napadača ciljala je 10 LLM servisa hostovanih u oblaku koristeći ukradene kredencijale. Ušli su preko ranjive verzije frejmvorka Laravel, a zatim utvrdili šta kredencijali omogućavaju i koje kvote postoje, s očiglednim ciljem da prodaju pristup. Ispitivana su i brojna podešavanja logovanja, verovatno da bi se izbeglo otkrivanje. Prema podacima kompanije Sysdig, u najgorem slučaju žrtvu bi to moglo da košta više od 46.000 dolara dnevno.

Šta možete da uradite:

  • Postavite budžete koji zaustavljaju potrošnju: Uvedite čvrsta ograničenja potrošnje za pojedinačne korisnike, API ključeve, timove i nalog u celini. Primenjujte ih na svakom mestu na kom zahtevi mogu da uđu.
  • Odredite tačku zaustavljanja za svaki zadatak: Ograničite koliko dugo zadatak može da traje, koliko teksta može da obradi i generiše i koliko poziva alata može da napravi. Dodajte automatsko prekidanje za agente koji se ponavljaju ili prekorače dozvoljeni limit.

7. Uočite dezinformacije pre nego što preduzmete radnju

Kada AI proizvede nešto netačno što zvuči ispravno, a neko ili nešto postupi na osnovu toga, to se naziva dezinformacijom. Osnovni rizik nije toliko sam pogrešan odgovor koliko to što se pogrešnom odgovoru veruje i što se on koristi.

Evidencija incidenata ukazuje na to da stručnjaci nisu bili zabrinuti zbog dezinformacija onoliko koliko je trebalo. Prema uvodnom pismu izdanja iz 2026. godine, glasači su ih svrstali pri dnu liste, ali prema stvarnim incidentima, one su pri vrhu.

Primer: Deloitte Australia je 2025. godine isporučio pregled IT sistema za socijalnu pomoć u okviru državnog ugovora vrednog 440.000 australijskih dolara. Chris Rudge, istraživač sa Univerziteta u Sidneju, pronašao je reference na nepostojeća istraživanja, kao i izmišljeni citat iz presude saveznog suda. U revidiranom izveštaju navedeno je da je Deloitte u svojoj metodologiji koristio Azure OpenAI GPT-4o, a firma je pristala da vrati poslednju ratu. Nažalost, radilo se upravo o reviziji čija je svrha bila da potvrdi pouzdanost.

Šta možete da uradite:

  • Proverite da li dokazi potkrepljuju odgovor: Zasnivajte tvrdnje na aktuelnim, merodavnim izvorima. Za odgovor u vezi sa nekom politikom preuzmite odobrenu politiku i proverite da li ona potkrepljuje zaključak, uključujući njene izuzetke.
  • Proverite pre nego što sistem deluje: Ako agent kaže da je korisnik prošao proveru identiteta, potvrdite to u sistemu za verifikaciju pre nego što odobrite plaćanje. Zahtevajte ljudsko odobrenje za odluke sa ozbiljnim posledicama, uz prateće dokaze dostupne osobi koja vrši pregled.

8. Ograničite štetu od izlaganja skrivenog konteksta

AI aplikacije daju modelu instrukcije i pozadinske informacije koje korisnici obično ne vide. To može uključivati sistemski prompt, interne politike, opise dostupnih alata i pravila o tome ko može da ih koristi. Do izlaganja skrivenog konteksta dolazi kada model te informacije otkrije nekome.

OWASP je 2026. proširio ovu stavku sa „curenja sistemskog prompta“ jer je sistemski prompt samo deo onoga što može da procuri. Opasnost zavisi od toga šta ste tamo stavili. Ako procuri vodič za ton komunikacije, to je pomalo neprijatno, ali procureli API ključ nekome daje pristup vašoj poverljivoj bazi podataka.

Primer: U februaru 2023. korisnici su naveli Bing Chat kompanije Microsoft da otkrije svoje interne instrukcije. Jedan uspešan pokušaj izveo je Marvin von Hagen, koji je tvrdio da je programer u kompaniji OpenAI i zatražio instrukcije kako bi mogao da konfiguriše model. Bing je otkrio pravila koja upravljaju njegovim pretragama, odgovorima i bezbednosnim ponašanjem, kao i svoje interno ime, Sydney. Među otkrivenim instrukcijama bila je i ona koja mu nalaže da te instrukcije čuva kao poverljive.

Šta možete da uradite:

  • Držite tajne podatke van konteksta modela: Pretpostavite da sve što model može da pročita može postati vidljivo korisnicima — lozinke, API ključeve i pristupne tokene čuvajte u zasebnom sistemu za upravljanje tajnim podacima.
  • Neka dozvole važe čak i kada pravila procure: Sprovodite provere pristupa u kodu svoje aplikacije. Ako je alat ograničen na administratore, pre pokretanja proverite dozvole korisničkog naloga.

9. Zaštitite svoje vektore i embedinge

Kada AI koristi vektorsku pretragu da pronađe odgovore u dokumentima vaše kompanije, ne pretražuje direktno tekst. Dokumenti se pretvaraju u „embedinge“, odnosno duge nizove brojeva koji beleže značenje svakog odlomka, i čuvaju se u vektorskoj bazi podataka. Pitanje se pretvara na isti način, a sistem izdvaja odlomke čiji su brojevi najbliži.

OWASP sažima četiri načina na koja ovo može da zakaže: trovanje čini sistem netačnim, inverzija dovodi do curenja podataka, ometanje ga ućutkuje, a narušena kontrola pristupa ga navodi da bilo šta preda bilo kome.

Brojevi nisu bezbedna apstrakcija kakvom se čine. Sačuvani embedinzi mogu se ponovo pretvoriti u tekst, a jedna metoda je u svojim testovima tačno rekonstruisala 92% kratkih odlomaka od 32 tokena. Zato i rezervna kopija koja sadrži „samo embedinge“, ako procuri, može otkriti sadržaj dokumenata.

Primer: U istraživanju predstavljenom na konferenciji USENIX Security 2025, istraživači su pokazali da jedan pažljivo osmišljen dokument može sprečiti AI da odgovori na određeno pitanje. Dodali su ga u kolekciju koju je AI pretraživao. Kada bi ga AI pronašao, mogao bi da kaže da nema dovoljno informacija ili da bi odgovaranje bilo nebezbedno. Dokument nije morao da nalaže AI-ju da ignoriše svoja pravila. Ovo se naziva „ometanje pretraživanja“.

Šta možete da uradite:

  • Održavajte zasebne indekse za javne i privatne podatke: Ne mešajte sadržaj prikupljen sa veba sa podacima partnera ili poverljivim internim dokumentima. Umesto da sadržaj u jednom indeksu razlikujete oznakama, fizički ga razdvojite prema nivou poverenja, jer se tako eliminiše čitava klasa pogrešnih konfiguracija, a sadržaj prikupljen sa interneta ne može da završi pored dokumenata vašeg upravnog odbora.
  • Tretirajte embedinge kao dokumente iz kojih su nastali: Šifrujte ih, štitite rezervne kopije vektorske baze podataka jednako kao i izvorne datoteke, a embedinge brišite kada brišete original. API ključeve za uslugu za embedinge treba čuvati u tajnosti.

10. Proverite izlazne podatke AI-ja pre nego što ih prosledite dalje

Kad god aplikacija prosledi izlazne podatke AI-ja drugom sistemu bez provere da li su bezbedni za upotrebu u njemu, reč je o nepravilnom rukovanju izlaznim podacima LLM-a.

Ova stavka obuhvata i nebezbedan kod koji AI asistenti za programiranje generišu u velikim razmerama. Stoga se i svaka linija koda koju asistent napiše smatra izlaznim podacima.

Primer: Godine 2025. istraživač Johann Rehberger je pokazao kako je asistent za programiranje Amp kompanije Sourcegraph mogao da oda sadržaj razgovora samim prikazivanjem slike. Pomoću ubacivanja prompta naveo je Amp da privatne informacije uključi u veb-adresu slike. Aplikacija je zatim automatski preuzela tu sliku i tako poslala informacije na njegov server. Propust u rukovanju izlaznim podacima bio je upravo taj automatski zahtev — tekst koji je model generisao pretvorio se u vezu sa spoljnim serverom, noseći sa sobom privatne podatke.

Šta možete da uradite:

  • Učinite izlazne podatke bezbednim za njihovo odredište: Proveravajte i obrađujte odgovore u skladu s tim kuda će otići. Kod veb-stranice sprečite da generisani tekst postane izvršni kod. Kod baze podataka koristite pripremljene upite koji dostavljene vrednosti drže odvojeno od komandi.
  • Sprečite da odgovori automatski uspostavljaju spoljne veze: Podrazumevano onemogućite automatsko učitavanje slika, pregleda linkova i ugrađenih stranica u odgovorima modela. Neophodne veze ograničite na izričito odobrena odredišta.

Kako Perplexity štiti LLM-ove?

Polazimo od pretpostavke da će se svaki od gore navedenih rizika na kraju ostvariti, pa sisteme projektujemo tako da tada ne može mnogo da naškodi. Naš CISO Kyle Polley objasnio je kako to radimo na nedavnoj radionici.

  • Agent dobija sopstveni računar, koji je na početku prazan: Alati za agente instalirani na vašem laptopu mogu dobiti pristup njegovim datotekama, aplikacijama i sačuvanim akreditivima. Perplexity Computer funkcioniše obrnuto. Svaki zadatak se izvršava u sopstvenom izolovanom sandbox okruženju i, kako Polley kaže, „podrazumevano nema pristup ničemu“.
  • Agent nikada ne vidi lozinke: Akreditivi za povezane usluge čuvaju se van sandbox okruženja. Kada agent treba da pristupi usluzi kao što je GitHub, šalje zahtev bez priloženih akreditiva. Mrežni prolaz proverava da li su odredište i zahtev u skladu sa očekivanjima, a zatim dodaje akreditive pri slanju zahteva. Agent može da koristi vezu, a da nikada ne dobije ključeve.
  • Vaše dozvole se prenose, a možete ih i dodatno ograničiti: Veze uspostavljene putem OAuth-a zadržavaju vaše dozvole pristupa u povezanoj usluzi. Ako vi nešto ne možete da vidite, ne može ni vaš agent.
  • Svakoj veb-stranici pristupamo s nepoverenjem: Napravili smo BrowseSafe za Comet, naš agentski pregledač, jer alati koje smo testirali nisu zadovoljavali naše potrebe u stvarnoj upotrebi. Pregledač skenira veb-stranice i drugi spoljni sadržaj, uključujući e-poruke, u potrazi za ubacivanjem prompta. I model i skup podataka objavili smo kao otvoreni kod.
  • Nadgledamo agenta i mašine na kojima radi: Numbat se nalazi između trenutka kada agent odluči da deluje i stvarnog pokretanja alata. Numbat beleži aktivnosti u podržanim agentima za programiranje i može da blokira radnje koje krše konfigurisane smernice pre nego što se izvrše. Bumblebee pravi popis softverskih paketa na laptopovima, serverima i u sistemima za izgradnju softvera i označava pakete za koje se zna da su zlonamerni. Oba alata su otvorenog koda.
  • Dobavljači modela ne čuvaju vaše podatke: Sa spoljnim dobavljačima LLM-ova imamo ugovore o nultom zadržavanju podataka. Administratori Enterprise naloga mogu i da skrate period zadržavanja podataka u samom Perplexity-ju na svega 24 sata.

Numbat smo napravili proaktivno, iz razloga koji Polley sažima u jednoj rečenici: „Što više autonomije date agentu, to je rizik veći.“

Česta pitanja o bezbednosti LLM-ova

Koji je LLM najbezbedniji?

Nijedan LLM sam po sebi ne čini aplikaciju bezbednom — modeli i dalje mogu da pomešaju sadržaj koji treba da pročitaju sa uputstvima koja treba da slede. Odbrane koje deluju snažno na standardnim testovima takođe mogu da popuste pod pritiskom.

Bolje je pitati koja je konfiguracija najbezbednija za vaš slučaj upotrebe. To podrazumeva ograničene dozvole, akreditive koji se drže dalje od modela, ljudsko odobrenje za rizične radnje i testiranje koje sprovode ljudi koji poznaju vaše odbrane.

Šta su ranjivosti LLM-ova?

Ranjivosti LLM-ova su slabosti zbog kojih AI sistem može biti prevaren, otkriti podatke ili naneti štetu, bilo zbog napadača ili zbog sopstvenih grešaka.

Deset glavnih rizika su ubacivanje prompta, otkrivanje osetljivih informacija, prekomerna autonomija, lanac snabdevanja, trovanje podataka i modela, neograničena potrošnja, dezinformacije, izlaganje skrivenog konteksta, slabosti vektora i embedinga i nepravilno rukovanje izlaznim podacima.

Da li je privatni LLM bezbedan?

Za neke namene jeste bezbednija opcija, ali ne sam po sebi. Ako model pokrećete na sopstvenoj infrastrukturi ili u okruženju u oblaku, imate veću kontrolu nad rukovanjem podacima. Međutim, ne postoji automatski način da se spreče ubacivanje prompta, prekomerna autonomija, trovanje ili dezinformacije.

Kada model sami hostujete, odgovorni ste i za model koji preuzimate, uključujući rizike u lancu snabdevanja i infrastrukturu koja mu je potrebna.