Što je sigurnost LLM-ova? Kako ublažiti 10 najvećih sigurnosnih rizika prema OWASP-u
Vodič kroz sigurnost LLM-ova koji obrađuje OWASP Top 10 za LLM aplikacije 2026., uz stvaran incident i praktične obrane za svaki rizik.

Napad kojim se AI navodi da upute napadača tretira kao naredbe – ubacivanje prompta (prompt injection) – u svakom je izdanju od 2023. na 1. mjestu popisa OWASP Top 10 for LLM Applications.
Taj je popis otprilike najbliže konsenzusu što se u sigurnosti AI-ja može postići. Projekt je započeo kao mala skupina sigurnosnih stručnjaka, a danas okuplja više od 600 stručnjaka suradnika iz više od 18 zemalja.
Mi smo AI tvrtka koja objavljuje vodič o tome kako se AI može nagovoriti na razne stvari, pa se nećemo pretvarati da je problem riješen. Wilson, jedan od voditelja projekta OWASP, bio je prilično jasan o trenutačnim obranama: „...iskreno, mislim da nismo na 99 %.“
Izdanje iz 2026. počinje u istom tonu. Voditelj projekta poručuje nam da „prestanemo pokušavati izgraditi model koji se ne može prevariti“ te da okolni sustav osmislimo tako da prevareni model ne može pokvariti ništa važno.
Taj stav primjenjujemo na svih 10 rizika s OWASP-ova popisa za 2026.
Što znači sigurnost LLM-ova?
Sigurnost LLM-ova znači zaštitu AI modela i aplikacija koje ih koriste od napada i zlouporabe. Rizik raste s onim s čime je model povezan: s datotekama i podacima koje može čitati te s alatima koje može koristiti, poput e-pošte, pretraživanja ili baze podataka tvrtke.
U pravilno zaštićenom softveru postoji čvrsta granica između uputa koje program slijedi i informacija koje obrađuje. No LLM-ovi tu granicu nemaju.
Sve što model pročita stiže kao jedan dugi niz teksta: upute razvojnog programera, vaše pitanje, web-stranica koju je potražio. AI modeli trebali bi pratiti tko govori – razvojni programer, korisnik ili sam model dok promišlja o problemu.
No istraživači Jasmine Cui i Charles Ye otkrili su da modeli uglavnom pogađaju tko govori na temelju toga kako tekst zvuči. Ako napadač napiše nešto što zvuči kao modelovo vlastito rasuđivanje, model može povjerovati da je sam došao na tu ideju. To je problem za svaki sigurnosni sustav koji ovisi o tome zna li model tko je glavni.
Na isti smo problem naišli i s vlastitim AI agentima. Naš CISO Kyle Polley rekao je ISMG-u da agenti „možda neće slijediti pravila čak i ako ih dodate u sistemski prompt“. Zato smo izgradili Numbat, alat otvorenog koda koji provjerava što agent namjerava učiniti i može ga blokirati ako radnja krši konfigurirano sigurnosno pravilo.
Sigurnost LLM-ova znači prihvatiti da će model ponekad primati naredbe od pogrešne osobe te oko njega postaviti AI zaštitne mehanizme koji izdrže i kada se to dogodi.
Koje su najbolje prakse za sigurnost LLM-ova?
Redom ćemo proći kroz OWASP Top 10 for LLM Applications 2026, od 1. do 10. mjesta.
Za svaki rizik dobit ćete jednostavno objašnjenje onoga što može poći po zlu i primjer iz stvarnog svijeta. Zatim ćemo obraditi prakse koje ga mogu spriječiti ili barem ograničiti štetu.
Mjesto | Sigurnosni rizik LLM-a | Što može poći po zlu? |
01 | Ubacivanje prompta | Napadač navodi AI da slijedi upute koje ne bi smio. |
02 | Otkrivanje osjetljivih informacija | AI otkriva privatne informacije nekome tko ih ne bi smio vidjeti. |
03 | Prekomjerna autonomija | AI ima dovoljno pristupa i slobode da pogrešku pretvori u štetu. |
04 | Lanac opskrbe | Kompromitirani model, skup podataka ili softverski paket uvodi napadača u vašu aplikaciju. |
05 | Trovanje podataka i modela | Netko neovlašteno mijenja podatke ili model kako bi promijenio njegovo ponašanje ili ugradio stražnja vrata. |
06 | Neograničena potrošnja | Zahtjevi ili zadaci koji su izmakli kontroli troše računalnu snagu i novac. |
07 | Dezinformacije | AI proizvodi netočne informacije na temelju kojih djeluju ljudi ili drugi sustavi. |
08 | Izloženost skrivenog konteksta | AI otkriva interne upute ili pozadinske informacije koje korisnici nisu trebali vidjeti. |
09 | Slabosti vektora i ugrađivanja (embeddinga) | Slabosti u načinu pohrane i dohvaćanja informacija omogućuju napadačima da otkriju podatke ili poremete odgovore. |
10 | Nepravilno rukovanje izlazom | Drugi sustav koristi neprovjereni izlaz AI-ja, što omogućuje izvršavanje naredbi, otkrivanje podataka ili nanošenje štete. |
1. Obuzdajte ubacivanje prompta
Do ubacivanja prompta dolazi kada napadač navede AI da slijedi upute koje ne bi smio. Te upute mogu stići izravno u chatu ili biti podmetnute u e-poruku, web-stranicu ili dokument.
Druga vrsta poznata je kao neizravno ubacivanje prompta. Recimo da zamolite svojeg asistenta da sažme dokument. Autori tog dokumenta u njemu su asistentu naložili da im pošalje vaše privatne datoteke. Ako asistent slijedi te upute, osoba koja je napisala dokument zapravo je posudila vaš pristup.
PCMag uspoređuje sigurnost promptova s krpanjem rupa u poroznom kamenu. Zatvorite jedan otvor, a voda pronađe drugi. „Napad pronađe put; to se popravi, ali bezbroj drugih putova napada ostaje neotkriveno jednostavno zbog toga koliko su dinamični sustavi poput LLM-ova.“
Primjer: U lipnju 2025. istraživači tvrtke Aim Security otkrili su EchoLeak, propust koji je Microsoft 365 Copilot navodio da oda privatne informacije tvrtke. Kada bi zaposlenik postavio rutinsko poslovno pitanje, Copilot je mogao dohvatiti e-poruku, slijediti upute skrivene u njoj i poslati osjetljive informacije napadaču. Napad je zaobišao provjere namijenjene otkrivanju zlonamjernih uputa i uklanjanju sumnjivih poveznica.
Što možete učiniti:
- Slijedite Metino „pravilo dvoje“: EchoLeaku je bio potreban AI koji može čitati podatke tvrtke, čitati vanjsku e-poštu i slati informacije prema van – a Copilot je imao sve tri sposobnosti. Ograničavanjem na dvije od njih sprječava se da ubacivanje prompta preuzme previše kontrole. Ako zadatak zahtijeva sve tri, za svaku radnju zatražite ljudsko odobrenje.
- Testirajte s napadačima koji poznaju vaše obrane: Dajte svojim sigurnosnim testerima pravila i filtre koje ste uveli, a zatim ih pustite da ih zaobiđu. U jednom istraživanju napadači koji su se prilagodili obranama uspjeli su u više od 90 % slučajeva protiv većine od 12 testiranih obrana.
2. Spriječite curenje osjetljivih informacija
Kada AI sustavi daju privatne informacije osobama koje ih ne bi smjele vidjeti, to se naziva otkrivanjem osjetljivih informacija. To može značiti otkrivanje podataka o plaćanju klijenta ili ostavljanje privatnih razgovora u zajedničkoj bazi podataka.
Mnoga curenja počinju „pretjeranim dijeljenjem“. Recimo da tvrtka poveže svoj AI s diskovima i bazama znanja s labavim dozvolama. AI dohvaća sve do čega može doći, točno kako je zamišljeno. Nitko ne mora provaliti, ali LLM svejedno smatrajte kompromitiranim.
Primjer: U siječnju 2025. istraživači tvrtke Wiz otkrili su DeepSeekovu bazu podataka otvorenu prema internetu s više od milijun unosa u zapisnicima, uključujući povijest chatova i API ključeve, koje softver koristi za pristup drugim uslugama. Istraživači nisu morali nagovarati model da išta otkrije.
Što možete učiniti:
- Provjerite pristup prije nego što AI pročita podatke: Vaša aplikacija trebala bi provjeriti koje dokumente osoba koja postavlja pitanje smije vidjeti prije nego što ih proslijedi modelu.
- Zaštitite zapise koje vaš AI ostavlja za sobom: Prije spremanja zapisnika aktivnosti uklonite privatne podatke i tajne ključeve, zahtijevajte prijavu i ograničite pristup na osobe kojima su potrebni. Odredite razdoblje čuvanja kako se ti zapisi ne bi gomilali unedogled.
3. Obuzdajte prekomjernu autonomiju
AI sustavi s prekomjernom autonomijom imaju više ovlasti nego što im posao zahtijeva: alate koji im nisu potrebni, dozvole koje nadilaze njihov zadatak ili slobodu da djeluju bez provjere. Uzrok je ovdje nevažan.
Ubačeni prompt, programska pogreška ili model koji jednostavno pogriješi – sve vodi do istog ishoda. AI će prije ili kasnije učiniti nešto destruktivno ako za to ima sposobnost.
Primjer: U srpnju 2025. osnivač SaaStra Jason Lemkin izvijestio je da je Replitov agent za programiranje izbrisao njegovu bazu podataka s 1206 zapisa o direktorima, unatoč uputama da ne radi nikakve promjene. Agent je isprva tvrdio da se podaci ne mogu vratiti, iako se kasnije pokazalo da je oporavak moguć. Jason je shvatio da mu uputa da ne dira bazu podataka nije oduzela mogućnost da je izbriše.
Izvor: X
Što možete učiniti:
- Uklonite sposobnosti koje zadatku nisu potrebne: Ograničite i alate koje agent dobiva i ono što ti alati mogu činiti. Asistentu koji sažima e-poruke potrebna je dozvola da ih čita, a ne da ih šalje ili briše.
- Provjere dozvola smjestite izvan AI-ja: Svaki put kada se zatraži neka radnja, pobrinite se da se ona provjeri prema vašim sigurnosnim pravilima i zahtijevajte da je odobri osoba.
4. Provjerite što ulazi u vaš AI lanac opskrbe
Malo tvrtki razvija AI od nule, a svake godine sve manje. Prema istraživanju The State of Generative AI in the Enterprise tvrtke Menlo Ventures iz 2025., 53 % tvrtki kupilo je AI modele 2024., a 2025. taj je udio porastao na 76 %.
Tvrtke najčešće preuzimaju modele s platformi poput Hugging Facea, dodatno ih treniraju na skupovima podataka koje su prikupili drugi te uključuju dodatke i programske pakete koje su napisali nepoznati ljudi.
Svaki od tih dijelova moguća je ulazna točka. Ako se jedan od njih neovlašteno izmijeni, problem se isporučuje unutar vašeg proizvoda.
Primjer: Broj javnih repozitorija modela na Hugging Faceu porastao je s 2,43 milijuna na 2,96 milijuna između siječnja i kolovoza 2026. No u srpnju 2026. OpenAI-jevi modeli zaobišli su kontrole koje su ih tijekom internog sigurnosnog testiranja trebale držati izvan interneta i provalili u dijelove sustava Hugging Facea. Jedan je agent čak pronašao 14 javno izloženih pristupnih vjerodajnica, provjerio rade li i podijelio ih s drugim agentima. Agenti su zatim iskoristili propuste koji su im omogućili izvršavanje koda na poslužiteljima Hugging Facea.
„Uvodimo strože zahtjeve za usklađenost tijekom cijelog životnog ciklusa modela i stvaramo izoliranija sandbox okruženja, ograničavamo pristup internetu i dodatno kontroliramo pristup težinama modela“, navodi se u OpenAI-jevu izvješću.
Što možete učiniti:
- Vežite modele uz točnu verziju i provjerite ih: Svaki model vežite uz pregledanu verziju i prije učitavanja provjerite otisak njegove datoteke kako se zamijenjena datoteka ne bi mogla podmetnuti pod istom oznakom. OWASP preporučuje i digitalne potpise, uz napomenu da potpis dokazuje podrijetlo modela, a ne da je model siguran.
- Provjerite svaki paket koji vam AI predloži: Prije instaliranja programskog paketa koji je preporučio AI asistent provjerite postoji li, je li to paket koji ste mislili i dolazi li od izdavača kojeg očekujete.
5. Zaštitite se od trovanja podataka i modela
Otrovani AI uči iz oštećenih podataka. To mogu biti primjeri 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 se nauči loše ponašati samo kada vidi određenu frazu okidač.
S takvom frazom model će proći svaki test koji mu zadate – sve dok je netko ne upotrijebi.
Osim toga, to je doista teško poništiti. Trovanje nije programska pogreška koju možete zakrpati. Ako su vam podaci pogrešni, možda ćete ih morati ponovno provjeriti, ponovno trenirati model ili ga u potpunosti zamijeniti.
Primjer: U listopadu 2025. istraživači iz Anthropica, britanskog instituta UK AI Security Institute i instituta Alan Turing Institute pokazali su da 250 otrovanih dokumenata može naučiti model da generira besmislice kad god naiđe na određeni okidač. Isti je broj djelovao na sve četiri testirane veličine modela, iako je najveći bio treniran na više od 20 puta više čistih podataka.
Što možete učiniti:
- Pratite podrijetlo svojih podataka: Vodite evidenciju o svakom skupu podataka i modelu koji koristite, odakle potječu i što se promijenilo između verzija. Preporučujemo kontrolu verzija za skupove podataka kako biste se, ako otkrijete trovanje, mogli vratiti na čistu verziju i utvrditi kako je do njega došlo.
- Testirajte postoje li stražnja vrata: „Stražnja vrata“ skriveno su ponašanje koje napadač ugradi u model i koje čeka određenu frazu ili drugi okidač da se aktivira. Testirajte model na njih ulaznim podacima osmišljenima tako da ga natjeraju da prekrši svoja uobičajena pravila.
6. Postavite granice neograničenoj potrošnji
Kada AI sustavi nemaju nikakva ograničenja koliko posla mogu obaviti ili koliko mogu koštati, njihova se potrošnja smatra „neograničenom“. Većina AI usluga naplaćuje se po korištenju, pa bi vam napadač mogao napuhati račun ili izraditi kopiju vašeg modela.
OWASP temeljni problem naziva „asimetrijom troškova“. Kratak, jeftin zahtjev može pokrenuti skupo računanje na vašoj strani.
Primjer: U svibnju 2024. Sysdigov tim Threat Research Team otkrio je novu vrstu napada nazvanu „LLMjacking“. Skupina napadača ukradenim je vjerodajnicama ciljala 10 LLM usluga hostiranih u oblaku. Ušli su putem ranjive verzije Laravela, a zatim su utvrdili što vjerodajnice omogućuju i koje su kvote, s očitim ciljem prodaje pristupa. Provjeravali su i brojne postavke zapisivanja, vjerojatno kako bi izbjegli otkrivanje. Prema Sysdigu, u najgorem bi slučaju to žrtvu moglo stajati više od 46.000 dolara dnevno.
Što možete učiniti:
- Postavite proračune koji zaustavljaju potrošnju: Uvedite čvrsta ograničenja potrošnje za pojedinačne korisnike, API ključeve, timove i račun u cjelini. Primjenjujte ih na svakom mjestu na kojem zahtjevi mogu ući.
- Svakom zadatku odredite točku zaustavljanja: Ograničite koliko dugo zadatak može trajati, koliko teksta može obraditi i generirati te koliko poziva alata može uputiti. Dodajte automatske prekide za agente koji se ponavljaju ili premaše dopuštenu kvotu.
7. Uočite dezinformacije prije nego što djelujete
Kada AI proizvede nešto netočno što zvuči ispravno, a netko ili nešto na temelju toga djeluje, to se naziva dezinformacijom. Temeljni rizik nije toliko sam pogrešan odgovor koliko to što se pogrešnom odgovoru vjeruje i što se on koristi.
Evidencija incidenata upućuje na to da stručnjaci nisu bili zabrinuti zbog dezinformacija koliko su trebali biti. Prema uvodnom pismu izdanja za 2026., glasači su ih stavili pri dno popisa, ali prema stvarnim incidentima one su pri vrhu.
Primjer: Deloitte Australia izradio je 2025. pregled informatičkih sustava socijalne skrbi u sklopu državnog ugovora vrijednog 440.000 australskih dolara. Istraživač Chris Rudge sa Sveučilišta u Sydneyju pronašao je reference na nepostojeća istraživanja i izmišljeni citat iz presude saveznog suda. U revidiranom izvješću navedeno je da je Deloitte u svojoj metodologiji koristio Azure OpenAI GPT-4o, a tvrtka je pristala vratiti posljednju ratu. Nažalost, bila je riječ upravo o pregledu kojim se trebala potvrditi pouzdanost.
Što možete učiniti:
- Provjerite potkrepljuju li dokazi odgovor: Tvrdnje temeljite na aktualnim, mjerodavnim izvorima. Za odgovor o pravilima dohvatite odobrena pravila i provjerite potkrepljuju li zaključak, uključujući iznimke.
- Provjerite prije nego što sustav djeluje: Ako agent tvrdi da je klijent prošao provjeru identiteta, potvrdite to u sustavu za provjeru prije nego što odobrite plaćanje. Za odluke sa značajnim posljedicama zahtijevajte ljudsko odobrenje, a osobi koja ih pregledava stavite na raspolaganje dokaze koji ih potkrepljuju.
8. Ograničite štetu od izloženosti skrivenog konteksta
AI aplikacije modelu daju upute i pozadinske informacije koje korisnici inače ne vide. To može uključivati sistemski prompt, interna pravila, opise dostupnih alata i pravila o tome tko ih smije koristiti. Do izloženosti skrivenog konteksta dolazi kada model te informacije nekome otkrije.
OWASP je 2026. proširio ovu stavku s „curenja sistemskog prompta“ jer je sistemski prompt samo dio onoga što može procuriti. Opasnost ovisi o tome što ste ondje stavili. Procurjeli vodič za ton komunikacije pomalo je neugodan, ali procurjeli API ključ nekome daje pristup vašoj povjerljivoj bazi podataka.
Primjer: U veljači 2023. korisnici su naveli Microsoftov Bing Chat da otkrije svoje interne upute. Jedan uspješan pokušaj izveo je Marvin von Hagen, koji se predstavio kao razvojni programer u OpenAI-ju i zatražio upute kako bi mogao konfigurirati model. Bing je otkrio pravila koja upravljaju njegovim pretraživanjima, odgovorima i sigurnosnim ponašanjem, kao i svoje interno ime, Sydney. Među otkrivenim uputama bila je i ona koja mu nalaže da te upute čuva u tajnosti.
Što možete učiniti:
- Držite tajne podatke izvan konteksta modela: Pretpostavite da bi sve što model može pročitati moglo postati vidljivo korisnicima – lozinke, API ključeve i pristupne tokene pohranjujte u zaseban sustav za upravljanje tajnama.
- Neka dopuštenja vrijede čak i ako pravila procure: Provjere pristupa provodite u kodu svoje aplikacije. Ako je alat ograničen na administratore, prije njegova pokretanja provjerite dopuštenja korisničkog računa.
9. Zaštitite vektore i ugrađivanja
Kada AI koristi vektorsko pretraživanje kako bi pronašao odgovore u dokumentima vaše tvrtke, ne pretražuje izravno tekst. Dokumenti se pretvaraju u „ugrađivanja“ (engl. embeddings), odnosno duge nizove brojeva koji bilježe značenje svakog odlomka, i pohranjuju u vektorsku bazu podataka. Pitanje se pretvara na isti način, a sustav dohvaća odlomke čiji su brojevi najbliži.
OWASP sažima četiri načina na koja to može poći po zlu: trovanje čini sustav netočnim, inverzija dovodi do curenja podataka, ometanje ga ušutkava, a narušena kontrola pristupa navodi ga da bilo što preda bilo kome.
Brojevi nisu sigurna apstrakcija kakvom se čine. Pohranjena ugrađivanja mogu se ponovno pretvoriti u tekst, a jedna je metoda u svojim testovima točno rekonstruirala 92 % kratkih odlomaka od 32 tokena. Stoga i procurjela sigurnosna kopija koja sadrži „samo ugrađivanja“ može otkriti sadržaj dokumenata.
Primjer: U istraživanju predstavljenom na konferenciji USENIX Security 2025 istraživači su pokazali da jedan pomno osmišljen dokument može spriječiti AI da odgovori na određeno pitanje. Dodali su ga u zbirku koju je AI pretraživao. Kada bi ga AI pronašao, mogao bi reći da nema dovoljno informacija ili da bi odgovaranje bilo nesigurno. Dokument nije morao AI-ju nalagati da zanemari svoja pravila. To se naziva „ometanje dohvaćanja“ (engl. retrieval jamming).
Što možete učiniti:
- Održavajte zasebne indekse za javne i privatne podatke: Ne miješajte sadržaj prikupljen s weba s podacima partnera ili povjerljivim internim dokumentima. Umjesto da sadržaj označavate unutar jednog indeksa, fizički ga odvojite prema razini povjerenja jer se time uklanja čitava kategorija pogrešnih konfiguracija, a sadržaj prikupljen s interneta ne može završiti pokraj dokumenata za sjednice uprave.
- Postupajte s ugrađivanjima kao s dokumentima iz kojih su nastala: Šifrirajte ih, zaštitite sigurnosne kopije vektorske baze podataka jednako kao i izvorne datoteke te izbrišite ugrađivanja kada izbrišete izvornik. API ključeve za uslugu ugrađivanja treba čuvati u tajnosti.
10. Provjerite izlaz AI-ja prije nego što ga proslijedite dalje
Kad god aplikacija prosljeđuje izlaz AI-ja drugom sustavu bez provjere je li ga ondje sigurno koristiti, riječ je o nepravilnom rukovanju izlazom LLM-a.
Ova stavka obuhvaća i nesiguran kod koji AI asistenti za programiranje generiraju u velikim količinama. Svaki redak koji asistent napiše stoga je također izlaz.
Primjer: Godine 2025. istraživač Johann Rehberger pokazao je kako je Sourcegraphov asistent za programiranje Amp mogao odati sadržaj razgovora samim prikazivanjem slike. Pomoću ubacivanja upita (prompt injection) natjerao je Amp da privatne informacije uključi u web-adresu slike. Aplikacija je zatim automatski dohvatila tu sliku i tako poslala informacije na njegov poslužitelj. Propust u rukovanju izlazom bio je upravo taj automatski zahtjev – tekst koji je model generirao postao je veza s vanjskim poslužiteljem koja je sa sobom prenijela privatne podatke.
Što možete učiniti:
- Učinite izlaz sigurnim za njegovo odredište: Provjeravajte odgovore i postupajte s njima ovisno o tome kamo će ići. Kod web-stranice spriječite da generirani tekst postane izvršni kod. Kod baze podataka koristite pripremljene upite koji dostavljene vrijednosti drže odvojenima od naredbi.
- Spriječite da odgovori automatski uspostavljaju vanjske veze: Prema zadanim postavkama onemogućite automatsko učitavanje slika, pretpregleda poveznica i ugrađenih stranica u odgovorima modela. Nužne veze ograničite na izričito odobrena odredišta.
Kako Perplexity osigurava LLM-ove?
Pretpostavljamo da će se svaki od navedenih rizika prije ili kasnije ostvariti pa sustave osmišljavamo tako da tada ne mogu napraviti veliku štetu. Naš CISO, Kyle Polley, objasnio je kako to radimo na nedavnoj radionici.
- Agent dobiva vlastito računalo, a ono je na početku prazno: Alati za agente instalirani na vašem prijenosnom računalu mogu dobiti pristup njegovim datotekama, aplikacijama i spremljenim vjerodajnicama. Perplexity Computer funkcionira obrnuto. Svaki se zadatak izvršava u vlastitom izoliranom sandboxu, a, kako kaže Polley, „prema zadanim postavkama nema pristup ničemu“.
- Agent nikada ne vidi lozinke: Vjerodajnice za povezane usluge pohranjene su izvan sandboxa. Kada agent treba pristupiti usluzi kao što je GitHub, šalje zahtjev bez priloženih vjerodajnica. Pristupnik provjerava jesu li odredište i zahtjev u skladu s očekivanjima, a zatim na izlasku dodaje vjerodajnice. Agent može koristiti vezu, a da pritom ne dobije ključeve.
- Vaša se dopuštenja prenose, a možete ih i dodatno ograničiti: Veze uspostavljene putem OAutha zadržavaju vaša dopuštenja pristupa u povezanoj usluzi. Ako vi nešto ne možete vidjeti, ne može ni vaš agent.
- Svaka se web-stranica tretira kao nepouzdana: BrowseSafe smo izgradili za Comet, naš agentski preglednik, jer alati koje smo testirali nisu zadovoljili naše potrebe u stvarnoj upotrebi. Preglednik u web-stranicama i drugom vanjskom sadržaju, uključujući e-poštu, traži pokušaje ubacivanja upita. I model i skup podataka objavili smo kao otvoreni kod.
- Nadziremo agenta i računala na kojima radi: Numbat se nalazi između agentove odluke da nešto učini i stvarnog pokretanja alata. Numbat bilježi aktivnosti podržanih agenata za programiranje i može blokirati radnje koje krše konfigurirana pravila prije nego što se izvrše. Bumblebee popisuje softverske pakete na prijenosnim računalima, poslužiteljima i cjevovodima za izgradnju te označava one za koje je poznato da su zlonamjerni. Oba su alata otvorenog koda.
- Pružatelji modela ne zadržavaju vaše podatke: S našim vanjskim pružateljima LLM-ova imamo ugovore o nultom zadržavanju podataka. Administratori u planu Enterprise mogu i vlastito zadržavanje podataka platforme Perplexity skratiti na samo 24 sata.
Numbat smo izgradili proaktivno, iz razloga koji Polley sažima u jednoj rečenici: „Što agentu date više autonomije, to je rizik veći.“
Česta pitanja o sigurnosti LLM-ova
Koji je LLM najsigurniji?
Nijedan LLM sam po sebi ne čini aplikaciju sigurnom – modeli i dalje mogu zamijeniti sadržaj koji trebaju pročitati za upute koje trebaju slijediti. Obrane koje se u standardnim testovima čine snažnima mogu i popustiti pod pritiskom.
Bolje je pitanje koja je konfiguracija najsigurnija za vaš slučaj upotrebe. To znači ograničena dopuštenja, vjerodajnice držane podalje od modela, ljudsko odobrenje za rizične radnje i testiranje koje provode ljudi koji poznaju vaše obrane.
Što su ranjivosti LLM-ova?
Ranjivosti LLM-ova slabosti su koje omogućuju da se AI sustav prevari, da procure podaci ili da nastane šteta, bilo djelovanjem napadača ili vlastitim pogreškama sustava.
Deset glavnih rizika jesu ubacivanje upita, otkrivanje osjetljivih informacija, prekomjerna autonomija, opskrbni lanac, trovanje podataka i modela, neograničena potrošnja, dezinformacije, izlaganje skrivenog konteksta, slabosti vektora i ugrađivanja te nepravilno rukovanje izlazom.
Je li privatni LLM siguran?
Za neke je stvari sigurnija opcija, ali ne sam po sebi. Ako model pokrećete na vlastitoj infrastrukturi ili u oblačnom okruženju, imate veću kontrolu nad rukovanjem podacima. Ne postoji automatski način za sprječavanje ubacivanja upita, prekomjerne autonomije, trovanja ili dezinformacija.
Kada model hostate sami, odgovorni ste i za model koji preuzmete, uključujući rizike opskrbnog lanca i infrastrukturu koja mu je potrebna.